Claude API — Rate limits

Anthropic's reference for how the Claude API caps an organization's usage. Routed here on 2026-06-28 from the hub: the provider-API-access lens (alongside claude-refusals-and-fallback and llm-api-pricing). The standout for this wiki is cache-aware ITPM — a rate-limit rule that turns prompt caching from a discount into a throughput multiplier.

Two limits, set at the org level

• Spend limits — a maximum monthly cost, billed per calendar month. Tiered caps: Start $500 · Build $1,000 · Scale $200,000 · Custom none (arranged with the account team). Hit the cap and usage pauses until next month unless you request more. You can also set a lower self-limit under your tier's cap.
• Rate limits — RPM / input-tokens-per-minute (ITPM) / output-tokens-per-minute (OTPM), per model class, enforced at the org level. Exceed one and you get a 429 naming which limit blew, with a retry-after header.

Tier placement is automatic and rises with usage over time. Limits use the token-bucket algorithm — capacity replenishes continuously rather than resetting on a fixed clock — so a "60 RPM" allowance behaves like ~1 request/second and short bursts can still trip a 429. A separate acceleration limit fires on sharp usage spikes, so the docs advise ramping traffic gradually.

Cache-aware ITPM — the cost/throughput hook

Unlike a flat "tokens per minute" cap, only uncached input tokens count toward ITPM on most Claude models:

• input_tokens (after the last cache breakpoint) → counts
• cache_creation_input_tokens (writing to cache) → counts
• cache_read_input_tokens (reading from cache) → does NOT count (except Claude Haiku 3.5, marked † in the tables, which does count cache reads)

So caching does double duty: cache reads are billed at ~10% of input price and don't consume rate limit. The docs' example: a 2,000,000 ITPM limit at an 80% cache-hit rate effectively processes 10M total input tokens/minute (2M uncached + 8M cached). OTPM, by contrast, counts only tokens actually generated — max_tokens doesn't factor in, so setting it high carries no rate-limit penalty.

The tier tables (re-read 2026-08-30 — volatile)

Per-model RPM / ITPM / OTPM. Opus 5 and Sonnet 5 each carry their own bucket; Opus 4.x and Sonnet 4.x each share one combined limit across their point releases (Opus 4.8/4.7/4.6/4.5; Sonnet 4.6/4.5), and Claude 5 traffic does not draw from those pools.

Above Scale is Custom (contact sales). Below Start there is now an Evaluation tier: new organizations, and those with little usage history, start under the standard limits and are raised automatically as history accumulates — an anti-fraud measure, and a fact worth knowing before benchmarking a new account against these numbers. Limits are per-model, so different models draw from separate pools simultaneously. Rate limits are currently shared across inference_geo values (us and global draw from one pool). Claude Haiku 3.5 is retired except on Bedrock and Google Cloud.

The premium tier is also the throttled one. Fable 5 gets a quarter of Opus 5's ITPM at every tier — 500K against 2M on Start, 1.5M against 5M on Build, 4M against 10M on Scale — and half the RPM on Build and Scale. This spoke has spent four sources establishing that Fable 5 is the family's expensive tier ($10/$50, twice Opus 5); the rate card is only half of it. The model Anthropic places above its own flagship on intelligence is the one you can push the least traffic through, which is a capacity statement rather than a pricing one, and it lands the same way Cerebras's sold-out coding tiers did: the fast or frontier thing is rationed, not merely priced.

Separate limit pools

• Message Batches API — its own RPM (1,000 / 2,000 / 4,000 by tier) plus caps on batch requests in the processing queue (200K / 300K / 500K) and per batch (100K).
• Managed Agents — 300 RPM create / 1,200 RPM read, separate from the Messages API.
• Fast mode (speed: "fast", research preview) — dedicated limits separate from standard Opus, surfaced via anthropic-fast-* headers. Corrected 2026-08-30: this page previously listed the supported models as Opus 4.8/4.7/4.6. The docs now say Opus 5 or Opus 4.8; Opus 4.7 returns an error, and claude-opus-4-6 with speed: "fast" runs at standard speed rather than failing — a silent no-op, which is the failure mode a developer would not notice.
• Files API — its own per-organization limit, shared across upload, list, retrieve, download and delete, separate from the Messages API.
• The Claude Code workspace is checked separately, and requests over its limit can return a 429 carrying retry-after rather than the spend-cap shape below.

Response headers & workspaces

Every response carries anthropic-ratelimit-{requests,tokens,input-tokens,output-tokens}-{limit, remaining,reset} (reset in RFC 3339), plus retry-after and Priority-Tier variants. The tokens-* headers report the most restrictive limit currently binding. Orgs can also set per-Workspace spend/rate limits below the org cap to stop one workspace starving the rest (org-wide limits always dominate; the default workspace can't be limited).

Two different 429s, and only one is a rate limit

Added 2026-08-30, because the distinction is easy to get wrong in code. Hitting the monthly spend cap also returns HTTP 429 with "type": "rate_limit_error" — but it carries no retry-after header, so SDK auto-retries fail until 00:00 UTC on the first of the next month. The tell is error.details.error_code == "enforced_spend_limit_reached". A self-set spend limit below the tier cap behaves differently again: HTTP 400, invalid_request_error, message beginning "You have reached your specified API usage limits."

Platform caveat

On Claude Platform on AWS: rate limits here apply; orgs sit on the Start tier and do not auto-promote; the Request rate limit increase flow is unavailable (go through an account representative); and per-workspace configuration and fast mode are unavailable. Corrected 2026-08-30: this page previously said spend limits do not apply there. The docs now state the opposite — the same monthly spend caps apply and requests stop at the cap in the same way; what differs is billing (AWS Marketplace rather than Anthropic credits) and how tier increases are requested.

Why this lives in the providers wiki

It sharpens two of the spoke's running threads:

• "Engineering sets real cost" (llm-api-pricing, claude-refusals-and-fallback): prompt caching isn't only a price cut — under cache-aware ITPM it raises effective throughput without a higher limit. Caching is now a rate-limit lever, not just a billing one.
• API access as competitive surface: tiers, token-bucket pacing, per-model pools, and the AWS-reseller divergence are all part of how access is rationed, the access-and-pricing half of this wiki's domain.

Related

anthropic · llm-api-pricing · claude-refusals-and-fallback · llm-provider · claude-fable-5 · claude-opus-5 · cerebras-pricing