Anthropic API Rate Limits: How They Are Measured and How to Work Within Them

Most teams meet rate limits the same way: something worked fine in development, went to production, and started returning 429 responses under real concurrency. The fix is rarely "ask for more capacity." It is usually understanding which of several separate limits is binding, because they are measured differently and are relieved by different changes.

Three limits, measured separately

Anthropic's API enforces limits along more than one axis at once. A request is rejected when it would exceed any of them.

Requests per minute. How many API calls the organisation may start in a rolling minute. This is the limit that a burst of small requests hits first — it does not care how large each one is.

Input tokens per minute. The volume of prompt content accepted per minute. Long-context workloads hit this well before they hit the request limit. A workflow sending one very large prompt per call can exhaust it with a handful of calls.

Output tokens per minute. The volume of generated content per minute. Long-form generation and agentic loops that produce large diffs are the usual cause.

The practical consequence: two applications making the same number of calls can have completely different limit behaviour, because one sends 2,000-token prompts and the other sends 150,000-token prompts. When you are diagnosing 429s, the first question is which axis is saturated, not how many requests you sent.

Limits are per organisation and scoped per model, and they rise with usage tier — tiers advance based on payment history and cumulative spend rather than on request. Because the exact ceilings change, treat published numbers as current-at-time-of-reading and verify against your own account's limits page before designing around a specific value.

Reading the response

A rejected request returns HTTP 429. Two things in the response matter more than the status code:

• The retry-after header tells you how long to wait. Honouring it is more effective than a fixed backoff, because it reflects the actual window rather than your guess about it.
• The error message names the limit that was exceeded — requests, input tokens, or output tokens. This is the single most useful diagnostic in the whole exchange, and it is routinely discarded by client code that only logs the status.

Responses also carry headers describing remaining capacity in the current window. Logging these alongside your own request metrics turns limit debugging from guesswork into arithmetic.

What actually fixes each case

If requests per minute is binding: reduce call count rather than call size. Batch independent items into fewer calls where the task allows it. Add a client-side concurrency cap so parallel workers cannot collectively exceed the ceiling — an unbounded worker pool will find the limit every time.

If input tokens per minute is binding: this is where prompt caching does the most work. Agentic and RAG workloads resend a large stable prefix on every turn; a cached prefix is both cheaper and lighter against the input-token axis. Beyond caching, trim what is genuinely resent — full file contents that have not changed, conversation history past its useful life, retrieved chunks that did not inform the answer.

If output tokens per minute is binding: cap max_tokens to what the task actually needs rather than leaving headroom "just in case," and split long generations into stages. A single request allowed to generate 8,000 tokens when 800 would do consumes ten times the budget for the same result.

Retry behaviour worth shipping

Exponential backoff with jitter, honouring retry-after when present, capped at a maximum delay and a maximum attempt count. Two details are commonly missed and both cause outages:

Jitter is not optional. Without it, every client that failed in the same second retries in the same second, and the retry storm re-creates the condition that caused the failure.

Distinguish 429 from 529. A rate limit is your traffic against your ceiling and is fixed by pacing. An overloaded response is a capacity condition upstream and calls for a longer, more patient backoff rather than aggressive retrying.

Requests that are not latency-sensitive belong in the Message Batches API instead, which is processed asynchronously with its own separate capacity — moving background work there frees the interactive path.

The layer people forget

If requests go through a gateway or relay endpoint rather than directly to Anthropic, there are two sets of limits in play: the upstream account's, and whatever the intermediate endpoint enforces for its own users. A 429 can originate from either, and the error body is how you tell them apart. When evaluating an endpoint, ask what its own per-key limits are, whether prompt caching is supported end-to-end, and whether limit headers are passed through — an endpoint that strips them removes your ability to pace intelligently. What an LLM API gateway does covers where that layer helps and where it adds a failure mode.

Cost and rate limits also interact: the same caching that reduces the bill reduces input-token pressure. Claude API pricing covers the billing side of the same mechanism.

Frequently asked questions

Why am I rate limited when I am sending very few requests?

Almost certainly the input-token axis. A small number of long-context calls can exceed the token-per-minute ceiling while the request count stays low.

How do I raise my limits?

Limits scale with usage tier, which advances on payment history and cumulative spend. There is no per-request override for standard tiers; organisations with sustained high-volume needs negotiate capacity directly.

Does prompt caching help with rate limits or only with cost?

Both. Cached prefix content is cheaper and also counts differently against input-token throughput, which is why caching is the highest-leverage change for long-context workloads.

What is the difference between a 429 and a 529?

429 means your traffic exceeded your limit — pace yourself. 529 means the service is overloaded — back off longer and retry more patiently. Treating them identically makes the second one worse.

Should background jobs use the same path as interactive requests?

No. Asynchronous batch processing has separate capacity, so moving non-urgent work there protects the interactive path from competing with it.