Anthropic rate limits explained: tiers, spend caps, 429s

You get a 429 from Claude while the Console still shows a positive balance. Or Claude Code stops in the middle of a task and tells you to come back in a few hours. Both get called "Anthropic rate limits", but they come from two separate systems, and the fix for one does nothing for the other.

This is the picture as Anthropic documents it in October 2026. An earlier version of this post showed the old Tier 1 to Tier 4 ladder, which Anthropic has since replaced. It also credited kRouter's v0.5.47 and v0.5.49 changes to Anthropic handling; those changes were about Google's Antigravity errors. Both are corrected below.

Two systems, not one

The Claude API is what you use with an API key from the Claude Console. It is billed per token, and each organization has rate limits and a monthly spend cap.

A Claude subscription (Pro or Max) is what claude.ai and Claude Code use when you sign in with your Claude account. It has usage limits instead: a session limit that resets every five hours, and a weekly limit across all models. Anthropic's help center says these limits are shared across Claude and Claude Code, so a long chat in the browser eats into the same allowance as your agent.

A subscription is not an API key. Paying for Pro or Max does not raise your API limits. When a plan runs out you can choose to continue on API credits, but that usage is billed at standard API rates.

The API limits, one axis at a time

For the Messages API, Anthropic measures three rate limits per model class:

1. Requests per minute (RPM)
2. Input tokens per minute (ITPM)
3. Output tokens per minute (OTPM)

Exceed any one of them and you get a 429 that names the limit, with a retry-after header saying how long to wait. Headroom on the other two does not help.

Three details change how these behave in practice.

It is a token bucket, not a minute clock. Capacity refills continuously up to your maximum instead of resetting on the minute, and a per-minute limit can be enforced over shorter intervals. Anthropic's own example is 60 RPM applied as one request per second. A burst can trip a limit that your per-minute average never reaches.

Cache reads do not count toward ITPM on most models. Only input_tokens (the tokens after the last cache breakpoint) and cache_creation_input_tokens count; cache_read_input_tokens do not. For an agent that resends a long conversation every turn, a stable cached prefix is the difference between hitting ITPM constantly and hitting it rarely. Anything that rewrites the earlier part of the prompt between turns breaks the cache, and every turn then counts in full.

OTPM counts what the model actually writes. max_tokens is not part of the calculation, so lowering it does nothing for an OTPM 429.

Limits are also set per model class. Sonnet 4.6 and Sonnet 4.5 share one Sonnet 4.x limit; Opus 4.8, 4.7, 4.6 and 4.5 share one Opus 4.x limit; Sonnet 5.5 and Opus 5.5 each have their own. Work sent to a model in a different class draws on separate headroom.

Finally, Anthropic applies acceleration limits: an organization whose usage rises sharply can get 429s while still under its tier's numbers. The documented advice is to ramp traffic up gradually and keep usage patterns consistent.

The tiers

Organizations are placed on a tier automatically, based on usage history and account standing. New organizations may start in an Evaluation tier with lower limits than the table below. These are Anthropic's published standard limits for the Sonnet 4.x class:

Your real tier and limits are on the Rate limits page in the Claude Console, which is also where you request an increase. Check that page rather than trusting any table, this one included; the numbers change. The source is Anthropic's rate limits documentation.

The spend cap looks like a rate limit, and is not one

When an organization reaches its tier's monthly spend cap, the API also returns a 429 rate_limit_error. Three things give it away:

• There is no retry-after header.
• The body carries "error_code": "enforced_spend_limit_reached" and a message naming the date access returns.
• Access resumes at 00:00 UTC on the first day of the next month, or sooner if you move to a higher tier.

Retrying, including the SDK's automatic retries, fails until then. A spend limit that you set below the cap behaves differently again: it returns a 400 invalid_request_error whose message begins "You have reached your specified API usage limits".

A 529 overloaded_error is not your limit at all. It means the API is under heavy load across all users. The Claude Code 529 guide covers that one.

The subscription side: five hours and a week

Pro and Max limits work differently from the API. The session limit resets every five hours. The weekly limit applies across all models and resets at a fixed time each week that is assigned to your account. Anthropic does not publish fixed message counts: how far a session goes depends on message length, attachments, the length of the conversation and the model.

