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
- Use the container_id exactly as returned by the create call on the same provider (openai or azure).
- Pass the matching custom_llm_provider explicitly instead of relying on the default 'openai' + embedded-ID decoding.
- If the ID is LiteLLM-managed and stale, create a new container rather than reusing an ID from another provider/mapping.
- 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
- Persist the provider alongside every container_id at creation time.
- Treat decoded-provider mismatches as stale IDs — recreate rather than retry.
- Wrap stored-ID replay paths in try/except that quarantines failing IDs.
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
- Container provider config not found for: {resolved_custom_ll
- container operations are not supported for {custom_llm_provi
- Container provider config not found for provider: {custom_ll
- Failed to transform Braintrust response: {str(e)}
- Unclassified keys in {PRICES_PATH.name}: {', '.join(unclassi
AI-assisted analysis of BerriAI/litellm@6c2dcb801b (2026-08-15).
Data as JSON: /api/errors/b60c81f612c5c6de.
Report an issue: GitHub.