Claude API Returning 529 overloaded_error? How It Differs From 429 and What Actually Helps
529 means Anthropic is at capacity — not that you exceeded a quota, not that your key is wrong, not a bug in your code. It is the mirror image of 429, and the fixes are opposite.
First, work out which one you have
Read the `type` field in the response body: `overloaded_error` is 529, `rate_limit_error` is 429. **Do not skip this** — the fixes point in opposite directions. Cutting concurrency is the right answer for 429 and nearly useless for 529, because the bottleneck is not on your side. Plenty of people respond to a 529 by throttling their own traffic, which slows their product without improving anything.
Why switching model tier works so well for 529
Anthropic schedules capacity **per model**. Frontier models saturate first under load, and at the same moment the mid and small tiers are frequently fine. So the first instinct on a 529 should not be to wait — it should be to drop a tier and keep going. For most tasks the mid tier finishes the job, and finishing beats waiting. This is the second value of tiered routing, beyond cost: **it doubles as a failover path.**
Backoff needs jitter
Retry at 1s, 2s, 4s, 8s — and add a random offset to each delay. Without jitter, every client rejected in the same second retries in the same second and re-saturates a service that was just recovering. Also cap the attempts (three to five is typical); an uncapped retry loop turns an availability problem into a billing problem. The official SDKs retry twice and honour `retry-after` — match that behaviour if you write your own loop.
Make long jobs resumable
The worst 529 is the one that lands twenty minutes into a job and voids the whole run. The fix is structural: split long work into independently retryable segments and persist after each. Then a 529 costs you one segment instead of everything. This has nothing to do with 529 specifically — it determines how much any transient failure costs you.
Whether a fallback path is worth building
It depends on whether your product can tolerate waiting ten minutes. If it can, backoff is enough and a second path is over-engineering. If it cannot — anything user-facing and real-time — a second route is worth the setup. Using an OpenAI-compatible endpoint makes that switch nearly free: change the model string, keep the SDK, keep the auth. cocodot serves Claude, GPT and Gemini on one key and one balance for exactly this reason: switching tier is a config line, not a migration.
Being clear about what a gateway cannot do
**No gateway makes 529 disappear.** Upstream capacity is Anthropic's capacity, and adding a hop does not create compute — anyone claiming their service is immune to 529 is telling you something that cannot be true. What a gateway can offer is different: one key across several providers so dropping a tier is a one-line change, and failed calls that are not billed, so retries do not charge you for results you never received.
529 and 429 are different problems
| 529 overloaded_error | 429 rate_limit_error | |
|---|---|---|
| Cause | Service-wide saturation | You exceeded your own limits |
| Related to your account | No | Directly |
| Consumes quota | No | Already counted |
| Does lowering concurrency help | Barely | Yes — that is the fix |
| Does switching model help | **Yes** (capacity is per-model) | Not necessarily |
| What to do | Back off, switch model, wait | Slow down, add a client-side limiter |