[Bug]: Vertex Veo video status/content fail with vertex_project is required; client params ignored; #18854 missing from main #33521

Check for existing issues

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

Related prior reports (same family, not an exact open Vertex re-open of the #18854 loss):

• [Bug]: veo-3.1-generate-preview video status query fails with DefaultCredentialsError despite successful generation #18050 — Veo generate OK, status fails with DefaultCredentialsError (closed)
• [Bug]: Veo support - failing to poll the video generation status and download the video #17512 — Veo status + download still failing after generate (closed)
• [Feature]: Support Multiple Veo models from different GCP projects #16945 — Veo project/credentials handling; status/content follow-up called out (closed)
• [Bug]: azure-openai sora-2 have generated a video, but can not download video, report errs #17016 — Azure Sora generate OK, download missing API key (closed)
• [Bug]: POST /v1/videos encodes empty model_id → status/content fail with invalid_api_key for STORE_MODEL_IN_DB per-model keys (OpenAI) #33423 / fix(videos): preserve model_id in proxy video ids so per-model keys resolve on status/content #33437 — OpenAI path: status/content lose model identity / per-model key (open)
• PR fix: video status/content credential injection for wildcard models #18854 — fix for video status/content credential injection for wildcard models (merged into staging, then lost from main)

No open issue currently captures: Vertex Veo + proxy status/content ignore request-level vertex_project + #18854 absent from main.

What happened?

LiteLLM Proxy Video API for Vertex AI (Veo):

1. POST /v1/videos can succeed when Vertex project/credentials are available for that call (request params, env, or deployment config).
2. GET /v1/videos/{video_id} (status) and GET /v1/videos/{video_id}/content (download) fail with:

vertex_project is required for Vertex AI video generation.
Set it via VERTEXAI_PROJECT or pass as parameter.

(or the related DefaultCredentialsError / missing-credentials path, depending on config)

Passing vertex_project / vertex_location again on status/content via query params, headers, or body does not help. Those endpoints do not re-apply request-level Vertex params; they rely on resolving a deployment from the video id and injecting config.

Expected: generate → poll → download should use the same Vertex deployment credentials as generation, without re-supplying project/credentials on every status/content call. Proxy docs currently show status/content with only the virtual key, which implies automatic credential restore.

Steps to Reproduce

1. Configure LiteLLM Proxy with a Vertex Veo model, for example:

model_list:
  - model_name: veo-3
    litellm_params:
      model: vertex_ai/veo-3.1-fast-generate-001
      vertex_project: os.environ/VERTEXAI_PROJECT
      vertex_location: os.environ/VERTEXAI_LOCATION
      vertex_credentials: os.environ/VERTEXAI_CREDENTIALS
  # or a wildcard:
  # - model_name: vertex_ai/*
  #   litellm_params:
  #     model: vertex_ai/*
  #     vertex_project: os.environ/VERTEXAI_PROJECT
  #     vertex_location: os.environ/VERTEXAI_LOCATION
  #     vertex_credentials: os.environ/VERTEXAI_CREDENTIALS

2. Generate a video:

curl -X POST "http://localhost:4000/v1/videos" \
  -H "Authorization: Bearer sk-1234" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "veo-3",
    "prompt": "A red ball bouncing once on a white floor",
    "seconds": "4",
    "size": "1280x720"
  }'

3. Poll status and download content using only the returned video_id (as docs show):

curl -X GET "http://localhost:4000/v1/videos/{video_id}" \
  -H "Authorization: Bearer sk-1234"

curl -X GET "http://localhost:4000/v1/videos/{video_id}/content" \
  -H "Authorization: Bearer sk-1234" \
  --output video.mp4

4. Observe status/content fail with vertex_project is required / missing credentials, even when re-passing:

curl -X GET "http://localhost:4000/v1/videos/{video_id}?vertex_project=my-gcp-project&vertex_location=us-central1" \
  -H "Authorization: Bearer sk-1234"

Relevant log output

litellm.APIConnectionError: vertex_project is required for Vertex AI video generation.
Set it via environment variable VERTEXAI_PROJECT or pass as parameter.

File ".../litellm/videos/main.py", line ..., in avideo_status
File ".../litellm/llms/custom_httpx/llm_http_handler.py", line ..., in async_video_status_handler
File ".../litellm/llms/vertex_ai/videos/transformation.py", line ..., in get_complete_url
ValueError: vertex_project is required for Vertex AI video generation.

Related historical form (same family):

google.auth.exceptions.DefaultCredentialsError: Your default credentials were not found.

Root cause notes (optional analysis)

Status/content use resolve_model_name_from_model_id so the router can inject litellm_params (including vertex_project / credentials) from the model config.

PR #18854 fixed this for wildcard models by:

• accepting custom_llm_provider in resolve_model_name_from_model_id
• matching provider-prefixed and wildcard deployments (vertex_ai/*)
• passing provider_from_id from video_status / video_content / video_remix

#18854 was merged into a staging branch on 2026-01-15, then removed by the bulk staging revert the next day (Revert "Litellm staging 01 15 2026"). Those changes are not present on current main:

• resolve_model_name_from_model_id has no custom_llm_provider
• no wildcard Strategy 4 / pattern_router match for video id resolve
• video status/content still call the old single-arg resolver

Requested fix:

1. Re-land fix: video status/content credential injection for wildcard models #18854 (or equivalent) on main
2. Ensure video_status and video_content resolve provider + model and inject the same vertex_project / location / credentials as generation
3. Add regression coverage for generate → status → content on explicit Vertex Veo deployments and wildcard vertex_ai/*

What part of LiteLLM is this about?

Proxy

What LiteLLM version are you on?

v1.86.1

Twitter / LinkedIn details

No response