BerriAI/litellm · error · ValueError

Container provider config not found for provider: {resolved_

Error message

Container provider config not found for provider: {resolved_custom_llm_provider}

What it means

Raised in the container-retrieval path (get container by id) after decode_managed_container_id_for_request resolves the effective provider. If the caller-supplied provider is 'openai' and the container_id is a LiteLLM-managed encoded ID, the provider embedded in the ID wins; when that resolved provider has no container config (only openai/azure do), this ValueError is raised.

Source

Thrown at litellm/containers/main.py:636

            **kwargs,
        )

        # Decode container ID and extract provider info
        original_container_id, resolved_custom_llm_provider, litellm_params = decode_managed_container_id_for_request(
            container_id=container_id,
            custom_llm_provider=custom_llm_provider,
            litellm_params=litellm_params,
        )
        # True when input was a LiteLLM-managed ID (any length); needed to re-encode output for routing affinity
        was_encoded: Final = original_container_id != container_id

        # get provider config
        container_provider_config: BaseContainerConfig | None = ProviderConfigManager.get_provider_container_config(
            provider=litellm.LlmProviders(resolved_custom_llm_provider),
        )

        if container_provider_config is None:
            raise ValueError(f"Container provider config not found for provider: {resolved_custom_llm_provider}")

        # Pre Call logging
        litellm_logging_obj.update_from_kwargs(
            kwargs=kwargs,
            model="",
            optional_params={},
            litellm_params={
                "litellm_call_id": litellm_call_id,
            },
            custom_llm_provider=resolved_custom_llm_provider,
        )

        # Set the correct call type
        litellm_logging_obj.call_type = CallTypes.retrieve_container.value

        container_obj = base_llm_http_handler.container_retrieve_handler(
            container_id=original_container_id,  # Use decoded original ID
            container_provider_config=container_provider_config,

View on GitHub (pinned to 6c2dcb801b)

Solutions

  1. Use the container_id exactly as returned by the create call on the same provider (openai or azure).
  2. Pass the matching custom_llm_provider explicitly instead of relying on the default 'openai' + embedded-ID decoding.
  3. If the ID is LiteLLM-managed and stale, create a new container rather than reusing an ID from another provider/mapping.
  4. Add a BaseContainerConfig for the target provider in ProviderConfigManager.

Example fix

# before
container = await litellm.acreate_get_container(
    container_id=stale_id_from_other_provider,
)

# after
created = await litellm.acreate_container(custom_llm_provider="openai")
container = await litellm.acreate_get_container(
    container_id=created.id,
    custom_llm_provider="openai",
)
Defensive patterns

Strategy: try-catch

Validate before calling

from litellm.containers.utils import decode_managed_container_id_for_request
from litellm.litellm_core_utils.core_helpers import ProviderConfigManager
import litellm

_, resolved, _ = decode_managed_container_id_for_request(container_id, custom_llm_provider or "openai", params)
if ProviderConfigManager.get_provider_container_config(litellm.LlmProviders(resolved)) is None:
    raise StaleContainerId(container_id)

Type guard

def container_id_resolves_to_supported_provider(cid: str, fallback: str = "openai") -> bool:
    try:
        _, provider, _ = decode_managed_container_id_for_request(cid, fallback, GenericLiteLLMParams())
        return ProviderConfigManager.get_provider_container_config(
            litellm.LlmProviders(provider)
        ) is not None
    except Exception:
        return False

Try / catch

try:
    c = await litellm.acreate_get_container(container_id=cid)
except ValueError as e:
    if "provider config not found" in str(e):
        mark_stale(cid)  # stop retrying this stored id
    raise

Prevention

When it happens

Trigger: Calling a get-container endpoint with a LiteLLM-managed encoded container_id whose embedded custom_llm_provider is not openai/azure, or with an explicit unsupported custom_llm_provider.

Common situations: Persisting container IDs from an older gateway or different provider mapping and replaying them later; mixing an anthropic/vertex deployment label with an OpenAI-issued container ID; corrupted or truncated encoded IDs that decode to garbage provider strings.

Related errors


AI-assisted analysis of BerriAI/litellm@6c2dcb801b (2026-08-15). Data as JSON: /api/errors/b60c81f612c5c6de. Report an issue: GitHub.