Claude Rate Exceeded: How to Fix It Fast

What the "Claude rate exceeded" error means

When Claude tells you the rate has been exceeded, it is communicating one of three different things and the fix depends on which. The error text looks similar in all three cases but the underlying cause is not. Most developers trying to fix this guess wrong on the first try and waste the next 30 minutes.

This guide breaks down the three flavours of "rate exceeded," how to identify which one you are hitting, the fastest fix for each, and the configuration changes that prevent the error from cropping up daily.

The three rate-exceeded scenarios

The same error message can mean very different things depending on where you are calling Claude from.

Subscription rate limit (Pro/Max/Team). You have used your share of the 5-hour rolling window on a subscription plan. The fix is to wait, not to upgrade or change config.

API rate limit (per-second or per-minute). You hit Anthropic's per-second token cap on the API. The fix is concurrency control in your code, not waiting.

API spend cap. You hit a hard spend limit configured on your billing settings. The fix is in the billing dashboard, not in your client code.

These three look almost identical from the outside but require completely different responses. Diagnosing the right one is the entire game.

Identifying which one you have

A 30-second triage:

Where are you calling from?	What's the cause?
Claude.ai web app or Claude Code in terminal	Subscription window
API call from your code or script	API rate or spend
Programmatic call from a CI/CD pipeline	API rate or spend
Claude Code configured with API key	API rate or spend

For API errors specifically, the response body contains a structured error. The type field will say rate_limit_error (per-second cap) or permission_error with a billing message (spend cap). If you see rate_limit_error, it is a tokens-per-minute issue. If you see anything mentioning "credits" or "spend," it is your billing cap.

Claude Code in the terminal usually shows the subscription variant. The error includes a timestamp like "rate exceeded, retry after 12:34 UTC" which is your window-rollover time.

How to fix the three rate-exceeded scenarios

Subscription window saturation

For Pro, Max, Team, or Enterprise subscriptions:

1. Note the retry-after timestamp from the error
2. Stop sending prompts immediately (more attempts do not help and may extend the wait)
3. Wait until the timestamp passes, typically 30 to 60 minutes
4. Resume normally

That is genuinely the whole fix. There is no parameter you can tune, no retry logic that helps, and no "upgrade now" path that retroactively unlocks the current window.

What does help: prevention. The single biggest cause of subscription rate exceeded is sending huge context blobs to Claude when small ones would do. Each token in your input counts toward the window, so a 40K-token CLAUDE.md getting injected into every prompt drains the budget fast. Trimming context and using memory systems instead is how serious users avoid this.

If you hit the Pro rate limit more than twice a week, you are not configured wrong, you are just on the wrong plan. Max 5x at $100 per month gives you roughly five times the headroom. The math says it pays for itself in time saved if your hourly rate is over $20.

API tokens-per-minute cap

For programmatic callers hitting the API:

The error is per-second tokens-per-minute (TPM) or requests-per-minute (RPM), not a daily cap. The fix is concurrency control. Three layers to add:

Exponential backoff. When you receive a 429, wait 1 second, retry. If that 429s, wait 2. Then 4. Then 8. Cap at 60 seconds. Most production setups skip this and just spam retries, which extends the rate-limit window and makes the problem worse.

Token-budgeting your concurrency. If your TPM cap is 80,000 and your average call uses 4,000 tokens, you can sustain 20 calls per minute, period. Code that fires 100 calls in a 10-second burst will rate-limit within seconds even though the per-minute average is fine. Use a token-bucket algorithm or explicit rate limiter.

Request prioritisation. Production traffic should always preempt development or batch jobs. If your service has a queue, mark production calls as priority and let everything else queue behind them. When the rate limit hits, only the low-priority work gets backed up.

The Anthropic API includes rate-limit headers (anthropic-ratelimit-tokens-remaining, anthropic-ratelimit-tokens-reset) on every response. Read them. Adjust send rate based on remaining budget. This is the single highest-leverage change a production caller can make.

API spend cap reached

If your error mentions credits or spend rather than rate:

1. Open console.anthropic.com → Billing
2. Check your hard spend limit
3. Either raise the limit or wait for the next billing cycle

