Issue Station
Sign In
Tools hereToolbox

litellm - ✅(Solved) Fix [Feature]: Support Azure-hosted Containers for Code Interpreter file retrieval [1 pull requests, 1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
BerriAI/litellm#22996•Fetched 2026-04-08 00:39:00
View on GitHub
Comments
1
Participants
2
Timeline
7
Reactions
3
Author
david-kuehndavid-kuehn
Participants
david-kuehndavid-kuehnzooneonzooneon
Timeline (top)
subscribed ×3labeled ×2commented ×1cross-referenced ×1

Error Message

{ "error": { "message": "litellm.APIConnectionError: openai - Incorrect API key provided: None. You can find your API key at https://platform.openai.com/account/api-keys.", "type": null, "param": null, "code": "500" } }

Root Cause

LiteLLM's Container endpoints (/v1/containers/{id}/files, /v1/containers/{id}/files/{file_id}/content, etc.) currently only route to OpenAI. When using Code Interpreter via an Azure OpenAI deployment, the Responses API correctly returns container_id and container_file_citation annotations, but subsequent calls to the container file retrieval endpoints fail because LiteLLM attempts to forward them to OpenAI instead of the originating Azure endpoint.

Fix Action

Fixed

PR fix notes

PR #24685: feat: support Azure OpenAI container API

Description (problem / solution / changelog)

Relevant issues

Fixes #22996

Pre-Submission checklist

  • I have Added testing in the tests/test_litellm/ directory
  • My PR passes all unit tests on make test-unit
  • My PR's scope is as isolated as possible, it only solves 1 specific problem
  • I have requested a Greptile review by commenting @greptileai and received a Confidence Score of at least 4/5 before requesting a maintainer review

Type

🆕 New Feature

Changes

Summary

LiteLLM's Container endpoints currently only route to OpenAI. When using Code Interpreter via Azure OpenAI, container file retrieval requests fail because LiteLLM forwards them to OpenAI instead of Azure. This PR registers the existing AzureOpenAIContainerConfig class so that all container operations (CRUD + file operations) work with Azure OpenAI.

Note: Azure OpenAI supports the Container API in the v1 API. See the Azure OpenAI v1 REST API reference — Containers for full endpoint documentation.

Code Changes

  • litellm/constants.py — Add AZURE_DEFAULT_CONTAINERS_API_VERSION constant
  • litellm/utils.py — Register AzureOpenAIContainerConfig in ProviderConfigManager.get_provider_container_config()
  • litellm/proxy/container_endpoints/handler_factory.py — Register Azure in _get_container_provider_config()
  • litellm/containers/main.py — Update custom_llm_provider type hints from Literal["openai"] to Literal["openai", "azure"]

Tests

  • tests/test_litellm/containers/test_azure_container_transformation.py — 17 tests covering Azure container config inheritance, authentication headers, URL construction, request/response transformations, and provider registration

Docs

  • docs/my-website/docs/containers.md — Add Azure to supported providers, add OpenAI/Azure tab examples
  • docs/my-website/docs/container_files.md — Add Azure to supported providers, add OpenAI/Azure tab examples

Changed files

  • docs/my-website/docs/container_files.md (modified, +61/-9)
  • docs/my-website/docs/containers.md (modified, +177/-33)
  • litellm/constants.py (modified, +3/-0)
  • litellm/containers/main.py (modified, +24/-24)
  • litellm/llms/azure/containers/transformation.py (added, +166/-0)
  • litellm/proxy/container_endpoints/handler_factory.py (modified, +6/-0)
  • litellm/utils.py (modified, +6/-0)
  • tests/test_litellm/containers/test_azure_container_transformation.py (added, +297/-0)

Code Example

{
  "error": {
    "message": "litellm.APIConnectionError: openai - Incorrect API key provided: None. You can find your API key at https://platform.openai.com/account/api-keys.",
    "type": null,
    "param": null,
    "code": "500"
  }
}

---

GET https://{endpoint}.openai.azure.com/openai/v1/containers/{container_id}/files
RAW_BUFFERClick to expand / collapse

Check for existing issues

  • I have searched the existing issues and checked that my issue is not a duplicate.

The Feature

LiteLLM's Container endpoints (/v1/containers/{id}/files, /v1/containers/{id}/files/{file_id}/content, etc.) currently only route to OpenAI. When using Code Interpreter via an Azure OpenAI deployment, the Responses API correctly returns container_id and container_file_citation annotations, but subsequent calls to the container file retrieval endpoints fail because LiteLLM attempts to forward them to OpenAI instead of the originating Azure endpoint.

Expected behavior: Container file retrieval requests should be routed to the same Azure endpoint that served the original Responses API call, using the Azure API key and base URL — just like the /v1/responses call itself.

Current behavior: Calling GET /v1/containers/{container_id}/files through LiteLLM returns:

{
  "error": {
    "message": "litellm.APIConnectionError: openai - Incorrect API key provided: None. You can find your API key at https://platform.openai.com/account/api-keys.",
    "type": null,
    "param": null,
    "code": "500"
  }
}

The same request made directly to Azure succeeds:

GET https://{endpoint}.openai.azure.com/openai/v1/containers/{container_id}/files

and returns the expected file listing.

Relevant code: https://github.com/BerriAI/litellm/blob/main/litellm/utils.py#L8745-L8754 — it appears only OpenAI is currently wired as a supported provider for Containers.

Motivation, pitch

We're using Azure OpenAI with Code Interpreter through LiteLLM Proxy. The Code Interpreter call works perfectly and returns container IDs and file citations in the response. However, we cannot retrieve the generated files (e.g., plots, CSVs) from those containers because the container file endpoints are hardcoded to OpenAI.

This means users on Azure have to bypass LiteLLM entirely and call Azure directly to download container files, which defeats the purpose of using LiteLLM as a unified proxy.

Azure documentation confirms container support:

LiteLLM documentation references containers but only for OpenAI:

What part of LiteLLM is this about?

Proxy

Are you interested in joining LiteLLM?

No

extent analysis

Fix Plan

To fix the issue, we need to modify the LiteLLM proxy to route container file retrieval requests to the same Azure endpoint that served the original Responses API call. Here are the steps:

  • Modify the litellm/utils.py file to add Azure as a supported provider for Containers.
  • Update the get_container_files function to use the Azure API key and base URL when the original request was made to Azure.

Example code:

# litellm/utils.py

# Add Azure as a supported provider for Containers
SUPPORTED_PROVIDERS = ['openai', 'azure']

# Update the get_container_files function
def get_container_files(container_id, provider):
    if provider == 'azure':
        # Use the Azure API key and base URL
        api_key = 'YOUR_AZURE_API_KEY'
        base_url = 'https://{endpoint}.openai.azure.com/openai/v1'
        url = f'{base_url}/containers/{container_id}/files'
        headers = {'Authorization': f'Bearer {api_key}'}
        response = requests.get(url, headers=headers)
        return response.json()
    elif provider == 'openai':
        # Existing code for OpenAI
        pass
  • Update the litellm/proxy.py file to pass the provider to the get_container_files function.
# litellm/proxy.py

# Update the container_files endpoint
@app.route('/v1/containers/<string:container_id>/files', methods=['GET'])
def get_container_files_endpoint(container_id):
    provider = request.args.get('provider')
    if provider == 'azure':
        # Call the updated get_container_files function
        files = get_container_files(container_id, provider)
        return jsonify(files)
    else:
        # Existing code for OpenAI
        pass

Verification

To verify the fix, make a request to the GET /v1/containers/{container_id}/files endpoint through LiteLLM with the provider parameter set to azure. The response should be a list of files in the container.

Example request:

GET /v1/containers/{container_id}/files?provider=azure

Extra Tips

  • Make sure to replace YOUR_AZURE_API_KEY with your actual Azure API key.
  • Update the LiteLLM documentation to reflect the added support for Azure Containers.
  • Test the fix thoroughly to ensure it works for all scenarios.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#ssr#installation#tensor shape#autograd error#agent setup#task chaining#parallel task#integration issue

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

litellm - ✅(Solved) Fix [Feature]: Support Azure-hosted Containers for Code Interpreter file retrieval [1 pull requests, 1 comments, 2 participants]