Quotas on Vertex AI are consumption ceilings that Google enforces per project, per model family, per location, per minute. They exist to protect shared capacity, and they are separate from billing — you can have plenty of budget and still be throttled. For Claude, two dimensions matter most: requests per minute (how many calls you make, sometimes labeled queries per minute or QPM in Google's docs) and tokens per minute (how much text those calls move, abbreviated TPM). A workload with few but enormous requests exhausts TPM first; a chatty workload with short prompts exhausts RPM first.
Model-lineage quotas: the current scheme
For Claude models launched after May 26, 2026, Google uses shared model-lineage quotas: one quota bucket per model family, per location. All Opus versions draw from a shared anthropic-claude-opus bucket, all Sonnets from anthropic-claude-sonnet, and likewise anthropic-claude-haiku and anthropic-claude-fable. Two practical consequences:
- New versions need no new quota request. When a new Opus ships, it draws from the Opus lineage bucket you already have — upgrading models stops being a quota event.
- Versions of one family compete with each other. If one team hammers Opus 4.8 while another runs Opus 4.7, they share one bucket in that location. Splitting model families across teams (or projects) is now the isolation lever.
On the global endpoint, the lineage metrics are global_online_prediction_requests_per_base_model, global_online_prediction_input_tokens_per_minute_per_base_model, and global_online_prediction_output_tokens_per_minute_per_base_model — note that input and output tokens are metered separately.
Per-model quotas: the older scheme
Claude models launched before May 26, 2026 keep the earlier arrangement: quotas per individual model, expressed in QPM and TPM (input + output combined for some models, separated for others), varying by endpoint type. Regional metric names look like online_prediction_requests_per_base_model and online_prediction_tokens_per_minute_per_base_model. If you run a mix of older and newer Claude models, expect to see both schemes side by side on the quota page.
Quota buckets are scoped by endpoint
The global endpoint's quota and each multi-region endpoint's quota are independent buckets — usage on one does not consume the other. Multi-region metrics carry their geography in the name, for example UsOnlinePredictionInputTokensPerMinutePerBaseModel or EuOnlinePredictionRequestsPerMinPerProjectPerBaseModel. This has a legitimate architectural use: a workload pinned to eu for residency does not eat the global-endpoint headroom your other services rely on. There are even separate publisher-scoped buckets for auxiliary features, such as web search requests. See the endpoint decision guide for how to choose.
| Dimension | What varies |
|---|---|
| Metric | Requests/min vs input tokens/min vs output tokens/min |
| Model scope | Lineage bucket (post-May 2026 models) vs per-model (older) |
| Location | Global, us, eu, and specific regions are separate buckets |
| Project | All of the above apply per project — a second project is a second set of buckets |
Reading your actual usage — carefully
You view current limits and usage on the Quotas & System Limits page in the Google Cloud console. One documented caveat: because of Anthropic's token estimation and refund system, the token usage shown on the console quota page may be inaccurate. For numbers you can plan against, Google points you to the token counting API or the token_count metrics in Metrics Explorer instead. Maximum quotas also "might vary by account and, in some cases, access might be restricted" — so never assume your new project's defaults match the ones in your existing project.
max_tokens helps output-TPM, and only a quota increase helps all three.Where to go next
When the buckets are genuinely too small, read requesting a quota increase; for guaranteed capacity, see provisioned throughput. Handling throttling gracefully in code is covered in 429 handling.