Claude Code Rate Limit Reached? Which Limit You Hit

Jump to: quick triage · "limit reached, resets at" a time · 429 with a wait time · 429 or 400 that retrying won't fix · things worth clarifying · FAQ

Start Here: Which Message Are You Looking At?

Error 1 - "Limit Reached, Resets At" a Given Time

What you see: Claude Code stops partway through a session with a message along the lines of "limit reached, resets at" a given time — no HTTP status code, since this isn't an API-level error. Anthropic's own documentation quotes this exact wording for Claude Enterprise seats; if you're on Pro, Max, or Team, you likely hit the same kind of pool, but Anthropic's Claude Code article doesn't confirm the exact message text for those plans, so treat the wording as close rather than guaranteed identical.

Why it happens

Anthropic documents this for Claude Enterprise seats specifically: a seat gets "a pool of usage included in your organization's plan, reset on a rolling window." Anthropic's own Claude Code support article doesn't publish a numeric session-window or weekly-cap figure for this pool, or for Pro, Max, or Team plans, so there's no official number to check yourself against — only the reset time the message itself gives you.

How to fix it

1. Read the reset time in the message itself; that's the only number Anthropic's own documentation gives you for this pool.
2. While you wait, switch to a lighter model with /model — Opus "uses meaningfully more of your quota" than Sonnet, and Sonnet more than Haiku, per Anthropic's own guidance. /model opusplan uses Opus only for planning and Sonnet for execution, which stretches the same pool further.
3. Cut what each turn costs: reference files by path instead of pasting their contents, trim pasted logs to the relevant lines, and keep CLAUDE.md to roughly 200 lines or less.
4. Run /clear between unrelated tasks — it drops the resent chat history (the single biggest driver of token use per turn) while keeping CLAUDE.md and your project files available. Use /compact instead if you want to summarize the current task's history without losing it entirely.
5. For a multi-file change, ask for a plan first rather than letting Claude Code touch everything at once; reviewing a plan before execution avoids paying for a large edit twice if the first attempt goes the wrong way.
6. If your organization allows it, fall back to an API key for the rest of the session — that path is pay-as-you-go with no pool to run out of (see Error 2 for what its own limits look like).

What you should see: Claude Code resumes normally once the reset time passes, or immediately if you switch to an API key.

Error 2 - A 429 That Tells You How Long to Wait

What you see: an API error with status 429 whose body names a specific limit (requests per minute, input tokens per minute, or output tokens per minute), and a retry-after response header stating how many seconds to wait.

Why it happens

This is Anthropic's standard Messages API rate limiting, measured per model in requests per minute (RPM), input tokens per minute (ITPM), and output tokens per minute (OTPM), set by your organization's usage tier (Start, Build, Scale, or Custom; new organizations start on a lower Evaluation tier and move up automatically with usage history). Anthropic's documentation states directly that Claude Code's own workspace is checked the same way: "Limits on the Claude Code workspace are checked separately: Claude Code requests over that workspace's limit can instead receive a 429 that carries a retry-after header." Limits use a token-bucket algorithm — capacity refills continuously rather than resetting at a fixed interval — so a short burst of requests can trigger a 429 even if your per-minute average is well under the limit. A sharp, sudden jump in usage can also trigger a separate "acceleration limit" 429, even under your normal cap.

How to fix it

1. Read the retry-after header (or the equivalent wait time your tool surfaces) and wait that long before the next request; retrying sooner just fails again.
2. If this happens repeatedly during ordinary, non-bursty use, your traffic is likely hitting a token-bucket burst rather than a sustained overage — smooth out request timing instead of firing several at once.
3. If you've recently and sharply increased usage, ramp it up gradually instead of all at once; Anthropic's documentation names this specifically as the fix for acceleration-limit 429s.
4. Use prompt caching for repeated content (system instructions, large context documents, tool definitions). For most models, only uncached input tokens count toward your ITPM limit, so a high cache-hit rate raises your effective throughput without needing a higher limit.
5. If you're consistently near the limit rather than bursting into it, request a higher limit: Anthropic's support documentation says you can request a tier increase once you're using at least 50% of your current limits, via Request tier increase on the Rate limits page in the Claude Console (platform.claude.com/usage/limits).

What you should see: the request succeeds once you're past the retry-after window, or consistently once you've smoothed out bursts or raised your tier.

Error 3 - A 429 or 400 That Waiting Doesn't Fix

What you see: either a 429 with no retry-after header and an error code of enforced_spend_limit_reached, or a 400 whose message starts "You have reached your specified API usage limits" (or the workspace-scoped version of that message). Retrying — including a tool's automatic retry logic — keeps failing.

