Claude Code 529 Overloaded: What It Means and 5 Simple Fixes
Repeated 529 Overloaded errors in Claude Code mean Anthropic is out of capacity for that model. It doesn't count against your quota. How it differs from 429 and 500, what Claude Code retries on its own, and 5 fixes in order.

If Claude Code stops with “API Error: Repeated 529 Overloaded errors”, Anthropic’s servers are short of capacity for the model you’re using. It isn’t your usage limit, and Anthropic’s own docs say a Claude Code 529 Overloaded error doesn’t count against your quota. Usually the fix is to wait a few minutes, check status.claude.com, or switch to another model with /model. Below is what the error means, how it differs from 429 and 500, what Claude Code already does for you, and what’s worth trying. I only used official docs, the status page and real GitHub reports, all linked.
What Claude Code 529 Overloaded means
A 529 is an HTTP status code that the Claude API returns with the error type overloaded_error. The Claude API errors page describes it in one line: “The API is temporarily overloaded.” Right under it there’s a note that “a 529 error can occur when the API experiences high traffic across all users.”
Claude Code doesn’t show you the very first 529. It retries quietly, and only when the retries run out do you see the full message from the Claude Code error reference:
API Error: Repeated 529 Overloaded errors. The API is at capacity — this is usually temporary. Try again in a moment. If it persists, check https://status.claude.com.
The same page says it plainly: “A 529 is not your usage limit and doesn’t count against your quota.” So you haven’t burned through your Pro or Max allowance, and your account isn’t in trouble. Lots of people are asking for the same model at the same moment, and Anthropic is turning some requests away.

Claude Code 529 Overloaded vs 429 and 500
These three get mixed up all the time, and the fix depends on which one you got.
| Code | Error type | What Anthropic says it means | Does waiting help? |
|---|---|---|---|
| 529 | overloaded_error | The API is temporarily overloaded, high traffic across all users | Yes, usually within minutes |
| 429 | rate_limit_error | Your organization hit a rate limit, its tier’s monthly spend cap, or a spend limit on the Claude Code workspace | Only if it’s a short throttle; a spend cap keeps failing until access resumes |
| 500 | api_error | An unexpected error inside Anthropic’s systems | Yes, retry with backoff |
| 504 | timeout_error | The request timed out while processing | Retry, or use streaming for long requests |
A 429 is about you or your organization. In Claude Code it shows up as “Request rejected (429)” when an API key, Bedrock project or Google Cloud project hits its rate limit, or as “You’ve hit your session limit” and “You’ve hit your weekly limit” when you’re on a Pro or Max plan. Those plan limits are shared across all models, so switching models won’t help there. I keep all the exact messages in my Claude Code errors lookup, and the plan limits themselves are explained in Claude usage limits explained. If you got a 429 rather than a 529, my Claude Code 429 quick reference goes through every message, the headers worth reading and the Codex equivalents.
A 500 is a bug or failure on Anthropic’s side. It’s also not your fault, and the Claude Code message for it points to the same status page.

What Claude Code already did before showing the error
By the time you read the message, Claude Code has already tried again several times. The error reference says it “retries transient failures up to 10 times with exponential backoff before showing you an error”, and overloaded responses are on that list. While it retries, the spinner shows a countdown like Retrying in Ns · attempt x/y, and from v2.1.198 a 529 also names status.claude.com under the countdown.
There’s one detail worth knowing. The environment variable reference says retrying “can stop earlier on 529 overloaded errors”, and gives the example that with an API key on an Opus model it stops at the third 529. So if you’re on Opus and see the error quickly, that’s expected behavior, not a broken install.
These are the official settings that change how Claude Code handles a 529:
| Setting | Default | What it does |
|---|---|---|
CLAUDE_CODE_MAX_RETRIES | 10 | Number of retry attempts, capped at 15 as of v2.1.186 |
CLAUDE_CODE_OVERLOADED_RETRY_BASE_DELAY_MS | 500 | Starting delay between 529 retries, up to 32000 (v2.1.292+) |
CLAUDE_CODE_OVERLOADED_RETRY_MAX_DELAY_MS | 32000 | Ceiling on the delay between 529 retries, up to 64000 (v2.1.296+) |
CLAUDE_CODE_RETRY_WATCHDOG | unset | Set to 1 in unattended sessions such as CI to retry 429 and 529 capacity errors indefinitely |
CLAUDE_CODE_RETRY_WATCHDOG_MAX_WAIT_MS | unset | Caps how long each request waits out 429 and 529 errors with the watchdog on (v2.1.295+) |
I wouldn’t turn on the watchdog in an interactive session. It’s meant for jobs nobody is watching, and in a terminal you’d rather see the error and decide yourself.
5 things to try, in this order

