Rate Limits vs Usage Limits (and 429s)

Last updated 19 September 2026. This page explains claude api rate limit rules versus consumer and API usage / spend limits, what HTTP 429 actually means, and how those differ from Pro, Max, and Team session and weekly bars. Figures below were checked against Anthropic’s Platform rate-limits documentation and Help Center “Our approach to rate limits for the Claude API” on that date. Tiers, model classes, and published ceilings change — confirm on your org’s Claude Console Rate limits page. [VERIFY: 2026-09-19]

Not affiliated with Anthropic. Claude Token Optimization is an independent site and audit service. Claude® and related product names are trademarks of Anthropic PBC. Plan prices, model rates, rate limits, and usage limits change; always confirm on Anthropic’s own docs. [VERIFY: 2026-09-19]

If you searched “claude api rate limit,” “429 retry-after,” or “rate limit vs usage limit,” you probably hit a wall and need the right diagnosis. Rate limits are about how fast you call the API. Usage and spend limits are about how much capacity or money you have left. Consumer chat plans (Pro, Max, Team) mostly show in-product usage bars — not API 429s — unless you are on an API or Claude Code workspace spend path. This spoke keeps those worlds separate so you fix the throttle you actually hit.

What people mean by “rate limit” vs “usage limit”

Searchers often collapse three different ceilings into one phrase. API rate limits are org-level throughput ceilings — requests per minute (RPM), input tokens per minute (ITPM), and output tokens per minute (OTPM) — enforced with a token-bucket that refills continuously. Burst too hard and the Messages API returns HTTP 429 naming which limit you hit, usually with a retry-after header. [VERIFY: 2026-09-19]

Usage / spend limits are capacity or money caps. On consumer and chat plans (Pro, Max, Team) that means session (~5 hour) and weekly included-usage bars — covered in depth on usage limits, Max usage limits, and Team seat limits. On the API, it also means monthly spend caps by tier plus optional org or workspace spend limits you set yourself. Hitting a monthly spend cap can also surface as a 429 — but without retry-after, and with a different error code. [VERIFY: 2026-09-19]

Finally, 529 overloaded is a server-side capacity signal, not your org’s published rate or spend ceiling. Retrying with backoff helps; raising your tier does not fix Anthropic being briefly overloaded. [VERIFY: 2026-09-19]

Comparison at a glance

API rate limits deep dive

Anthropic documents three primary rate-limit metrics for the Messages API. RPM counts requests per minute. ITPM counts input tokens per minute. OTPM counts output tokens per minute. Exceeding any of the three for your model class returns 429 and names the limit that fired. Limits apply per model class separately— you can drive different models up to each class’s ceiling at the same time. That is why a Sonnet-heavy agent fleet can still leave Haiku headroom unused, and why “we need more RPM” is incomplete without naming the model class. [VERIFY: 2026-09-19]

Enforcement uses a token bucket: capacity replenishes continuously rather than as a hard reset at the top of each minute. A published 60 RPM ceiling may behave like roughly one request per second of sustained headroom. Short bursts can still 429 even when your minute-average looks fine on a dashboard that only samples coarsely. [VERIFY: 2026-09-19]

Cache-aware ITPM matters for throughput planning. For most models, only uncached input tokens and cache-creation tokens count toward ITPM; cache_read_input_tokens do not. That means prompt caching raises effective input throughput for the same published ITPM — details and pricing on prompt caching. One notable exception: Haiku 3.5 (retired except on Bedrock/GCP) counts cache-read tokens toward ITPM. [VERIFY: 2026-09-19]

OTPM counts actual generated tokens only. Setting a high max_tokens does not consume OTPM until tokens are produced. Long agent loops and extended thinking still burn OTPM (and bill) as output lands. [VERIFY: 2026-09-19]

Tiers and published ceilings

Standard API tiers are Start, Build, and Scale, plus Custom arranged with an account team. New or limited-history orgs may land in an Evaluation tier with lower ceilings than the standard Start table. View your current tier and live remaining headroom on the Claude Console Rate limits page. [VERIFY: 2026-09-19]

Monthly spend caps by tier (separate from RPM/ITPM/OTPM): Start $500, Build $1,000, Scale $200,000, Custom arranged with no monthly spend cap in the published table. [VERIFY: 2026-09-19]

*Haiku 3.5 counts cache_read_input_tokens toward ITPM; most other models do not. [VERIFY: 2026-09-19]

All three tables are the standard published Messages API ceilings as of verification day. Your Console may show Evaluation or Custom numbers that differ. Workspace-level custom lower limits are also possible (not on the default workspace). [VERIFY: 2026-09-19]

Headers, acceleration, and Batch

Successful and limited responses expose anthropic-ratelimit-*-limit, anthropic-ratelimit-*-remaining, and anthropic-ratelimit-*-reset style headers, plus retry-after when a rate limit 429 fires. Log them. Guessing sleep intervals from minute averages alone is how teams invent phantom outages. [VERIFY: 2026-09-19]

