BerriAI/litellm · error · Exception

No response from fallbacks. Got none. Turn on `litellm.set_v

Error message

No response from fallbacks. Got none. Turn on `litellm.set_verbose=True` to see more details.

What it means

Generic Exception raised in async completion when the fallbacks machinery (async_completion_with_fallbacks) returned None instead of a response -- meaning every configured fallback was exhausted or skipped and the individual failures were swallowed by the fallback loop. The message itself admits the root cause is only visible with verbose logging.

Source

Thrown at litellm/main.py:607

        "acompletion": True,  # assuming this is a required parameter
        "thinking": thinking,
        "web_search_options": web_search_options,
        "include_server_side_tool_invocations": include_server_side_tool_invocations,
        "shared_session": shared_session,
        "enable_json_schema_validation": enable_json_schema_validation,
    }
    if custom_llm_provider is None:
        _, custom_llm_provider, _, _ = get_llm_provider(
            model=model,
            custom_llm_provider=custom_llm_provider,
            api_base=base_url,
        )

    fallbacks = fallbacks or litellm.model_fallbacks
    if fallbacks is not None:
        response = await async_completion_with_fallbacks(**completion_kwargs, kwargs={"fallbacks": fallbacks, **kwargs})
        if response is None:
            raise Exception(
                "No response from fallbacks. Got none. Turn on `litellm.set_verbose=True` to see more details."
            )
        return response

    ### APPLY MOCK DELAY ###

    mock_delay: Final = kwargs.get("mock_delay")
    mock_response: Final = kwargs.get("mock_response")
    mock_tool_calls: Final = kwargs.get("mock_tool_calls")
    mock_timeout = kwargs.get("mock_timeout")
    if mock_delay and should_run_mock_completion(
        mock_response=mock_response,
        mock_tool_calls=mock_tool_calls,
        mock_timeout=mock_timeout,
    ):
        await asyncio.sleep(mock_delay)

    try:

View on GitHub (pinned to 77b7c6c40c)

Solutions

Set litellm.set_verbose = True (or debug via callback logs) and rerun to see each fallback's real error
Test each fallback model standalone with the same credentials to find the broken entry
Fix the fallbacks structure for the API you are calling (plain list for completion kwargs; router-style mapping belongs to Router)
Temporarily remove fallbacks so the primary model's original exception surfaces directly

Example fix

# before
resp = await litellm.acompletion(model='gpt-4o', fallbacks=['claude-3-5-sonnet'], messages=m)  # Exception: No response from fallbacks

# after: verify fallbacks work standalone, keep fallbacks off until fixed
resp = await litellm.acompletion(model='gpt-4o', messages=m)

Defensive patterns

Strategy: try-catch

Validate before calling

# sanity-check every fallback model resolves before relying on it
for m in [primary, *fallbacks]:
    try:
        litellm.get_llm_provider(model=m)
    except Exception as e:
        raise ValueError(f'fallback model {m!r} does not resolve: {e}')

Try / catch

try:
    resp = await litellm.acompletion(model=primary, fallbacks=fallbacks, messages=m)
except Exception as e:
    if 'No response from fallbacks' in str(e):
        # all candidates failed; surface the primary error directly
        resp = await litellm.acompletion(model=primary, messages=m)
    else:
        raise

Prevention

Validate fallback model names and credentials with the same checks as the primary model at deploy time
Prefer Router with its documented fallbacks structure over ad-hoc fallbacks kwargs for production
Keep verbose logging or a callback logger enabled in lower environments so fallback failures are never silent
Add alerting on fallback-exhaustion events, not just on primary errors

When it happens

Trigger: await litellm.acompletion(..., fallbacks=[...]) where all fallback models fail (bad keys, unknown model names, network) or the fallbacks argument is malformed so nothing is actually attempted; the helper returns None and main.py raises.

Common situations: Fallback list pointing at models that are not in the deployment; one shared bad API key across primary and fallbacks; fallbacks config shaped for Router (list of {model: [...]}) passed to plain completion; auth or rate-limit errors on every candidate.

Related errors

AI-assisted analysis of BerriAI/litellm@77b7c6c40c (2026-08-18). Data as JSON: /api/errors/4940589c62fb40d7. Report an issue: GitHub.