Claude API Rate Limits: Tier 1-4, 429 Recovery (2026)

Originally published at claudeguide.io/claude-api-rate-limits

Claude API Rate Limits: Tier 1-4, 429 Recovery, Retry-After (2026)

Anthropic enforces 4 independent counters per organization: RPM (50 starting), input TPM (50K), output TPM (10K), and a $100 daily spend cap — hit any one and the API returns 429. Anthropic enforces RPM (requests per minute) and TPM (tokens per minute) limits per organization, scaled by usage tier. A 429 Too Many Requests is returned when any of those four counters — RPM, input TPM, output TPM, or daily dollar cap — is exceeded. The correct recovery is exponential backoff that honors the retry-after header, not a fixed sleep. Tier upgrades are automatic, triggered by both cumulative spend and days since first payment — you can't just throw $400 at the API and immediately land on Tier 4.

This guide unpacks every limit, shows production-grade retry code, and explains the burst patterns that keep throughput high without tripping 429s.

The four limits that matter

Most people think "rate limit" means RPM. Anthropic enforces four independent counters, and you hit 429 the moment any one trips:

1. RPM — requests per minute. Each API call counts as 1, regardless of size.
2. Input TPM — input tokens per minute. Includes system prompt, user message, tool definitions, prior assistant turns, and any cached prefix. Tool-heavy agents burn input TPM faster than chat because every tool result re-enters as input on the next turn.
3. Output TPM — output tokens per minute. The one that bites long-form generation.
4. Daily $ cap (Tier 1 and 2 only) — hard ceiling on cumulative spend per UTC day. Resets at 00:00 UTC, not local midnight.

Output TPM is the most common surprise: a single 4K-token response on Tier 1 burns 40% of your minute. Plan for whichever limit your workload hits first, not the headline RPM number.

Tier table (Tier 1 through Tier 4)

Tier	Spend req	Days req	RPM	In TPM	Out TPM	Daily $
Tier 1	$0	0	50	50K	10K	$100
Tier 2	$40	7	1,000	100K	20K	$500
Tier 3	$200	7	2,000	200K	40K	$1,000
Tier 4	$400	14	4,000	400K	80K	$5,000

Tier 4 removes the daily cap entirely. Above Tier 4 ("custom tier") requires sales contact.

The days requirement catches teams. You can spend $400 in week one, but Tier 4 needs 14 days since first payment — so the earliest you reach it is day 14 with $400 cumulative spend. If your launch needs Tier 4, start spending real money 2-3 weeks ahead.

Anatomy of a 429 response

When you trip a limit, Anthropic returns:

HTTP/1.1 429 Too Many Requests
retry-after: 23
anthropic-ratelimit-requests-limit: 1000
anthropic-ratelimit-requests-remaining: 0
anthropic-ratelimit-requests-reset: 2026-05-09T14:23:45Z
anthropic-ratelimit-input-tokens-limit: 100000
anthropic-ratelimit-input-tokens-remaining: 0
anthropic-ratelimit-input-tokens-reset: 2026-05-09T14:23:12Z
anthropic-ratelimit-tokens-limit: 100000
anthropic-ratelimit-tokens-remaining: 0
anthropic-ratelimit-tokens-reset: 2026-05-09T14:23:12Z

{"type":"error","error":{"type":"rate_limit_error","message":"..."}}

The two things to read every time:

• retry-after — seconds to wait. Always honor this; it's the server's authoritative hint.
• anthropic-ratelimit-*-remaining — present on every 200 too. Read these proactively to throttle yourself before you hit 0.

There are three reset timestamps, not one — RPM, input TPM, and output TPM reset on independent rolling windows. Read all three before deciding when to retry.

Exponential backoff that actually works (TypeScript)

The naive await sleep(1000 * 2 ** attempt) ignores retry-after and synchronizes all your retries — bad. Production code honors the header, adds jitter, and caps total attempts:

typescript
import Anthropic from "@anthropic-ai/sdk";

const client = new Anthropic();

async function callWithBackoff<T

---

## Long-running batches: use the Batch API

If your job isn't latency-sensitive, **don't fight rate limits — use the Message Batches API**: 50% cheaper on both input and output, no synchronous rate limit, up to 10,000 requests per batch processed within 24 hours (usually under an hour). Heuristic: if a human won't see the output within 60 seconds, route it to batch. Combining batch with prompt caching can cut token costs 60-70% versus synchronous calls. See the [cost monitoring guide](/claude-api-cost-monitoring-guide) for automatic routing based on a per-request `latency_budget` field.

