Claude API rate limits and usage tiers, straight

Your organization is placed on a usage tier automatically and moves up over time. Each tier caps monthly spend and per-model requests/tokens per minute. Here's every number, sourced from Anthropic's docs, not estimated.

TierMonthly spend cap
Start$500
Build$1,000
Scale$200,000
CustomNo cap (negotiated)

Hit your spend cap and API usage pauses until next month unless you request a higher limit. You can also self-set a lower spend limit below your tier's cap in Console → Settings → Limits.

Requests/tokens per minute, by tier and model

Limits are set per model class using the token bucket algorithm (continuously replenished, not reset on a fixed clock). Opus 4.5–4.8 share one combined limit; Sonnet 4.5/4.6 share another, separate from Sonnet 5.

ModelStart RPMStart ITPMStart OTPM
Claude Sonnet 51,0002,000,000400,000
Claude Opus 4.x*1,0002,000,000400,000
Claude Haiku 4.51,0002,000,000400,000
Claude Fable 51,000500,000100,000
ModelBuild RPMBuild ITPMBuild OTPM
Claude Sonnet 55,0005,000,0001,000,000
Claude Opus 4.x*5,0005,000,0001,000,000
Claude Haiku 4.55,0005,000,0001,000,000
Claude Fable 52,0001,500,000300,000
ModelScale RPMScale ITPMScale OTPM
Claude Sonnet 510,00010,000,0002,000,000
Claude Opus 4.x*10,00010,000,0002,000,000
Claude Haiku 4.510,00010,000,0002,000,000
Claude Fable 54,0004,000,000800,000

*Opus limit is one combined bucket across Opus 4.8, 4.7, 4.6, and 4.5. Need more than Scale? That's the Custom tier — contact sales, no self-serve path.

Cached tokens mostly don't count against you

The detail that actually changes how you should build: for most models, only input_tokens (post-cache-breakpoint) and cache_creation_input_tokens count toward ITPM — cache_read_input_tokens does not. With a 2,000,000 ITPM limit and an 80% cache hit rate, you can effectively push through 10,000,000 total input tokens/minute (2M uncached + 8M served from cache). Claude Haiku 3.5 is the one exception (marked † in Anthropic's tables) — it counts cache reads toward ITPM like everyone else's naive TPM limit does.

OTPM is metered on tokens actually generated, not on max_tokens — setting a high max_tokens costs nothing extra against this limit if the model stops early.

What else shares or skips the pool

SurfaceLimit behavior
Message Batches APISeparate pool: 1,000–4,000 RPM by tier, plus a 100k–500k queued-batch-request cap — doesn't draw from your Messages API RPM/ITPM/OTPM.
Managed Agents (create)300 requests/min, org-wide, separate from Messages API limits.
Managed Agents (read/list/stream)1,200 requests/min.
inference_geo: "us" vs "global"Same rate-limit pool — data residency changes price (1.1x), not your limit.
Fast mode (Opus 4.7/4.8, research preview)Its own dedicated limit, separate from standard Opus RPM/TPM.

Reading a 429

Every response carries anthropic-ratelimit-requests-remaining, -input-tokens-remaining, and -output-tokens-remaining headers plus matching -reset timestamps (RFC 3339) — poll those instead of guessing. A 429 also returns retry-after in seconds; retrying before that elapses will just fail again. Watch too for acceleration limits: a sharp usage spike can trip a 429 even under your steady-state cap, so ramp traffic up gradually rather than switching a new workload on at full volume.

Model it on your own numbers

Use the full calculator to price the token side once you know your throughput, or see tool use pricing for what web search/code execution add on top of plain tokens, and Batch API pricing if your workload can tolerate async processing instead of live RPM limits entirely.