Acceleration limits can still 429 you inside published ceilings if usage spikes sharply. Ramp gradually when you turn on a new agent fleet or overnight backfill. The Message Batches API has separate RPM and processing-queue limits — useful when async latency is acceptable; see Batch API pricing. [VERIFY: 2026-09-19]

Claude Platform on AWS often starts at Start-tier placement; the request-increase flow differs from first-party Console. For cost and placement context, see Claude on Bedrock vs Anthropic API. [VERIFY: 2026-09-19]

When 429 is spend-cap vs rate vs acceleration

Treat every 429 as a branching diagnosis, not a single retry policy:

• Rate-limit 429 — body or headers name RPM, ITPM, or OTPM; retry-after is present. Honor it, then backoff with jitter. Reduce concurrency, shrink tool loops, or spread load across model classes. [VERIFY: 2026-09-19]
• Spend-cap 429 — error_code enforced_spend_limit_reached; no retry-after. Waiting a few seconds will not help until the monthly cap resets or your tier / spend limit is raised. [VERIFY: 2026-09-19]
• User-set spend limit — often returns 400 invalid_request_error instead of 429. Check Console spend settings before rewriting client retry logic. [VERIFY: 2026-09-19]
• Acceleration — you are under published tables but spiking. Slow the ramp; do not immediately request a tier jump. [VERIFY: 2026-09-19]
• 529 — overloaded; exponential backoff. Not a spend or rate-table problem. [VERIFY: 2026-09-19]

Requesting higher limits: use the Claude Console Rate limits page. Anthropic’s Help Center guidance often expects meaningful use of current capacity (commonly cited around ~50% of current limits) before increases land. Details and playbooks: how to increase limits. [VERIFY: 2026-09-19]

Consumer and chat usage limits (pointer)

Pro, Max, and Team included usage is a different product surface. Those plans share session and weekly bars across chat, Claude Code, and Cowork per seat — they do not usually return an API 429 when you empty a bar in the product UI. If the in-app meter is red, read the consumer spokes instead of this API rate-limit table:

• Usage limits — why the same plan feels different week to week
• Max usage limits — 5x / 20x session and weekly bars
• Team seat limits — Standard vs Premium per-member capacity
• Reset schedule — session (~5h) vs weekly account-assigned clocks
• How to check usage — Settings > Usage and related meters

Token pricing for API workloads lives on API pricing; this page stays on ceilings and error semantics, not the rate card. If you are comparing seats versus pay-per-token for product traffic, Pro vs API is the decision spoke — keep rate-limit debugging here, and keep plan-choice math there.

Practical fixes when you are hitting walls

Most teams that live in 429s are mixing three problems: too many concurrent sync calls, input prompts that never get cached, and spend caps they misread as “the API is broken.” Fix the diagnosis first, then apply the cheapest lever that matches it. Raising a tier before you cut waste just buys a larger firehose.

1. Honor retry-after on rate-limit 429s; add jittered exponential backoff. Do not busy-loop.
2. Distinguish spend-cap 429s (no retry-after, enforced_spend_limit_reached) from throughput 429s before you rewrite clients.
3. Turn on prompt caching so cache reads stop eating ITPM on most models — prompt caching guide.
4. Move async work to Message Batches when overnight latency is fine — Batch API pricing.
5. Shrink agents and tool loops — fewer round-trips cut RPM and OTPM together. Start with cut token usage.
6. Request a higher tier only after you are using a meaningful share of current limits and have cleaned waste — increase limits.
7. Watch acceleration — ramp new fleets gradually so spike protection does not look like a permanent ceiling.

Checklist

• Confirm whether the failure is API rate, API spend, user-set spend, consumer usage UI, or 529.
• Read response headers: which limit, remaining, reset, retry-after.
• Check Console Rate limits page for tier, model-class ceilings, and remaining headroom. [VERIFY: 2026-09-19]
• Measure cache-read share before asking for more ITPM.
• Separate sync Messages traffic from Batch queue traffic.
• If the wall is a Pro/Max/Team bar, leave this page and use the consumer usage spokes above.

Related pages

• Usage hub — all meters and limit explainers
• Usage limits — consumer burn patterns
• Max usage limits — Max session / weekly bars
• Team seat limits — seat math
• How to check usage — every meter
• Reset schedule — the two clocks
• Increase limits — request higher API capacity
• API pricing — sync token rates
• Batch API pricing — async 50% path
• Prompt caching — cache-aware ITPM
• Cut token usage — eleven levers
• Audit — written review when 429s and waste pile up (soft CTA; no price on this page)

Get a written look at rate-limit and burn patterns

If your team is bouncing between 429s, spend caps, and consumer usage bars — or you are not sure which ceiling is actually binding — paste a sample of failing requests, headers, and representative prompts into a Claude token audit. You get a written map of throughput vs spend vs product bars, plus concrete changes that usually matter more than another blind tier request. Soft CTA only on this page — no audit dollar price here.