Claude Rate Limit & 'Rate Exceeded' Errors: Causes & Fixes

"Rate exceeded" and 429 rate_limit_error both mean the same thing: you sent Claude more than your current allowance in a short window. On the API it is a transient error with a retry-after header telling you exactly how long to wait; in the claude.ai app it is a plan message cap that resets on a rolling window. This guide covers both — the exact error shapes, Claude's per-tier RPM/ITPM/OTPM limits, why 529 "overloaded" is not your rate limit, and the fixes: honour retry-after with backoff, use prompt caching to raise your effective limit, and fail over so one provider's ceiling is not your app's ceiling.

What 'Claude rate exceeded' means

It means you sent more than your current allowance in a short window — and it is temporary. The exact form depends on where you hit it:

• On the Claude API you get HTTP 429 with body type rate_limit_error and a retry-after header saying how many seconds to wait. Anthropic's docs describe it plainly: "429 — rate_limit_error: Your account has hit a rate limit."
• In the claude.ai chat app you see "You've reached your rate limit. Please try again later" or "rate exceeded" — a message cap on your Free/Pro/Max plan that resets on a rolling window.

Neither is a bug or a ban. The API case is the one you control in code, and it is the focus of this guide; the app case is covered in its own section below.

Why you are being rate limited

Because you crossed one of three per-minute meters, hit a burst, or ramped too fast. Claude's API limits are measured, per model class, in:

• RPM — requests per minute.
• ITPM — input tokens per minute.
• OTPM — output tokens per minute.

Exceed any one and you get a 429 that names which limit you hit. Two non-obvious triggers catch most people:

• Bursts. A 1,000 RPM limit "might be enforced as 1 request per second," per Anthropic — so a tight loop trips it even though your one-minute average is well under budget. Claude uses a token-bucket algorithm that refills continuously rather than resetting on the minute.
• Acceleration limits. A sharp jump in overall usage can return 429s independently of your steady-state limits. Anthropic's guidance: "ramp up your traffic gradually and maintain consistent usage patterns."

429 vs 529: the Claude error decoder

429 is your limit; 529 is Anthropic's capacity — do not treat them the same. The errors people conflate with a rate limit, and what each actually means, straight from Anthropic's error reference:

Every Claude error is JSON with a stable shape — branch on error.type, not the message string:

{
  "type": "error",
  "error": {
    "type": "rate_limit_error",
    "message": "Number of request tokens has exceeded your per-minute rate limit..."
  },
  "request_id": "req_011CSHoEeqs5C35K2UUqR7Fy"
}

Claude API rate limits by tier

Limits scale with your usage tier, and each model class has its own bucket. Your organisation is placed on a tier automatically and moves up with usage. Anthropic's standard Messages API limits (Start tier shown; Build and Scale raise them several-fold):

Two consequences worth designing around:

• Separate buckets. Opus, Sonnet and Haiku each have their own limit, so you can run them simultaneously up to their respective ceilings — spreading load across model classes is free headroom. (Note: Opus 4.8/4.7/4.6/4.5 share one combined Opus bucket.)
• OTPM ignores max_tokens. Only tokens actually generated count, so a high max_tokens has no rate-limit downside — Anthropic confirms "the max_tokens parameter does not factor into OTPM rate limit calculations."

On tiers: Start caps monthly spend at $500, Build at $1,000, Scale at $200,000; Build roughly 2.5–5× the Start token limits and Scale ~5× again. Need more? Request an increase on the Limits page.

Read the rate-limit headers before you guess

Every response tells you your remaining budget and the exact reset time — use them instead of hard-coded sleeps. Claude returns these on the Messages API:

Watch *-remaining approach zero and you can throttle before the 429 ever fires.

How to fix Claude rate limit errors (with code)

Honour retry-after, back off with jitter, and remove the pressure structurally. The tactical fix and the durable fixes:

1. Honour retry-after + exponential backoff with jitter — the correct retry, not a fixed sleep.
2. Cache repeated input — cached tokens do not count toward ITPM on most Claude models (see below).
3. Spread across model classes — Opus/Sonnet/Haiku have separate buckets.
4. Batch non-urgent work — the Message Batches API has its own limits and takes load off your real-time budget.
5. Request a higher tier — or let usage advance you automatically.
6. Fail over — reroute a 429 to an equivalent model on another provider (see gateway).

A retry loop that respects the header and backs off correctly:

from anthropic import Anthropic, RateLimitError, APIStatusError
import time, random

client = Anthropic()

def call(messages, model="claude-sonnet-5", tries=6):
    for i in range(tries):
        try:
            return client.messages.create(model=model, max_tokens=1024, messages=messages)
        except RateLimitError as e:                       # 429 — read the header
            wait = float(e.response.headers.get("retry-after", 2 ** i))
            time.sleep(wait + random.random())               # + jitter
        except APIStatusError as e:
            if e.status_code in (500, 503, 529):        # overloaded — not your quota
                time.sleep((2 ** i) + random.random())
            else:                                          # 400/401/403 — fix, do not retry
                raise
    raise RuntimeError("exhausted retries")

Anthropic's official SDKs already retry transient failures (rate limits and 5xx) with exponential backoff twice by default, honouring retry-after — tune it with the max-retries option rather than reimplementing from scratch. This loop is the explicit version for when you need more control.

Prompt caching raises your effective rate limit

On most Claude models, cached input tokens do not count toward your ITPM limit — so caching is a throughput multiplier, not just a cost saver. Anthropic's own example: with a 2,000,000 ITPM limit and an 80% cache hit rate, you can effectively process about 10,000,000 input tokens per minute (2M uncached + 8M cached). What to cache for the biggest lift: system prompts, tool definitions, large context documents, and conversation history. Cached reads are also billed at ~10% of the input price, so the same lever cuts your bill — the arithmetic is in our cheapest-LLM cost guide. (Exception: legacy Claude Haiku 3.5 does count cached reads toward ITPM.)

Fixing 'rate exceeded' on the claude.ai app

If you hit it in the chat app rather than the API, it is a plan message cap, not something code can fix. Free, Pro and Max plans each allow a number of messages per rolling window (longer conversations and file-heavy chats consume the budget faster). Practical moves: wait for the window to reset, start a fresh shorter conversation, switch to a lighter model for routine turns, or — if you are building on top of Claude — move to the API, where limits are transparent (RPM/ITPM/OTPM) and you can add caching and failover. Exact plan message counts change over time; check your plan page for current numbers rather than trusting a screenshot.

When a gateway removes the ceiling

A single provider's rate limit does not have to be your application's rate limit. A 429 (your Claude limit) or a 529 (Anthropic overloaded) is exactly the kind of transient error a gateway can absorb: on either, it retries the request on an equivalent model from another provider, so the end user never sees the error. You still design within Claude's limits for Claude-specific work, but the not-your-fault ceiling — Anthropic capacity spikes, momentary bursts — becomes an invisible reroute instead of a failed request. See routing & failover for how that is wired, and the generic 429 deep-dive for the cross-provider version.

FAQ