Most teams discover their quota ceiling the hard way: real traffic arrives, 429 errors spike, and someone files an urgent increase request that takes days to process. The avoidable part is the surprise. A launch-readiness quota estimate needs only three measurements — peak requests per minute, average input tokens per request, and average output tokens per request — and a comparison against what your platform grants by default.
The estimating formula
At peak load:
Required output TPM = peak requests/minute × average output tokens per request.
Required RPM = peak requests/minute. Then add headroom — traffic estimates made before launch are always wrong in the optimistic direction.
Peak matters more than average. Rate limits are enforced per minute, so a workload that averages 100 requests/minute but bursts to 600 at 9 a.m. must be planned at 600. If you have no traffic history, derive peak from concurrency: the number of users or jobs active simultaneously, times requests each generates per minute.
For the token figures, measure rather than guess. The token-counting endpoint is free (it has its own separate request limits) and accepts exactly what you plan to send — system prompt, tools, documents included:
from anthropic import AnthropicVertex
client = AnthropicVertex(project_id="my-project", region="global")
count = client.messages.count_tokens(
model="claude-sonnet-5",
system=SYSTEM_PROMPT,
messages=[{"role": "user", "content": representative_request}],
)
print(count.input_tokens) # multiply by peak RPM for required ITPMCount against the model you will actually run: Opus 4.7 and later, Fable 5, and Sonnet 5 use a newer tokenizer that produces roughly 30% more tokens than earlier models for the same text, so numbers measured on an older model understate what the new one will consume (see the tokenizer's quota impact). Two accounting details also shift the math: cache writes count toward input-token limits while cache reads generally do not, and on the Claude API a generous max_tokens is free — but on Bedrock's current surface, input tokens plus max_tokens are reserved against quota upfront.
Compare against platform defaults
With the requirement in hand, look up what you get by default. All of the following numbers are published by the vendors and are subject to change — treat them as illustrations and confirm on the live documentation.
Claude API: limits scale with usage tier. At the Start tier, the Opus, Sonnet 5, and Haiku 4.5 classes each get 1,000 RPM / 2M ITPM / 400K OTPM (Fable 5 is lower: 1,000 / 500K / 100K); the Scale tier reaches 10,000 RPM / 10M ITPM / 2M OTPM. Organizations move up tiers automatically over time — but a brand-new org launching big starts at Start.
Claude Platform on AWS: the same limit schedule, but organizations stay on the Start tier with no automatic movement; contact Anthropic to raise limits.
Amazon Bedrock: Anthropic's docs describe a default of 2M input TPM for Claude in Amazon Bedrock, expandable to 4M without additional Anthropic approval, with AWS enforcing RPM separately. AWS's own bedrock-mantle quota table lists Claude Opus 4.7 at 20M input TPM / 4M output TPM — the two published figures differ, so verify your account's actual allocation rather than assuming either.
Vertex AI: newer Claude models draw from shared per-lineage quota buckets whose maximums "might vary by account"; view yours on the console's Quotas & System Limits page rather than relying on published tables.
Microsoft Foundry: the gap most likely to bite. Default pay-as-you-go limits are 40 RPM / 40,000 ITPM for Opus-family and Sonnet 5 models (80 / 80,000 for Sonnet 4.6/4.5 and Haiku 4.5, and Fable 5 defaults to zero on pay-as-you-go). Enterprise agreements raise these to the thousands-of-RPM range. A production workload on a default Foundry subscription almost certainly needs an increase first.
Close the gap through the right channel
Each platform has a different escalation path: automatic tier progression or sales contact on the Claude API, the Service Quotas console for adjustable Bedrock runtime quotas versus an AWS Support case for bedrock-mantle, the Quotas & System Limits page on Google Cloud, and Microsoft's quota-increase request form for Foundry. Increases take time and, on some platforms, favor accounts already consuming their allocation — another reason to file before launch, backed by the arithmetic above. If the gap is large, also consider offloading to batch and prompt caching, which shrink the requirement instead of raising the ceiling.
Where to go next
Work out which limit binds first, then plan the launch itself around acceleration limits. The platform overview summarizes the four routes to Claude.