Anthropic API Error 529: overloaded_error — Meaning and Fixes

Quick answer

HTTP 529 overloaded_error means Anthropic's servers are temporarily saturated — a capacity problem on the provider side, not your key, quota, or code. The fix is to retry with exponential backoff plus jitter (code below) and keep a fallback path so one overloaded upstream can't stall your app. Unlike 429, it has nothing to do with your own rate limits.

What the Error Looks Like

The Anthropic API returns HTTP status 529 with this JSON body:

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

Typical symptoms:

• Errors arrive in bursts — a few minutes of failures, then normal service, usually around peak US/EU hours or right after a model launch.
• With stream: true, the overload can surface as an error event mid-stream instead of an HTTP status, so streaming code needs the same handling.
• Your dashboard shows nothing wrong — that's the tell: 529 is their load, not your usage.

A request rejected with 529 was not processed, so no tokens are billed for it.

529 vs 429: Not the Same Problem

The two get conflated constantly, but the fixes differ:

	429 rate_limit_error	529 overloaded_error
Whose problem	Yours — you exceeded your account's RPM/TPM limits	Anthropic's — their fleet is saturated
Scope	Only your account/workspace	Everyone hitting the congested capacity
Signal	Often includes a retry-after header	No retry hint; back off blindly
Correct fix	Throttle your traffic, request higher limits	Backoff + retry, fallback routing
Prevention	Client-side rate limiter, token budgeting	You can't prevent it — only absorb it

Seeing 429? Look at your concurrency. Seeing 529? Look at your retry logic.

Why 529 Happens

1. Demand spikes — model releases, viral workloads, and business-hours peaks in the US and Europe saturate shared capacity.
2. Heavy requests during congestion — long contexts and large max_tokens values occupy servers longer, so they're likelier to be shed under load.
3. Your own burst landing in a hot window — a batch job firing 200 parallel requests at 9am Pacific is asking for it.
4. Incidents — sustained 529s usually correlate with an entry on status.anthropic.com.

Fix 1: Exponential Backoff with Jitter (Python)

Retry on 429 and 529 only, double the delay each attempt, add jitter so parallel workers don't retry in lockstep, and cap the delay:

import random
import time

import anthropic
from anthropic import APIStatusError

client = anthropic.Anthropic(max_retries=0)  # we own the retry loop

def create_with_backoff(max_retries: int = 5):
    for attempt in range(max_retries + 1):
        try:
            return client.messages.create(
                model="claude-sonnet-5",
                max_tokens=1024,
                messages=[{
                    "role": "user",
                    "content": "Summarize this changelog in three bullet points.",
                }],
            )
        except APIStatusError as e:
            retryable = e.status_code in (429, 529)
            if not retryable or attempt == max_retries:
                raise
            delay = min(2 ** attempt + random.uniform(0, 1), 60)
            time.sleep(delay)

Fix 2: Exponential Backoff with Jitter (TypeScript)

import Anthropic from "@anthropic-ai/sdk";

const client = new Anthropic({ maxRetries: 0 }); // we own the retry loop

async function createWithBackoff(maxRetries = 5) {
  for (let attempt = 0; ; attempt++) {
    try {
      return await client.messages.create({
        model: "claude-sonnet-5",
        max_tokens: 1024,
        messages: [
          { role: "user", content: "Summarize this changelog in three bullet points." },
        ],
      });
    } catch (err) {
      const status = err instanceof Anthropic.APIError ? err.status : undefined;
      const retryable = status === 429 || status === 529;
      if (!retryable || attempt >= maxRetries) throw err;
      const delay = Math.min(2 ** attempt * 1000 + Math.random() * 1000, 60_000);
      await new Promise((resolve) => setTimeout(resolve, delay));
    }
  }
}

Fix 3: Or Just Tune the SDK's Built-in Retries

Both official SDKs already retry 429 and 5xx-class errors (529 included) with backoff — 2 retries by default. Often one parameter is enough:

client = anthropic.Anthropic(max_retries=4)

Use the manual loop instead when you need per-attempt logging, a fallback model on final failure, or a shared retry budget across workers.

