Claude API Rate Limits — What to Know

Claude api rate limits are enforced per organization, per model, along three axes: requests per minute (RPM), input tokens per minute (ITPM), and output tokens per minute (OTPM). Exceed any one of them and the API returns a 429 with a retry-after header telling you exactly how long to wait. Your ceilings depend on your usage tier, and — the part most developers miss — cached input tokens don’t count against your input limit at all, which changes how you should architect high-volume apps.

TL;DR: Limits are per model and per tier (Start, Build, Scale, Custom), measured in RPM, input TPM, and output TPM. A 429 carries a retry-after header, and the official SDKs retry automatically. Cache reads don’t count toward input limits, so prompt caching effectively multiplies your quota. For bulk work, the Message Batches API has its own separate limits.

How Claude API Rate Limits Actually Work

Anthropic uses a token bucket algorithm: your capacity replenishes continuously up to the maximum rather than resetting on a fixed clock. That means a 1,000 RPM limit behaves more like “up to ~16 requests per second, sustained” — short bursts above that rate can trigger 429s even though your per-minute average looks fine. In my own testing, spiky cron-style traffic hits limits far more often than the same volume spread evenly.

Three separate meters run at once for every model:

• RPM — raw request count, regardless of size.
• ITPM — uncached input tokens plus cache writes. Cache reads are free against this meter on current models.
• OTPM — actual output tokens generated. Your max_tokens setting doesn’t count against it, only what the model really produces.

Limits are also per model, so Sonnet and Haiku traffic draw from independent pools — with one caveat: all Opus 4.x versions share a single combined bucket, while Sonnet 5 gets its own separate from Sonnet 4.x. These are API-side quotas, distinct from the message caps on claude.ai subscriptions, which I covered in Claude AI token limits explained.

The Usage Tier System

Organizations are placed into a tier automatically and move up as their API usage history grows. Older write-ups (and plenty of forum posts) refer to numbered tiers 1 through 4; the Console now labels them Start, Build, Scale, and Custom. Each tier pairs rate limits with a monthly spend cap:

Tier	Monthly spend cap	How you get there
Start	$500	Default for new organizations
Build	$1,000	Automatic advancement with usage
Scale	$200,000	Automatic advancement with usage
Custom	No cap	Arranged with Anthropic’s sales/account team

You can see your current tier, limits, and remaining headroom on the Limits page of the Claude Console, and request an increase from the same screen. Hitting the spend cap pauses API usage until the next month — worth knowing before it surprises you in production. Spend planning goes hand in hand with this; the Claude API pricing guide covers what each token actually costs.

Rate Limits by Model and Tier

Here are the standard published limits at the entry (Start) tier, per the official rate limits documentation:

Model (Start tier)	RPM	Input TPM	Output TPM
Claude Fable 5	1,000	500,000	100,000
Claude Opus 4.x (combined)	1,000	2,000,000	400,000
Claude Sonnet 5	1,000	2,000,000	400,000
Claude Sonnet 4.x (combined)	1,000	2,000,000	400,000
Claude Haiku 4.5	1,000	2,000,000	400,000

Higher tiers raise everything substantially. At Build, most models get 5,000 RPM / 5M input TPM / 1M output TPM (Fable 5: 2,000 / 1.5M / 300K). At Scale, that becomes 10,000 RPM / 10M input TPM / 2M output TPM (Fable 5: 4,000 / 4M / 800K). The Message Batches API runs on its own meters — 1,000 to 4,000 RPM depending on tier, up to 500,000 queued batch requests, and a maximum of 100,000 requests per batch. Fast mode on Opus also has dedicated limits separate from standard Opus traffic.

Handling 429 Errors and the retry-after Header

A rate-limited response tells you which limit you tripped and when to come back. The useful headers:

Header	Meaning
retry-after	Seconds to wait; earlier retries fail
anthropic-ratelimit-requests-remaining	Requests left before a 429
anthropic-ratelimit-input-tokens-remaining	Input tokens left (rounded to nearest 1,000)
anthropic-ratelimit-output-tokens-remaining	Output tokens left
anthropic-ratelimit-*-reset	RFC 3339 time when each meter fully refills

The official SDKs already retry 429s (plus 5xx and connection errors) twice with exponential backoff, honoring retry-after. For queue workers I usually add one explicit outer layer on top:

import time
import anthropic

client = anthropic.Anthropic(max_retries=4)

def create_with_backoff(**kwargs):
    for attempt in range(5):
        try:
            return client.messages.create(**kwargs)
        except anthropic.RateLimitError as e:
            wait = float(e.response.headers.get("retry-after", 2 ** attempt))
            time.sleep(wait)
    raise RuntimeError("still rate limited after 5 attempts")

One more source of 429s: acceleration limits. If your traffic ramps sharply — say a launch-day spike — you can get throttled even below your printed quota. Anthropic’s guidance is to ramp gradually and keep usage patterns consistent. Setup details for the client itself are in the Claude API Python guide.

Strategies to Stay Under Your Limits

1. Cache your prompts. Cache reads don’t count toward input TPM on current models. With a 2M ITPM limit and an 80% cache hit rate, you can effectively push 10M total input tokens a minute. Cache system prompts, tool definitions, and long documents.
2. Move bulk work to the Batches API. Anything that doesn’t need a real-time answer — evaluations, backfills, nightly enrichment — belongs in Message Batches, which has separate, generous queue limits and costs less per token.
3. Split traffic across models. Each model has its own pool. Routing lightweight classification to Haiku 4.5 keeps your Sonnet or Opus quota free for the hard requests.
4. Smooth your burst profile. A client-side concurrency cap (a semaphore or queue) converts spikes into a steady stream the token bucket tolerates.
5. Set workspace limits. Per-workspace caps stop one internal tool from starving the rest of your org.
6. Request an increase. If you consistently run near the ceiling, use the request form on the Console Limits page — moving up a tier is routine for growing products.

What People Get Wrong About Rate Limits

• Treating max_tokens as spend. Output limits count tokens actually generated, so there’s no rate-limit penalty for setting a generous max_tokens.
• Assuming one global limit. Limits are per model — a Sonnet 429 says nothing about your Haiku headroom.
• Retrying instantly in a loop. Retries before retry-after expires fail and prolong the throttle. Honor the header.
• Ignoring cache economics. Teams request tier increases when a cache breakpoint on their system prompt would have freed most of their input quota.
• Confusing API limits with claude.ai limits. Subscription message caps and API rate limits are completely separate systems.

FAQ

Next Steps

Rate limits define your throughput ceiling; cost defines whether you want to reach it. Once you know your tier, run your workload numbers through the Claude API cost calculator to see what full utilization would actually cost, and keep the Claude API hub bookmarked for the rest of the series.