Skip to content

test(claude_code): pin vertex opus passthrough deployment to the global endpoint - #33552

Closed
mateo-berri wants to merge 2 commits into
litellm_internal_stagingfrom
litellm_vertex_opus_global_passthrough
Closed

test(claude_code): pin vertex opus passthrough deployment to the global endpoint#33552
mateo-berri wants to merge 2 commits into
litellm_internal_stagingfrom
litellm_vertex_opus_global_passthrough

Conversation

@mateo-berri

Copy link
Copy Markdown
Contributor

Relevant issues

Follow-up to #33473, which documented the vertex opus passthrough cell as quota-blocked

Linear ticket

Pre-Submission checklist

Please complete all items before asking a LiteLLM maintainer to review your PR

  • I have added meaningful tests
  • My PR passes all CI/CD checks (e.g., lint, format, unit tests)
  • My PR's scope is as isolated as possible; it only solves 1 specific problem
  • I have received a Greptile Confidence Score of at least 4/5 before requesting a maintainer review (Greptile reviews automatically once the PR is opened; only comment @greptileai to re-request a review after pushing changes)

Delays in PR merge?

If you're seeing a delay in your PR being merged, ping the LiteLLM Team on Slack (#pr-review).

Screenshots / Proof of Fix

No mocks: real claude CLI (2.1.210) against real Google Vertex AI