Why it happens

This isn't a rate limit at all, even though the 429 variant uses the same HTTP status code and the same rate_limit_error type. It's a spend cap: your organization has either hit its usage tier's monthly spend cap (Start: $500, Build: $1,000, Scale: $200,000; Custom tiers have none) or a lower spend limit someone set deliberately on the Billing page. Anthropic's documentation is explicit that the spend-cap 429 has no retry-after header specifically because retrying won't help: access doesn't return until the calendar resets at 00:00 UTC on the first of the next month, or until someone raises the limit.

How to fix it

1. Check which message you got. enforced_spend_limit_reached (in a 429's error.details.error_code) is the organization's tier cap; a 400 starting "You have reached your specified API usage limits" is a self-set limit someone configured on purpose.
2. For a self-set limit: go to the Billing page in the Claude Console (platform.claude.com/settings/billing), open Spend limits, and raise or remove the limit under Adjust limit. Access resumes as soon as you save the change.
3. For the tier's own monthly cap: either wait for the reset at 00:00 UTC on the 1st, or request a higher tier via Request tier increase on the Rate limits page in the Claude Console.
4. Don't keep retrying automatically in the meantime — a tool's built-in retry logic (including SDK auto-retry) will keep failing against this specific error until one of the two fixes above happens.

What you should see: requests succeed immediately after the spend limit is raised or removed, with no need to wait once that change is saved.

Things Worth Clarifying

• "Rate limit" and "context limit" are two different problems. Everything on this page is about a time-windowed usage allowance — a pool, a per-minute cap, or a spend cap. Running out of context mid-task (Claude Code compacting or losing track of earlier instructions in a long session) is a separate, per-session token-count issue with its own fixes; see the general Claude Code troubleshooting guide's section on context compaction and large-codebase token limits if that's what you're actually running into.
• The specific message-count and hour figures you'll find for Pro, Max, and Team plans online (for example, "Sonnet 35-45 messages per 5 hours on Pro") are third-party estimates, not numbers Anthropic publishes. Anthropic's own Claude Code support article names the Enterprise-seat usage pool and the pay-as-you-go API key as the two metered paths it documents, without publishing specific session-window or weekly-cap figures for any plan. Treat any specific number you see elsewhere as an estimate, not a documented limit to plan around precisely.
• A handful of open, unconfirmed reports describe the error firing well under the stated usage — for instance, one report of the message appearing at roughly 27% of a 5-hour limit and 13% of a weekly one, another around 30%. These are user-filed GitHub issues, not a confirmed bug with an official fix, so treat an early-seeming "limit reached" as worth reporting with specifics rather than assuming the workarounds above will necessarily explain it.
• /cost and /context don't show you remaining pool quota. /cost reports session token and dollar spend, framed around API billing; /context shows what's currently loaded into context. Neither one surfaces how much of an Enterprise seat's usage pool is left — the reset-time message is the only figure you get.

When It Isn't a Bug

• Hitting a usage pool or a rate limit during heavy, legitimate use isn't a malfunction. Anthropic states plainly that these limits exist to "prevent API abuse, while minimizing impact on common customer usage patterns" — an agentic session that reads and writes many files in a row will burn through a time-windowed allowance faster than ordinary chat, by design.
• A spend cap or self-set spend limit stopping requests outright, with no retry-after, isn't a glitch. It's deliberately built that way so an organization's bill can't run past what someone configured; the fix is raising the limit or waiting for the calendar reset, not retrying.
• A short burst of requests triggering a 429 even under your average usage isn't unfair enforcement. The token-bucket method Anthropic uses replenishes continuously rather than all at once, so bursts can temporarily exceed capacity that looks unused on average.

What to Include When You Ask for Help

• the exact message or error, word for word, including any status code and whether a retry-after header or reset time was given;
• whether you're on a Claude Enterprise seat, another subscription plan, or an API key, and (for the API) your organization's usage tier;
• roughly how heavy the session was just before the error (long-running agentic task, many files touched, or a quick single request);
• whether the same error happened again shortly after the stated reset time, which points toward a bug report rather than a one-off.

Related

For Claude Code problems unrelated to usage or rate limits — reverted changes, context compaction, permission denials, and more — see the Claude Code troubleshooting guide. For an overview of what Claude Code covers as a platform, see the Claude Code platform page.

Frequently Asked Questions

Sources

Checked on October 26, 2026:

• Anthropic support: Models, usage, and limits in Claude Code
• Anthropic docs: Rate limits
• Anthropic support: Our approach to rate limits for the Claude API