Claude API Rate Limits: What Breaks First in Production

During a pilot, a handful of users send a few requests an hour and rate limits never come up. At launch, traffic grows quickly and requests start failing with HTTP 429 errors. Knowing which limit you're likely to hit lets you prepare in advance.

How the limits work

Anthropic's API limits apply to your organization and increase as you move up usage tiers. For each model class they usually include:

• Requests per minute (RPM).
• Input tokens per minute (ITPM).
• Output tokens per minute (OTPM).

Exceeding any of them returns HTTP 429 with a retry-after header. The anthropic-ratelimit-* response headers show how much capacity remains. The exact numbers change, so check the rate limits page in the documentation.

Which limit you'll hit first

Output tokens per minute is usually first for agents that write long answers or reports. A few long responses generated at the same time can use up the limit while the request count is still low.

Input tokens per minute is usually first for applications that send large documents or long conversation histories with every request. Twenty users each sending 100,000 tokens adds up quickly. Prompt caching helps, and on many current models cached tokens are treated favorably for rate limits, so check the documentation for your model.

Requests per minute is usually first for designs that make many small calls for each user action.

HTTP 529 is different: it means the API is temporarily overloaded, not that you've hit your limit. Your retry logic should handle it too.

Designing for the limits

1. Retry with exponential backoff and jitter. The official SDKs retry 429 and server errors automatically, twice by default. Adjust max_retries to suit your traffic.
2. Queue background work. Tasks that users aren't waiting for should go through a queue with limited concurrency.
3. Use the Batch API for bulk jobs. Batches run asynchronously at half the standard price and keep bulk work separate from interactive traffic.
4. Make requests smaller. Trim context, summarize long histories and set sensible max_tokens values.
5. Separate workloads. Use different workspaces for production and experiments so testing can't affect customers.

Load test before launch

Replay realistic traffic at two to three times your expected peak. Note which limit is reached, at what level of concurrency, and how the application responds. Users should see a clear message, not an error page.

Things to watch

• Retries add traffic. Without jitter, many clients retry at the same moment.
• Monitor the rate of 429 responses as a real metric.
• Ask for a limit increase well before launch.

Load test a week before launch, not the night before.