Before (captured at c4fee0e, in #33473): the vertex opus tier fails persistently while haiku and sonnet answer through the identical path in under 3s; three attempts spanning 490s, every one a token-quota 429

api_error_status: 429 | Quota exceeded for aiplatform.googleapis.com/online_prediction_input_tokens_per_minute...
[retry] claude-opus-4-7-vertex: rate-limit-shaped failure; sleeping 65s before attempt 2/3
[retry] claude-opus-4-7-vertex: rate-limit-shaped failure; sleeping 65s before attempt 3/3

Root cause: the test project's Cloud Quotas grants for online_prediction_input_tokens_per_minute cover every tier regionally except opus-4-7 (haiku-4-5 and sonnet-4-6 have 2M in the test region, opus-4-6 has 4M, opus-4-7 has no regional entry at all, i.e. an effective 0), while the global-endpoint quota family grants opus-4-7 16M input TPM. A ~15-token rawPredict straight at Google confirms it with no CLI or proxy involved: instant 429 RESOURCE_EXHAUSTED regionally, 200 via locations/global

$ curl https://$REGION-aiplatform.googleapis.com/v1/projects/$PROJ/locations/$REGION/publishers/anthropic/models/claude-opus-4-7:rawPredict ...   # 429 RESOURCE_EXHAUSTED
$ curl https://aiplatform.googleapis.com/v1/projects/$PROJ/locations/global/publishers/anthropic/models/claude-opus-4-7:rawPredict ...            # 200 "pong"

After (config at e7ade2e, proxy image from the merged c59963e through the tests/e2e compose stack, same commands as #33473):

docker compose -f tests/e2e/docker-compose.yml -f compose.override.yml up -d   # port 52341
LITELLM_PROXY_BASE_URL=http://localhost:52341 LITELLM_PROXY_API_KEY=sk-multipod-qa \
  python -m pytest tests/e2e/claude_code/passthrough -q
[compat] per-provider breakdown:
  anthropic            pass=3
  azure                fail=3
  bedrock_converse     not_applicable=1
  bedrock_invoke       pass=3
  vertex_ai            pass=3
1 failed, 4 passed in 13.33s

The vertex cell goes 3/3 with zero retry backoffs and the whole passthrough row drops from 498s to 13s. The CLI still sends its placeholder CLOUD_ML_REGION=us-east5 in the URL path, so the pass also proves the proxy substitutes the deployment's global location rather than echoing the client's region. The azure cell stays expected-red on the anthropic-version forwarding gap documented in #33473; it is a separate proxy bug, not part of this change

Type

✅ Test

Changes

Pins vertex_location: global on the claude-opus-4-7-vertex deployment in tests/e2e/claude_code/test_config.yaml. The haiku and sonnet vertex deployments stay on the regional VERTEXAI_LOCATION, which keeps both passthrough URL shapes under test: the regional https://{region}-aiplatform.googleapis.com host and the global https://aiplatform.googleapis.com + locations/global form

QA runbook

  • tests/e2e/claude_code/passthrough/test_vertex_ai.py::test_passthrough_vertex_ai (opus tier) - Claude Code in vertex mode gets an opus reply, with the proxy resolving the alias to the global Vertex endpoint instead of the client's placeholder region
    • Start the proxy: LITELLM_MASTER_KEY=sk-1234 python litellm/proxy/proxy_cli.py --config tests/e2e/claude_code/test_config.yaml --port 4000 with VERTEXAI_PROJECT, VERTEXAI_LOCATION, and Google ADC in the proxy env
    • Run CLAUDE_CODE_USE_VERTEX=1 CLAUDE_CODE_SKIP_VERTEX_AUTH=1 ANTHROPIC_VERTEX_BASE_URL=http://localhost:4000/vertex_ai/v1 ANTHROPIC_VERTEX_PROJECT_ID=anything CLOUD_ML_REGION=us-east5 ANTHROPIC_AUTH_TOKEN=sk-1234 claude --print --model claude-opus-4-7-vertex "Reply with the single word 'pong' and nothing else."
    • Expect a pong reply even though the CLI asked for us-east5, proving the proxy routed to aiplatform.googleapis.com/v1/projects/{project}/locations/global/... from the deployment config
    • Sanity check: this test makes sense to add and is not hand-wavey (e.g., assert actual expected spend instead of just spend > 0) or potentially flaky

Environment prerequisites and nuances are unchanged from #33473; the only new one is that the ADC project needs global-endpoint quota for opus-4-7, which is Google's default grant shape for this model

Final Attestation

  • The tests check the right things, including the edge cases, and regressions in the respective real-world customer use-cases are not possible after this PR

@greptile-apps

greptile-apps Bot commented Jul 16, 2026

Copy link
Copy Markdown
Contributor

Greptile Summary

This PR pins vertex_location: global on the claude-opus-4-7-vertex entry in the e2e test proxy config, working around a Google Cloud quota asymmetry where the test project has zero regional input-TPM quota for claude-opus-4-7 but 16M TPM on the global endpoint.

  • The one-line config change is well-justified and documented with an inline comment explaining both the quota root cause and the intentional design of keeping two Vertex passthrough URL shapes (regional via haiku/sonnet, global via opus) under test simultaneously.
  • No production code is touched; the change is strictly scoped to the e2e test configuration file, and the PR description provides concrete before/after evidence (test run output and raw curl comparisons) showing the fix resolves the 429 quota failures.

Confidence Score: 5/5

Safe to merge — single config line change in an e2e test fixture, no production code affected.

The change is a one-line value swap (os.environ/VERTEXAI_LOCATIONglobal) in an e2e test YAML that never ships to production. It is precisely scoped, well-commented, and backed by concrete curl and pytest output in the PR description. Haiku and sonnet retain the regional env-var path, so the regional URL shape remains exercised; only the opus deployment moves to the global endpoint to match the actual quota grant in the test project. No logic, schema, or API surface is modified.

No files require special attention.

Important Files Changed

Filename Overview
tests/e2e/claude_code/test_config.yaml Pins vertex_location: global for the claude-opus-4-7-vertex deployment to work around a zero-quota regional grant for opus-4-7 in the test project; haiku and sonnet stay regional, keeping both passthrough URL shapes exercised.

Reviews (1): Last reviewed commit: "test(claude_code): pin vertex opus passt..." | Re-trigger Greptile

@codecov

codecov Bot commented Jul 16, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

@codspeed-hq

codspeed-hq Bot commented Jul 16, 2026

Copy link
Copy Markdown
Contributor

Merging this PR will not alter performance

✅ 31 untouched benchmarks


Comparing litellm_vertex_opus_global_passthrough (01cab1a) with litellm_internal_staging (2162da5)1

Open in CodSpeed

Footnotes

  1. No successful run was found on litellm_internal_staging (5ab1601) during the generation of this report, so 2162da5 was used instead as the comparison base. There might be some changes unrelated to this pull request in this report.

@mateo-berri

Copy link
Copy Markdown
Contributor Author

This was already completed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant