Every Claude call on Vertex AI draws from per-minute quota buckets — requests per minute and tokens per minute, scoped by model lineage, location, and project (the full taxonomy is in quota types). Google documents that default maximums "might vary by account and, in some cases, access might be restricted." When your traffic outgrows the defaults, the remedy is a quota increase request, submitted through the Google Cloud console. The requests themselves are easy; the work is in the estimate.
When to request — three triggers
- Before a launch or migration. If your capacity math (below) says peak traffic lands above, say, half of a current limit, file the request during planning. Increases are reviewed by Google, not applied instantly, so treat lead time as nonzero and unpredictable.
- Recurring 429s at known peaks. Occasional throttling under a burst is normal and should be absorbed by retries with backoff (429 handling). Throttling every day at 9 a.m. is a sizing signal.
- A new model family or location. Quota buckets are independent per lineage and per endpoint location. Adding Haiku alongside Opus, or adding an
eumulti-region deployment alongside global, means new buckets that may have small defaults. One helpful exception under the current scheme: for Claude models launched after May 26, 2026, versions within a lineage share one bucket — adding a new version of a family you already use requires no new quota request.
Estimating the headroom you need
You are sizing up to three numbers per lineage per location: requests/minute, input tokens/minute, and output tokens/minute (metered separately on the global endpoint). A workable method:
- Requests per minute: project your peak concurrent users or jobs and multiply by calls per user per minute. Use the busiest realistic minute, not the daily average.
- Input TPM: multiply peak RPM by your typical request's input size — system prompt, conversation history, tool definitions, and documents all count. Measure this with the token counting API rather than eyeballing it; Google explicitly warns that the console quota page's token usage can be inaccurate due to Anthropic's token estimation and refund system, and points to the token counting API and
token_countmetrics in Metrics Explorer for accurate numbers. - Output TPM: peak RPM times realistic output length. Remember thinking output counts as output tokens.
- Add growth margin. Size for the traffic you expect at your next review, not today's. A common practice is requesting comfortably above measured peak so organic growth doesn't trigger a new request every quarter — but justify the number, since large jumps invite scrutiny.
The console workflow
Increases are viewed and requested on the Quotas & System Limits page in the Google Cloud console. In outline: filter to Vertex AI quotas and locate the Claude metric you need — lineage metrics look like global_online_prediction_input_tokens_per_minute_per_base_model with a base_model dimension such as anthropic-claude-opus — check the location matches the endpoint you actually use (global, us, eu, or a region), then submit an edit/increase request with your justification. The requester needs quota-administration permissions on the project; details of the form evolve, so follow the console's current flow and Google's quota documentation.
eu. Match the metric's location to your client's region setting before filing.While you wait — and if the answer is no
Quota requests are not guaranteed. Bridge tactics: shave input tokens with prompt caching and tighter context; cap max_tokens; route lighter traffic to a cheaper, separately quota'd lineage like Haiku; move non-urgent work to Google's Vertex batch prediction for Claude, which is a separate mechanism from live calls. For sustained, predictable high throughput where pay-as-you-go quota keeps pinching, the structural answer is provisioned throughput — reserved capacity purchased through sales rather than requested through the quota page.
Where to go next
Understand the buckets you're sizing in quota types, make throttling survivable with retries and fallbacks, and put the whole thing in a capacity plan with capacity planning.