Rate limits on Claude come in two currencies. Requests per minute (RPM) caps how often you can call the API, regardless of size. Tokens per minute (TPM) caps how much text flows through, regardless of call count. On the Claude API, the token side is actually split in two — input tokens per minute (ITPM) and output tokens per minute (OTPM) — and all limits are enforced per organization, per model. Your workload will exhaust exactly one of these first, and knowing which one changes everything about how you respond.
The break-even calculation
Divide your token limit by your request limit. The result is a break-even number: the average tokens per request at which both ceilings are reached simultaneously. If your real requests are smaller than that number, RPM binds first. If they are larger, TPM binds first.
Take the documented Start-tier limits on the Claude API for the Opus, Sonnet 5, and Haiku 4.5 model classes — 1,000 RPM and 2,000,000 ITPM (these figures come from Anthropic's rate-limits documentation and are subject to change; always check the live page). The break-even is 2,000,000 ÷ 1,000 = 2,000 input tokens per request. A chatbot sending 800-token prompts will hit 1,000 RPM long before it dents the token budget. A document-analysis pipeline sending 40,000-token prompts will exhaust ITPM at just 50 requests per minute — one twentieth of its nominal RPM allowance.
Run the same division on the output side. The Start tier pairs 1,000 RPM with 400,000 OTPM, a break-even of 400 output tokens per request. Workloads that generate long answers — reports, code files, summaries of summaries — are frequently OTPM-bound even when their prompts are short. Note that on the Claude API, OTPM counts only tokens actually generated; a high max_tokens setting carries no rate-limit penalty by itself.
The same arithmetic on each platform
The two-ceiling structure appears everywhere, but the units differ by platform — which changes what you divide.
| Platform | Limit structure |
|---|---|
| Claude API / Claude Platform on AWS | RPM + ITPM + OTPM per model (Claude Platform on AWS uses the same limits but stays on the Start tier) |
| Bedrock (legacy bedrock-runtime) | Per-model TPM counting input and output together, plus per-model RPM — though some models (e.g. Opus 4.7/4.8) have no RPM quota and are governed by tokens alone |
| Bedrock (current bedrock-mantle surface) | Separate input-TPM and output-TPM quotas per model; no RPM quota enforced |
| Vertex AI | Requests-per-minute and tokens-per-minute quota metrics per model lineage (Opus, Sonnet, Haiku, Fable each have their own bucket for newer models) |
| Microsoft Foundry | RPM plus uncached ITPM per model, shared across a subscription; output tokens and cache reads do not count toward ITPM |
Two platform quirks matter for the math. On Bedrock's legacy runtime endpoint, TPM counts input and output together, so your average tokens per request must include the response. On the current bedrock-mantle surface there is no RPM quota at all — every workload there is token-bound by definition, and admission control reserves your input tokens plus max_tokens upfront, so an inflated max_tokens does consume quota headroom there, unlike on the Claude API.
Each constraint demands a different fix
If RPM binds first, more tokens per request are effectively free. Consolidate: merge several small classification calls into one batched prompt, widen pagination, or move fire-and-forget work to batch processing, which on the Claude API draws from a completely separate rate-limit pool. Asking for a token-quota increase will not help you at all.
If TPM binds first, request count is the free resource and tokens are precious. Trim prompts, enable prompt caching (on the Claude API and bedrock-mantle, cache reads are excluded from input-token limits — see how caching multiplies effective TPM), route simpler traffic to a model with its own quota pool, or file a quota-increase request in the right channel for your platform.
Because the two fixes are nearly disjoint, running the break-even division before launch — as part of estimating required quota from workload shape — saves you from optimizing the wrong ceiling under production pressure.
Where to go next
See how token buckets replenish for the mechanics behind these limits, or start from the quotas overview and the platform comparison.