The three meters
- RPM, requests per minute. The one everybody expects.
- ITPM, input tokens per minute. The one that catches RAG and long context apps: 20 requests with 100k token contexts is 2 million input tokens in a minute.
- OTPM, output tokens per minute. The one that catches generation heavy apps, and it is typically the tightest of the three.
A 429 tells you which meter you exceeded and includes retry-after. The buckets replenish continuously rather than resetting on the wall clock minute, so short bursts recover fast. Entry tiers start around tens of requests and low hundreds of thousands of input tokens per minute, scaling to thousands of requests and millions of tokens at higher tiers; the spread between tiers is large, which is why the same code behaves completely differently on two accounts.
Getting more throughput without a bigger tier
- Cache the stable context. Cache reads generally do not count against ITPM on current models, so a cached system prompt buys throughput and money at once; the cost side is in prompt caching economics.
- Batch the asynchronous work. The Batch API runs on its own processing queue at half price, taking nightly jobs out of your interactive minute entirely.
- Trim contexts and cap outputs. Every token you do not send or generate is throughput.
max_tokensdiscipline protects OTPM directly. - Handle the 429 properly. Jittered backoff honoring retry-after, and a per feature decision to queue, degrade, or fall back, the mild version of the Claude outage playbook.
The per user truth about rate limits
Here is the pattern we see repeatedly: an app starts throwing 429s, the team debates paying for a higher tier, and the actual cause is one customer. A single integration retrying in a loop, one power user with a script, one agent stuck re reading its own context can consume most of a minute’s tokens, starving everyone else. Aggregate monitoring cannot see this; per user attribution sees it immediately, because the burning account tops every chart. The detection half is agent loop detection, and the enforcement half is per user spending caps that block or downgrade the one account instead of rate limiting everybody.
Weckr ships both: velocity alerts when any user burns tokens abnormally fast, and per plan caps enforced before the call. Teams buy tier upgrades to solve what is actually one runaway user; the cheaper fix is knowing which user it is.
FAQ
How do Anthropic API rate limits work?
Three separate meters per model: requests per minute (RPM), input tokens per minute (ITPM), and output tokens per minute (OTPM). Exceeding any one returns a 429 with a retry-after header. Limits replenish continuously on a token bucket rather than resetting on the minute, and they rise as your organization moves up spend based usage tiers. Your console shows your account’s actual numbers, which override anything an article says.
Why am I getting 429 errors when my request count is low?
Because tokens are limited separately from requests. A handful of calls with huge contexts can exhaust input tokens per minute while barely touching RPM, and long generations can exhaust output tokens per minute. Check which dimension the response headers say you exceeded: the fix for token limits is smaller contexts, caching, or batching, not fewer requests.
Does prompt caching help with rate limits?
Often substantially: cache reads generally do not count against input tokens per minute on current Claude models, so a cache heavy workload gets more effective throughput out of the same tier. That makes caching a throughput tool as well as the cost tool described in our prompt caching economics guide.
How do I raise my Anthropic rate limits?
Tiers advance with cumulative spend and account age, and the console shows your current tier and limits. Beyond standard tiers, higher volume needs come through sales or priority capacity arrangements. The practical near term levers while you wait: caching, moving async work to the Batch API (its own queue), spreading load across minutes, and trimming contexts.
What should my app do when it hits a 429?
Respect retry-after with jittered backoff, never a tight retry loop. Decide per feature whether to queue, degrade, or fall back to another model, the same decision tree as an outage but milder. And find the cause: very often one user or one runaway loop is consuming the whole minute, which is a per user problem wearing an infrastructure costume.
Keep reading
Before buying a tier, find the user
Per user visibility turns most rate limit emergencies into one account conversation. Weckr shows who is consuming your minute and caps them automatically, from two lines of integration. See the loop and velocity views on the live demo, or start with the AI cost and margin guide.