## Multi-key strategy: real, with caveats

Multiple API keys in one organization each get their **own RPM counter**, but share the **same TPM and daily $ budget**. So multi-key buys parallelism for request-bound workloads but does nothing for token-bound ones. Don't use multi-key to bypass tier limits — Anthropic's enforcement is org-wide on tokens and spend.

Legitimate use: separating keys per workspace so one runaway script doesn't exhaust RPM for production traffic. One nuance — **rotating keys does not reset rate limits**; if you've burned through TPM, a new key won't help.

## Tier upgrade triggers and manual requests

Upgrades are automatic — the system checks daily and promotes you when **both** conditions are true: cumulative spend ≥ tier threshold **and** days since first payment ≥ tier minimum. No button to push.

For enterprise volume or pre-launch teams with funded runway, email Anthropic support with: org ID, expected monthly RPM/TPM, use case description, billing contact. Manual upgrades resolve in 1-3 business days. YC and Anthropic for Startups members can often skip Tier 1 entirely.

## Five common pitfalls

1. **Fast retries with no jitter.** Ten clients retrying at `t+1s` cause a thundering herd. Use full jitter (`random * base`), not equal jitter.
2. **Ignoring `retry-after`.** Your guess is worse than the server's. Read it first; fall back to exponential math only when missing.
3. **Not honoring the daily cap.** Tier 1/2 have a $100/$500 ceiling — a runaway loop with `max_tokens: 8192` on Opus can blow it in under a minute. Add a client-side kill-switch at 80% of cap.
4. **Treating workspaces as separate budgets.** Workspaces are observability boundaries; rate limits and dollar caps are organization-wide.
5. **Forgetting streaming counts.** Streamed and non-streamed output consume identical TPM. A client that disconnects mid-stream still pays for tokens already generated. See [error handling patterns](/claude-api-error-handling) for streaming-specific 429 recovery and the `overloaded_error` 529 (distinct from a rate limit).

## Frequently Asked Questions

### What's the fastest way to get to Tier 4?

Minimum is **14 days from first payment with $400+ cumulative spend**. The day requirement is the binding constraint — you can't shortcut it by spending faster. If you need Tier 4 by date X, make your first paid call by X-14. For enterprise volume, email support for a manual promotion.

### Do streaming responses count toward TPM differently?

No. Streamed and non-streamed completions consume identical input/output tokens — streaming is just a delivery mode. The only difference: a client that disconnects mid-stream still pays for tokens already generated.

### Can I share rate limit across multiple keys?

Sort of. Multiple keys in the same organization each get **independent RPM counters** (so you can parallelize request-bound workloads across keys), but they **share the organization-wide TPM and daily spend cap**. Multi-key is a parallelism tool, not a tier-upgrade workaround.

### How do I monitor my current rate?

Read `anthropic-ratelimit-*-remaining` on every successful response — free telemetry. Pipe them to Datadog/Prometheus/PostHog and alert at 20% remaining. The Anthropic Console also shows real-time RPM/TPM graphs per key.

### What about prompt caching — does cache_read count toward TPM?

Yes, but at a discount. Cache reads consume the **same TPM budget** as fresh input tokens, just at 10% the cost. For TPM purposes a cached prefix and a fresh prefix are equivalent — both eat your input TPM. Caching is a cost and latency lever, not a rate-limit lever. If you're hitting input TPM constantly, caching won't save you — you need a tier upgrade or a token bucket. See the [prompt caching guide](/claude-prompt-caching-guide) for which workloads benefit.

## The one-line takeaway

Read the rate-limit headers on every response, honor `retry-after` on every 429, gate your client with a token bucket, and route long-running work to the Batch API. Do those four things and you'll never see a rate-limit incident in production.

**[Claude API Cost Optimization Masterclass ($59)](https://shoutfirst.gumroad.com/l/msjkda?utm_source=claudeguide&utm_medium=article&utm_campaign=rate-limits-end)** — Rate limits cap your throughput; token costs cap your budget. The masterclass covers model tiering, prompt caching, and the 80/15/5 rule to keep both under control — PDF guide with an Excel cost calculator.