That last point is why Claude Code drains a plan faster than chat does. Every tool call and file read resends the growing conversation, so one agent turn can weigh as much as many chat messages. If the weekly limit is the one you hit, waiting a few hours changes nothing; Claude Code weekly limit reached covers what to do instead.

What does not work

Retrying immediately. Anthropic's description of retry-after is blunt: earlier retries will fail. A tight retry loop only produces more 429s.

A second API key in the same organization. Limits belong to the organization. Every key in it draws from the same bucket.

Waiting a minute on a spend-cap 429. Nothing resets until the month turns or your tier changes.

Lowering max_tokens. It is not part of the OTPM calculation.

What kRouter does with an Anthropic 429

If you route Claude through kRouter, this is how current releases (v0.5.163) handle it:

• When the response says when to retry, kRouter reads retry-after and Anthropic's anthropic-ratelimit-tokens-reset and anthropic-ratelimit-requests-reset headers, takes the earliest reset, and parks that model on that account until then, for six hours at most. The request moves on to your next account or combo entry instead of waiting.
• When it does not, as with the spend-cap 429, kRouter uses an exponential cooldown that starts at 2 seconds and doubles up to 5 minutes. Once it reaches that ceiling, a capped organization gets one attempt every five minutes, and each fails until the month turns. Put a second backend after it so those requests have somewhere to go.
• Overloaded responses (529) get the same backoff and move on to the next account or entry.
• Cooldowns are written in one SQLite transaction. The current backoff level is read and the new one written inside the same transaction, so two requests failing at the same moment cannot both read level N and both write N+1. While an account is cooling down the picker skips it, so concurrent and new requests go elsewhere instead of piling onto the account that just refused them. Cooldowns live in the database, so a restart does not put a refused account straight back into rotation.

The full list of what kRouter does for each kind of error is in When kRouter moves on.

How to engineer around it

1. Cache the stable part of the prompt. This is the cheapest fix available, because cache reads do not count toward ITPM on most models. Keep the system prompt, tool definitions and earlier turns identical from one request to the next.

2. Ask for a higher tier. Use Request rate limit increase on the Console's Rate limits page. It is the only way to raise a single organization's ceiling.

3. Spread the load across organizations. In kRouter, connect more than one account to the Anthropic provider and set that provider's strategy to round-robin, so requests rotate instead of draining one account first. A connection only adds headroom if its key belongs to a different organization, and each organization brings its own billing and its own starting tier, possibly the Evaluation tier. Read Anthropic's usage policy before you split one workload across organizations to get past its limits; routing through kRouter does not change a provider's terms. The same applies to Claude subscriptions, which kRouter's dashboard marks with a risk notice because a subscription session is not licensed for proxy use.

4. Fall back to a different model. A combo tries its entries in order and moves to the next when one is rate limited:

1. anthropic/claude-sonnet-5-5
2. anthropic/claude-sonnet-4-6   # a separate Sonnet 4.x limit
3. glm/glm-5.3                   # different provider, pay per token

kRouter cools down the model that failed, not the whole account, so entry 2 can still use the same Anthropic key. Your tool sees an error only when every entry has failed. Whether a model from another provider is good enough for a given task is something to test on your own work; nothing here claims it is equivalent.

Common questions

Why do I get a 429 from Claude when I still have credits?

Credits and rate limits are separate. A 429 with a retry-after header is a per-minute limit (RPM, ITPM or OTPM) and clears within the time the header gives. A 429 with no retry-after and the error code enforced_spend_limit_reached is the monthly spend cap, and it lasts until the first day of the next month unless your tier changes.

Do cached tokens count toward Anthropic's rate limits?

For most current models, no. Tokens read from the cache are excluded from ITPM; only uncached input and tokens being written to the cache count. That makes prompt caching the most effective way to get more throughput out of the same tier.

Does Claude Pro or Max raise my API rate limits?

No. A subscription has its own usage limits, a five-hour session and a weekly cap shared between claude.ai and Claude Code. API limits belong to your Console organization and its tier.

Will a second API key double my limit?

Not if it is in the same organization. Rate limits and spend caps are enforced per organization, so every key in it shares one pool.

Can a router get around Anthropic's limits?

No. A router can stop retrying an account that has been told to wait, move requests to other accounts or models, and keep your tool working while that happens. Every limit still applies to every account it sends traffic to.

Related

• Claude Code "rate limit exceeded": every cause and the fix
• Claude Code weekly limit reached
• Rate limit errors reference