Fix 4: Degrade Gracefully

Retries alone won't save you during a sustained overload window. Add a second layer:

• Fallback model — if claude-opus-4-8 keeps returning 529, retry the final attempt on claude-sonnet-5; capacity pools differ per model.
• Queue instead of fail — push non-interactive jobs onto a queue and drain it after the spike.
• Cap concurrency during peaks — fewer simultaneous heavy requests means less exposure when load-shedding starts.

How a Multi-Channel Gateway Shrinks the 529 Surface

A single API key means a single path: when it returns 529, your only options are wait or fail. An AI API gateway changes the shape of the problem.

byesu maintains multiple upstream channels for the same model and, when an upstream call fails with an overload-class error, automatically retries it on a different channel — a transient 529 on one path is often absorbed before your code ever sees it. Keep client-side backoff as the last line of defense; the error rate reaching it just drops.

Two more properties help here:

• One key, many models — Claude, GPT-5.6, Grok, and Gemini sit behind the same token via both an OpenAI-compatible /v1/chat/completions and an Anthropic-native /v1/messages endpoint, so model-level fallback is a one-string change in your retry handler.
• Pay-as-you-go — no subscription; billing is per token with transparent group multipliers (input 1x, output 5x, cache hit 0.1x) and a live billed price in the console. Top up with USDT, Alipay or WeChat Pay.

No gateway can make overloads disappear — capacity is finite everywhere. What it removes is the single-path failure mode.

Monitoring Recommendations

• Count 529 and 429 as separate metrics. Mixing them into one "error rate" hides whether the fix is throttling (429) or fallback (529).
• Alert on sustained rate, not single events. Occasional 529s are normal; alert when they exceed a few percent of requests over 5–10 minutes.
• Log the request-id response header on every failure — support and incident correlation both need it.
• Subscribe to status.anthropic.com to distinguish a platform incident from a local bug.
• Cap retry budgets. Five retries with a 60s ceiling is a sensible default; unbounded retries turn a 10-minute incident into an hour of self-inflicted queue pressure.

FAQ

What does Anthropic API error 529 overloaded_error mean?

HTTP 529 with error type overloaded_error means Anthropic servers are temporarily overloaded and cannot accept the request. It is a capacity issue on the provider side, not a problem with your API key, quota, or request format. The standard fix is to retry with exponential backoff and jitter.

What is the difference between error 529 and error 429?

429 rate_limit_error means your account exceeded its own rate limits (requests or tokens per minute) and usually includes a retry-after header. 529 overloaded_error means Anthropic infrastructure is saturated regardless of your limits. 429 is fixed by throttling your own traffic; 529 is fixed by backoff, retries, and fallback routing.

How do I fix Claude API 529 overloaded errors?

Retry with exponential backoff plus jitter (for example 1s, 2s, 4s, 8s with a random component and a cap), keep concurrency modest during peak hours, and add a fallback path such as another model or a multi-channel gateway that can route around the overloaded upstream.

Does the Anthropic SDK retry 529 errors automatically?

Yes. The official Python and TypeScript SDKs automatically retry 429 and 5xx-class errors, including 529, with exponential backoff — two retries by default. Raise the limit with the max_retries option, or set it to 0 and implement your own retry loop.

Can an API gateway reduce 529 overloaded errors?

It can shrink how often your app sees them. A gateway such as byesu keeps multiple upstream channels for the same model and automatically retries a failed upstream call on a different channel, so a transient 529 on one path is often absorbed before it reaches your code. One key also covers Claude, GPT-5.6, Grok, and Gemini, so model-level fallback is a one-string change.

Am I billed for requests that fail with 529?

No. A request rejected with 529 was not processed, so no input or output tokens are consumed. Retrying is safe from a billing standpoint, though each retry adds latency — use a capped backoff so a prolonged outage fails fast instead of hanging.

Related Links

• Common Errors & Fixes — 401, insufficient balance, no available channel, timeouts
• Quick Start (3 steps) — create a token · set the address · pick a model
• Claude Opus 4.8 · Claude Sonnet 5 — call examples
• Console Sign-up / Create Token — get an sk- token and see live pricing