If Claude Code shows API Error: 529, start by treating it as overload, not as your personal rate limit. Anthropic defines 529 as overloaded_error, so the first split is whether Claude is in a live incident, whether the same path still fails on a green status page, whether you are actually looking at a 429, or whether Claude Code is using a route you did not expect.
Check the live Claude Status page first, then use /status together with your environment variables to confirm the path Claude Code is actually using before you change plans, keys, or local settings. If status is green, do one short same-path backoff retry or route check instead of several random changes at once, and verify that exact path before you widen the diagnosis.
If the same path still returns 529 after status and route checks, stop treating it like a local tuning problem and escalate with the exact error text plus any request_id. Anthropic's API error docs and Claude Code help pages were rechecked on April 11, 2026, and the public status page was green at that time. That dated note matters because a green page does not erase the overload branch. It only tells you the next move should be narrower.
30-Second Route Board
API Error: 529 is a routing problem before it is a theory problem. The question is not "what might be wrong in general?" The question is "which branch am I in right now, and what is the smallest correct move?" Start with the code correction first: if the line really says 429, stop here and switch playbooks. If it really says 529, stay on the overload route.
| What you are seeing | Most likely owner | Safest first move | Verify on the same path | Escalate when |
|---|---|---|---|---|
The line actually says 429 or a usage warning instead of 529 | Rate-limit or usage confusion, not true overload recovery | Switch to the rate-limit or usage diagnosis path before you keep retrying | Confirm the exact code and whether your real problem is plan or API usage | The exact code is still 529 after the confusion is cleared |
| Claude Status is red or an active incident is underway | Anthropic-side overload or degradation | Stop changing local settings and wait for recovery | Retry the same failing path after the incident clears | Status is green again and the same path still returns 529 |
| Status is green but the same path still returns 529 | Transient or localized overload | Do one short same-path backoff retry sequence | Confirm whether the exact path succeeds without changing unrelated variables | Repeated same-path retries still fail |
| Claude Code may be using an API key, proxy, or alternate provider route | ANTHROPIC_API_KEY override, proxy path, or unexpected auth owner | Check /status, environment variables, and route config first | Compare the same request on the intended route | The same route still fails with current evidence |
That table is the page. Everything else exists to help you choose the right row with more confidence. The main mistake is skipping the branch step and applying a generic recovery ritual: changing plans, rotating keys, logging out, reinstalling, or waiting indefinitely without learning anything.
What 529 Means and Why It Is Not 429
Anthropic's official API error documentation makes the core correction simple: 429 is rate_limit_error, while 529 is overloaded_error. To the reader, both can feel like "the service would not let me through." Operationally, they want different first moves.
If the code is really 529, the safe assumption is service saturation first. That means status, a bounded retry, and route verification matter more than quota theory. If the code is really 429, you are in a rate-limit or usage story instead. That is where our Claude Code token usage guide and the narrower Claude Code rate limit reached guide become the better pages.
This distinction is easy to blur because Claude Code users often describe every blocked request as "rate limited" or "overloaded." That language is understandable and still too sloppy for recovery. The exact code changes the next move. A 529 does not prove your personal plan is exhausted, and a 429 does not become overload just because the terminal session feels crowded.
The fastest practical habit is to read the exact code before you do anything expensive or disruptive. If the line says 529 or overloaded_error, keep this page. If it says 429 or a clearer usage warning, switch playbooks early instead of forcing the wrong one to fit.
If Claude Status Shows an Incident Right Now
Status comes first because it can save you from pointless local debugging. If Claude Status is red for the API, Claude Code, login, or a related component, the fastest safe move is usually to stop changing local settings and wait through the incident window.
That recommendation sounds obvious, but readers often resist it because overload errors feel personal. The failing request happened in your terminal, in your repo, on your subscription or API key. Still, an active status incident changes the expected value of every local experiment. Reauthenticating, reinstalling, or rotating keys during a live incident usually creates more noise than signal.
The useful move in this branch is small and disciplined. Keep the exact error text, note the time, and keep any request_id you have. Anthropic's error docs say error responses include a top-level request_id, and the request-id header appears on every API response. After status recovers, retry the same path that failed before. That same-path retry tells you whether the incident was the whole story or only part of it.
Do not let this branch expand into a universal explanation. A live incident is one real cause of 529. It is not the only cause worth considering. Once status is green again, the question changes from "is Anthropic degraded right now?" to "does the same path still fail after the degradation has passed?"
If Status Is Green but the Same Path Still Returns 529
A green status page does not mean you should start changing plans, keys, or local settings at random. It means you have ruled out one branch. You have not ruled out overload itself.
This is the most frustrating branch because it feels contradictory: the official code says overload, the public status page says healthy, and your terminal still fails. Official-repo issue threads such as #3558 and #3572 are useful here because they show the exact symptom can persist in Claude Code even when a reader thinks the public status surface looks fine. That evidence does not prove one universal root cause. It proves this branch is real enough to deserve its own recovery rule.
The right first move is a bounded same-path retry sequence. Do not turn that into endless retrying. Wait briefly, rerun the same action on the same route, and watch whether the behavior changes without introducing other variables. If you switch models, billing paths, auth routes, and session context all at once, you lose the one thing you need most: a clean answer about whether the original path recovered by itself.
This is also the branch where readers waste time on "large" fixes that feel productive but are poorly targeted. Reinstalling Claude Code, moving to a different plan, or rewriting shell config before you test the same path again is usually premature. The smaller question is still the better one: did the same request recover after a short pause, or does it fail consistently enough to justify escalation?
If repeated same-path retries still fail, stop turning one overload symptom into a general local-debugging marathon. Capture the evidence and escalate. A green status page plus repeated exact-path failure is not proof that the problem is yours. It is proof that you now have a sharper support case than "Claude seems overloaded."
If You May Actually Be on a Usage or API-Key Route
One reason 529 troubleshooting goes sideways is that users assume Claude Code is always using the route they think it is using. Anthropic's help page for Pro and Max plan users says that if ANTHROPIC_API_KEY is set, Claude Code uses that key instead of your subscription credentials. That one detail explains a lot of confused recovery attempts.
If you are sure you are on your Pro or Max plan, but your shell exports ANTHROPIC_API_KEY, stop assuming the subscription path owns the failure. Use /status, inspect your environment, and confirm which route is active before you interpret the error. A route mismatch does not automatically turn 529 into your fault. It does mean the wrong explanation may be sitting at the top of your mental stack.
The same caution applies if you are routing through a proxy, alternate provider, or wrapper. The first safe move is not provider shopping. It is to confirm the intended path, clear stale assumptions, and compare the same request on the route you actually meant to test. If the error disappears after removing the unexpected key or returning to the intended path, the route confusion was the branch. If the same intended path still fails with 529, then overload is still the better interpretation.
This section should also stay narrow. If the real problem turns out to be usage exhaustion, shared-plan drain, or API tier limits, move to the right sibling page instead of forcing everything through a 529 frame. Our Claude Code usage limits diagnosis guide is the right follow-up when the deeper complaint is fast drain or quota behavior. If the real symptom is 500, the better handoff is the dedicated Claude Code API Error 500 guide.
Verify the Fix and Know When to Escalate
Claude Code recovery gets faster once you stop asking "did anything change?" and start asking "did this exact path recover after one exact move?" That is why same-path verification matters so much. It prevents three common mistakes at once: random retries, accidental branch switching, and support reports with no usable evidence.
Before you escalate, capture the smallest useful evidence bundle from the same failing path:
- the exact error text, including
529oroverloaded_error - any
request_idorrequest-idvalue you can see - what Claude Status showed at the time
- whether the failure happened on the same path after a short retry, on a suspected wrong route, or after you corrected that route
- the minimum reproduction steps or relevant
/statusoutput
That list is short on purpose. A long diary of everything you tried is less useful than one clean reproduction story. "Green status, same path still returns 529 after a short retry, request_id attached" is actionable. "I changed a lot of settings and it still feels broken" is not.
The escalation boundary is also short: if status and route checks are done, the exact path still returns 529, and the retry stayed bounded, stop improvising. At that point you are less likely to fix the problem by getting more creative than by handing off clear evidence. The recovery job changes from "diagnose" to "report cleanly."
Frequently Asked Questions
Is Claude Code API Error: 529 the same as 429 rate_limit_error?
No. Anthropic's API error docs define them as different error types. 429 is the rate-limit branch. 529 is the overload branch.
Why can I still see 529 when Claude Status is green?
Because a green public status page only rules out the live-incident branch. It does not guarantee your exact Claude Code path has already recovered. That is why the next move is a short same-path retry or route check, not blind local changes.
Should I change plans or buy more usage when I see 529?
Not as a first move. 529 means overload first, not personal quota exhaustion. Confirm the exact code and route before you spend money or change billing assumptions.
What should I check if I expected the subscription path but Claude Code behaves differently?
Check whether ANTHROPIC_API_KEY is set and use /status plus your shell environment to confirm the active route. Anthropic's help docs say the API key overrides subscription auth when present.
What should I send to support?
Send the exact error wording, any request_id, what status showed, the path you tested, and the smallest reproduction you can describe. The goal is not to tell the whole story. It is to remove ambiguity.
The Working Rule
Claude Code API Error: 529 is worth treating as overload first, not as a personal rate-limit mystery. Check status, keep the path stable, make one bounded move, verify on that same path, and escalate with evidence if the path still fails.