1. Wait a few minutes and send “try again”
The official advice is to try again in a few minutes. Your message is still in the conversation, so you don’t need to paste a long prompt again. Typing “try again” or “continue” is enough.
2. Check status.claude.com
Open status.claude.com. If there’s an active incident for your model, waiting is the only real fix and you can stop debugging. Today, October 27, 2026, there was one: “Elevated errors for Claude Sonnet 5.5” was posted at 17:14 Beijing time and marked resolved at 17:56. The status page says “elevated errors” rather than “529”, so treat it as a strong hint, not proof.
3. Switch to another model with /model
This one works surprisingly often, because the docs say “capacity is tracked per model”. Run /model and pick another model. When one model is under heavy load, Claude Code even suggests it for you with a message like Opus is experiencing high load, please use /model to switch to Sonnet. In the Claude Desktop app it reads “Opus is experiencing high load. Switch to Sonnet.” and you use the model picker instead.
4. Set a fallback model so it switches on its own
If you hit this a lot, set up a fallback chain. According to the model configuration docs, when the primary model is overloaded or unavailable, Claude Code can switch to a fallback model instead of failing. For one session you can start it like this:
claude --fallback-model sonnet,haiku
To keep it, set fallbackModel as an array in your settings. The switch only lasts for the current turn, chains are capped at three models, and rate-limit errors never trigger a switch. That last point matters, because it means a fallback won’t hide a 429. Since v2.1.247 the chain also covers subagents. Before that, a failure like this ended the subagent, which matches a July 2026 GitHub report where four background agents died on 529 during one long session.
5. Update Claude Code, then report it
Several of the retry improvements above only exist in recent versions, so run claude update if you’re behind. The latest version on npm when I checked was 2.1.311. If the error keeps coming with no incident on the status page, run /feedback so Anthropic gets your request details.
Is there a better time of day? (Beijing time)
I looked for an official answer and didn’t find one for 529 specifically. Anthropic doesn’t publish a schedule for capacity errors.
The closest thing is a change Anthropic announced on March 26, 2026. Thariq from Anthropic posted on X that “during weekdays between 5am–11am PT / 1pm–7pm GMT, you’ll move through your 5-hour session limits faster than before”. That’s about how fast your session limit drains, not about 529, but it does tell you when demand is highest. In Beijing time, 5am to 11am PT is 20:00 to 02:00 while the US is on daylight saving time, and 21:00 to 03:00 after daylight saving ends on November 1, 2026. I couldn’t find a newer official page confirming that the peak-hour rule is still in force.
I also lined up this month’s model incidents from the status page in Beijing time. Of the nine incidents in October that touched Claude Code and named a model, only two started inside that evening window. The rest started in the Beijing morning or afternoon. So working during Beijing daytime doesn’t protect you from a Claude Code 529 Overloaded error. It mainly helps your session limit last longer.

What other users are seeing
You’re not alone. A GitHub search of anthropics/claude-code for “529 Overloaded” in the title returned 114 issues when I checked. The most active one, issue #3572 from July 2025, has 274 comments. More recent reports look the same: issue #78535 from July 2026 shows 529 Overloaded · Retrying in 0s · attempt 10/10, and one user counted 322 logged 529 events across 13+ days between June 8 and July 9, 2026 in issue #75953.
If you also use Codex, it has its own version of this error with a different wording. I covered it in Selected model is at capacity in Codex, and the two tools are compared in Claude Code vs Codex.
Claude Code 529 Overloaded FAQ
Does a 529 use up my Pro or Max limit?
No. The Claude Code docs say a 529 “is not your usage limit and doesn’t count against your quota.”
Will upgrading from Pro to Max stop 529 errors?
I couldn’t find anything official saying a higher plan avoids 529. Anthropic describes it as high traffic across all users. Max gives you more usage per session, which helps with 429 session limits, not with capacity. If you’re deciding between plans anyway, I compared them in Claude Pro vs Max.
Why does it fail right away on Opus with my API key?
That’s documented. With an API key on an Opus model, Claude Code stops retrying at the third 529 and shows the error. Setting a fallback model makes it switch instead.
Is a 529 the same as “Server is temporarily limiting requests”?
No. That message is a short 429 throttle that Claude Code tells apart by the missing quota headers, and the docs label it “not your usage limit”. Claude Code retries it automatically on v2.1.199 or later.
Can I make Claude Code keep retrying in CI?
Yes. Set CLAUDE_CODE_RETRY_WATCHDOG=1 and it retries 429 and 529 capacity errors indefinitely, and you can cap the wait with CLAUDE_CODE_RETRY_WATCHDOG_MAX_WAIT_MS.