The spend cap is yours to set. If you set it at $100/month and you actually need $500/month, you raise it. If your script is using more than expected, you investigate before raising it. Both are valid, but you have to make the call.

Most accidental spend caps come from default settings. New API accounts in some regions get a low cap by default, which is fine for testing and a problem in production. Check your cap before you scale traffic.

For the deeper console walkthrough on managing spend, see our Claude API console guide.

How to fix rate exceeded inside Claude Code

If you are hitting this specifically in Claude Code in the terminal, four tactical fixes that work right now:

Switch models. Type /model sonnet to switch from Opus to Sonnet, which consumes fewer resources. Or /model haiku for the lightest option. You lose some capability but you can keep working through the current window.

Compact your context. Claude Code does not send a single prompt per call, it sends your entire conversation history, system prompt, and all files pulled into context. A developer who issues 15 iterative commands might be sending 200,000+ input tokens on the final command. Run /compact to compress your conversation context. For a clean reset, use /clear to start a fresh session.

Credential reset for stuck sessions. Some developers report sessions getting permanently stuck on "rate exceeded" even after the window resets. The fix: run claude logout, delete cached credentials, and log back in with claude login. This forces a fresh session that is not carrying stale rate-limit state.

Check whether it is actually a bug. Anthropic has occasionally shipped rate-limit bugs that affect Max subscribers despite low reported usage. A quick triage:

Usage dashboard reading	Most likely cause
Below 50 percent	Likely a bug, file an issue on the Claude Code GitHub with your CLI version, subscription tier, and the exact error
50 to 80 percent	Try the credential reset first, if it persists it might be a bug
Above 80 percent	You are genuinely at the limit, use the prevention strategies below

Stopping rate exceeded from happening daily

If "rate exceeded" is showing up more than twice a week, something is structurally wrong. Three diagnostic questions:

Are you on the right plan? Pro is for casual use. Max is for daily use. The API is for automation. Match the plan to the workload, not the lowest price.

Is your prompt sending too much context? Every token in your input counts. If you are inlining files Claude does not need, drafts of past responses, or full chat history when only the last turn matters, you are burning your budget on noise.

Is your retry logic making it worse? Hammering a rate-limited endpoint is the fastest way to extend the limit. A polite client backs off and resumes when the budget resets.

This is exactly where Claudify compounds: structured memory architecture, agent-specific context budgets, and audit hooks that catch context bloat before it ships. Most Claudify users see their daily token consumption drop 40 to 60 percent after the first week, not because Claude got faster but because they stopped wasting tokens on context Claude did not need.

When the rate-limit error is actually a different bug

Three patterns where "rate exceeded" is the symptom but the cause is somewhere else:

Stale API key. A revoked or expired key returns a 401, not a 429. But some client libraries surface both as the same error. If retrying does not help and waiting does not help, regenerate the key.

Account billing failure. A failed payment method silently degrades your account to a lower tier or cuts off entirely. The error looks like rate exceeded but is actually billing. Check console.anthropic.com → Billing for declined-charge notifications.

Wrong model parameter. Calling a model your account does not have access to (e.g. Opus on a key scoped to Sonnet only) can return a similar-looking error. The fix is to use a model your key has access to or update the key scope.

If you are stuck after trying the fixes above, our Claude Code debugging guide covers the broader diagnostic flow, and fixing Claude Code errors fast lists the most common error types with their exact fixes. If the tool is failing in ways that are not strictly rate limits, why Claude Code is not working groups the runtime failures by category.

Quick reference

Symptom	Most likely cause	Fix
Hits Pro at 9pm every day	Window saturation on Pro	Upgrade to Max or trim context
429 on API mid-burst	TPM cap	Add concurrency control
"Insufficient credits" on API	Spend cap	Raise cap or wait for cycle
Hits within minutes of starting	Wrong plan or auth issue	Check plan, regenerate key
Random and unpredictable	Account billing problem	Check billing tab

Next steps

Rate exceeded is almost always a configuration problem disguised as a Claude problem. Treating it as a config problem is what separates people who hit it once a quarter from people who hit it every afternoon.

Get Claudify. The Claude Code operating system that prevents the configuration mistakes that cause most rate-limit errors. Skills, memory, agents, and audit hooks ship out of the box.