What causes "{e}" in BerriAI/litellm?

Read the wrapped message — it is str(e) of the original exception and names the actual problem; fix that first.

BerriAI/litellm · error · VertexAIError

{e}

Error message

{e}

What it means

A catch-all wrapper at the boundary of the Vertex Model Garden completion handler: any exception raised while preparing or executing the request (token retrieval, URL building, the OpenAILikeChatHandler call) is re-raised as VertexAIError with status 500 and the original message preserved. It is not a specific failure itself — it is the transport envelope for whatever went wrong underneath; read the message text to find the real cause.

Source

Thrown at litellm/llms/vertex_ai/vertex_model_garden/main.py:149

                messages=messages,
                api_base=api_base,
                api_key=access_token,
                custom_prompt_dict=custom_prompt_dict,
                model_response=model_response,
                print_verbose=print_verbose,
                logging_obj=logging_obj,
                optional_params=optional_params,
                acompletion=acompletion,
                litellm_params=litellm_params,
                logger_fn=logger_fn,
                client=client,
                timeout=timeout,
                encoding=encoding,
                custom_llm_provider="vertex_ai",
            )

        except Exception as e:
            raise VertexAIError(status_code=500, message=str(e))

View on GitHub (pinned to 77b7c6c40c)

Solutions

Read the wrapped message — it is str(e) of the original exception and names the actual problem; fix that first.
Confirm the model string after normalization: get_vertex_base_model_name must map vertex_ai/openai/<id> to a deployed Model Garden endpoint in your project.
Verify project/location/credentials (vertex_project, vertex_location, VERTEXAI_*) and that aiplatform.googleapis.com is enabled.
If the inner error is a Google 429/5xx, add retries with exponential backoff rather than changing config.

Defensive patterns

Strategy: try-catch

Try / catch

from litellm.exceptions import VertexAIError

try:
    resp = litellm.completion(model="vertex_ai/openai/llama-3.1-405b-instruct", messages=msgs)
except VertexAIError as e:
    inner = str(e)  # contains the original error text
    if "429" in inner or "quota" in inner.lower():
        backoff_and_retry()
    elif "permission" in inner.lower():
        raise ConfigError(f"Vertex IAM/billing issue: {inner}")
    else:
        raise

Prevention

Treat this wrapper as opaque: always branch on the inner message, never on status_code alone (it is always 500 here).
Pre-validate model IDs against your deployed Model Garden endpoints before calling.
Wrap model-garden calls with retry+backoff for transient Google-side 429/5xx inner errors.

When it happens

Trigger: Any failure inside the vertex_ai/openai/{MODEL_ID} path: missing project/credentials from _ensure_access_token, model-name resolution errors from get_vertex_base_model_name, network/HTTP failures from the underlying handler, or unsupported-parameter errors — all re-wrapped here with status_code=500.

Common situations: Model Garden model IDs spelled wrong (publisher/model mismatch); Vertex endpoint not deployed for the requested model in that project/region; quota or permission (iam.serviceAccounts) errors; transient 429/503 from the Vertex service being surfaced as generic 500s.

Related errors

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