The Anthropic API rate-limits per organization across three metrics — requests per minute (RPM), input tokens per minute (ITPM), and output tokens per minute (OTPM) — with standard limits set by your usage tier (Start, Build, Scale). Exceeding any one returns a 429 with a retry-after header.
Opus 4.x and Sonnet 4.x limits are shared across their respective 4.x versions.
Custom tier (contact sales) removes the spend cap and negotiates limits individually.
Three usual causes: you hit the REQUESTS-per-minute limit rather than tokens; burst enforcement (60 RPM can be enforced as ~1 request/second, so parallel agent calls trip it); or acceleration limits from ramping traffic too fast. The 429 body says which limit fired.
On most current models, no — cache reads are excluded from ITPM and billed at ~10% of input price. Only tokens after the last cache breakpoint plus cache writes count. This makes prompt caching the most effective way to raise your real throughput without a limit increase.
No. Output limits count actual generated tokens in real time, so there is no rate-limit penalty for setting a high max_tokens.
Hitting these limits from an agent? The specific errors have dedicated fixes: Anthropic / Claude rate limit exceeded (429) · Claude Code “usage limit reached” — how to fix · Claude weekly limit — when it resets and how to keep working
And if the limits themselves are the problem: this reference is maintained by Standard Compute, a flat-rate gateway with no RPM, TPM, or daily caps — heavy use is paced, never rejected. How that works →