529 overloaded_error on Anthropic: what it means and why go2llm rarely shows it

A 529 with overloaded_error means Anthropic's own API is temporarily overloaded — that's the vendor's own wording, not a problem with your key, your balance, or a specific request. go2llm doesn't have this status at all: the gateway sits in front of several routes to the model and can switch to a working one before the first byte of a response comes back, so a go2llm client usually never sees anything like a 529 — only a 502 or 503, and only once no working route is left.

Written 2026-09-22.

What the error looks like on Anthropic

The direct API at api.anthropic.com returns status 529 with this body:

{
  "type": "error",
  "error": {
    "type": "overloaded_error",
    "message": "Overloaded"
  },
  "request_id": "req_011CSHoEeqs5C35K2UUqR7Fy"
}

Anthropic's own docs put it plainly: "529 errors can occur when the API experiences high traffic across all users" — the overload is shared across every API user, not a limit tied to your account. Source: platform.claude.com/docs/en/api/errors, checked 2026-09-22.

Claude Code, hitting a 529 from the direct API, typically prints a short error in the terminal and ends the current request — the same as it does for any other 5xx from the vendor.

What actually causes it

Anthropic's infrastructure is overloaded across every customer

The only cause Anthropic names officially is a traffic spike across the whole API, not your own request volume. Anthropic is explicit that a sudden jump in your own traffic is more likely to trigger a 429 from acceleration limits than a 529 — these are two different protection mechanisms, and they don't share a cause.

go2llm's own error table has no 529 code

go2llm's list of error codes skips 529 entirely. When a request to a provider fails, the gateway returns 502 upstream_unavailable; when the product is paused or nothing is left to route to, it returns 503 product_paused or 503 no_eligible_route. The codes and the wording differ, but underneath they cover the same situation Anthropic's 529 describes: no answer from the model right now.

Why one overloaded route often goes unnoticed on go2llm

go2llm can switch to a compatible fallback route for the same model on eligible error classes, as long as the response hasn't started — before the first byte, or before the first valid SSE event. Inside that window the switch happens silently and the client gets a 200 instead of an error. Once the response has started, there's no more switching: a stream that begins and then breaks is a separate situation, not the same thing as a 529 from the vendor. Anthropic's direct API has no such fallback, by construction — it's one piece of infrastructure, and a 529 there reaches the client directly.

Fixing it

If you talk to api.anthropic.com directly. Anthropic's own advice is to retry with exponential backoff. The official SDKs already do this: two attempts by default, exponential backoff, honoring the retry-after header when it's present. A manual retry should follow the same shape:

import random, time
import httpx

def call_anthropic_with_retry(payload, api_key, max_attempts=3, base=1.0, cap=16.0):
    with httpx.Client(timeout=60.0) as client:
        for attempt in range(max_attempts):
            r = client.post(
                "https://api.anthropic.com/v1/messages",
                headers={
                    "x-api-key": api_key,
                    "anthropic-version": "2023-06-01",
                    "content-type": "application/json",
                },
                json=payload,
            )
            if r.status_code != 529:
                return r
            if attempt == max_attempts - 1:
                return r
            delay = min(cap, base * (2 ** attempt))
            time.sleep(delay * (0.5 + random.random() / 2))

If you'd rather not think about 529 at all. Point the same client at go2llm — the same two variables as always:

export ANTHROPIC_BASE_URL=https://go2llm.tech
export ANTHROPIC_AUTH_TOKEN=YOUR_API_KEY
export ANTHROPIC_MODEL=claude-sonnet-5
claude

That doesn't make Anthropic's own overload disappear — if every route eligible for your request is overloaded, go2llm still returns a 502 or 503 carrying the same meaning as the vendor's 529. The difference is that up to that point, the gateway gets a shot at switching quietly, which a direct connection to one vendor doesn't have by design.

Telling 529 apart from similar errors

529 overloaded_error is not the same thing as 429 rate_limit_error. A 429 comes from limits on your own organization or key — quota, RPM, a spend cap. A 529 comes from load on the API as a whole and has nothing to do with your account. Both are safe to retry outright, but 429 carries an extra rule: don't ramp up request volume sharply, because Anthropic separately warns that a sudden spike from one account can hit acceleration limits and produce a 429 even while the formal quota is untouched.

go2llm's closest equivalent code is 503 no_eligible_route — no permitted route was available for the request right now. 429 rate_limit and 429 quota on go2llm are a separate story: the 20 RPM per-key ceiling and the dollar balance, not infrastructure load.

Related errors

429 rate_limit_error — a request-rate limit, not an API-wide overload.
401 authentication_error — when the problem is the key, not model availability.
The full error reference.

FAQ

Can go2llm return a 529? No. go2llm's own error table doesn't include it — the gateway is limited to the codes it generates itself: 400–405, 409, 413, 429, 502, 503. The same underlying situation, a model that's unavailable right now, shows up on go2llm as 502 upstream_unavailable or 503 no_eligible_route.

Does the missing 529 mean overloads never happen? No — it means some single-route overloads get absorbed by automatic switching before the first byte of a response, and the rest surface under other codes (502, 503) carrying the same "try again shortly" logic. None of this guarantees full availability: that still depends on the upstream providers.

Should you retry a 529 forever? No. Anthropic's official SDKs cap automatic retries at two attempts by default. If the error is still there after a few backoff attempts, that's sustained overload rather than a short spike — either wait longer or move to a route with automatic fallback.

Get a key and make your first request in 3 minutes → go2llm.tech. Per-model prices are on the pricing page, setup steps are in the docs.