Claude-Fehler 529 (overloaded_error): Ursachen und Vorgehensweise

529 ist der einzige Claude-Fehler, der nicht durch deinen Code verursacht wird. Überlastet ist Anthropic; du kannst das nicht selbst beheben. Du kannst den Fehler nur „sauber auffangen“ — mit beharrlichen Retries und exponentiellem Backoff, einem Fallback-Modell für latenzkritische Pfade und ohne sofortige Retry-Stürme, die den Ausfall weiter verschärfen. Diese drei Maßnahmen sind alles, was du tun kannst.

Der Fehler

レスポンス（HTTP 529）

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

Ursachen und Lösungen im Überblick

Ursache	Lösung
Überlastung auf Anbieterseite (Veröffentlichung eines neuen Modells, regionaler Ausfall). Sie tritt gleichzeitig bei allen Nutzern auf.	Mit Backoff und Jitter warten. Nicht die App neu deployen, sondern die Statusseite von Anthropic prüfen.
Dein eigener Burst-Traffic traf auf bereits angespannte Kapazitäten.	Batchverarbeitung zeitlich verteilen. Eine Verzögerung von nur 10 Minuten behebt das meistens.
Verwechslung mit 429. In den Logs sehen sie ähnlich aus, aber die Ursachen sind völlig verschieden.	429 bedeutet, dass du dein Limit überschritten hast (der Server ist normal), 529 bedeutet, dass der Server überlastet ist (Guthaben und Limit sind normal). Nur 429 enthält Retry-After.
Es ist kein Fallback definiert, sodass das Anbieterproblem unverändert bis zum Endnutzer gelangt.	Die Reihenfolge der Fallbacks festlegen. Innerhalb derselben Modellfamilie (Sonnet → Haiku) ist das Verhalten ähnlich; über Anbieter hinweg (Claude → GPT) lässt sich auch ein vollständiger Ausfall überstehen.

Retries so gestalten, dass der Ausfall nicht verschärft wird

Behandle 529 wie „429 ohne Retry-After“. Beginne mit exponentiellem Backoff ab etwa 2 Sekunden, füge Jitter hinzu, begrenze die Wartezeit auf 30–60 Sekunden, gib nach ungefähr 5 Versuchen auf und verschiebe die Aufgabe in eine Warteschlange. Entscheidend ist der Jitter. Ohne ihn kehren alle Clients im selben Moment zurück und verlängern genau die Überlastung, der sie entkommen wollten.

Nicht verwerfen, sondern umleiten

Für latenzkritische Pfade eine Fallback-Kette vorbereiten. Bei einem OpenAI-kompatiblen Endpunkt musst du nur eine Zeichenfolge ändern — weder zusätzliche SDKs noch weitere Konten sind nötig:

failover.py

PREFERRED = ["claude-sonnet-5", "claude-haiku-4-5", "gpt-5-6-terra"]

def complete(messages):
    last = None
    for model in PREFERRED:
        try:
            return client.chat.completions.create(
                model=model, messages=messages, max_tokens=800)
        except APIStatusError as e:
            if e.status_code not in (429, 500, 529):
                raise
            last = e          # 過負荷 — 次の候補へ
    raise last

Den eigenen Code erst zuletzt verdächtigen

Wenn nur eine bestimmte Anfrageart mit 529 fehlschlägt, während andere Aufrufe zur selben Zeit funktionieren, handelt es sich nicht um einen vollständigen Ausfall. Prüfe, ob dieser Pfad ungewöhnlich große Prompts sendet oder in einer kurzen Schleife wiederholt aufgerufen wird. Wenn dagegen alle Aufrufe gleichzeitig mit 529 fehlschlagen und sich die Lage nach einiger Zeit von selbst beruhigt, ist die Ursache die Kapazität. Dann solltest du Retries und Fallbacks anpassen, nicht den Code refaktorieren.

Wenn Sie Kunavo verwenden

Kunavo verteilt Claude auf mehrere vorgelagerte Pfade. Dank des Multimodellkatalogs bedeutet der anbieterübergreifende Fallback lediglich, „bei demselben Schlüssel und demselben Guthaben den Modellnamen zu ändern“. Du brauchst für den obigen Code kein zweites Konto. Dennoch werden erreichte 529-Fehler nicht berechnet. Kapazität und Preis sind zwei verschiedene Fragen. Für Letzteres findest du die Preise pro Modell in der Claude-API-Preisliste.

Häufig gestellte Fragen

Ist 529 meine Schuld?

Nein. Es handelt sich um ein Kapazitätsproblem auf Anbieterseite. Deine Verantwortung besteht nur in zwei Punkten: den Ausfall nicht zu verstärken (Backoff und Jitter) und einen Ausweichpfad bereitzuhalten, wenn der Ausfall die zulässige Latenz überschreitet.

Was ist der Unterschied zwischen 529 und 429?

429 bedeutet, dass du dein Limit überschritten hast; der Server selbst ist normal. 529 bedeutet, dass der Server überlastet ist; dein Limit und dein Guthaben sind normal. Beide Fehler können wiederholt werden, aber nur 429 enthält den Hinweis Retry-After.

Wie lange dauert 529 normalerweise?

Das lässt sich nicht vorhersagen oder garantieren. Deshalb ist die richtige Lösung ein begrenzter Backoff mit Warteschlange, nicht eine fest im Code verankerte Wartezeit. Wenn dieser Pfad eine zulässige Latenz hat, übernimmt der Fallback, statt dass du weiter wartest.

Werden Aufrufe, die mit 529 fehlschlagen, trotzdem berechnet?

Über Kunavo werden sie nicht berechnet. Anfragen, die mit einem Fehler enden, sind nicht abrechenbar. Bei einem direkten Vertrag gelten die Abrechnungsregeln des jeweiligen Anbieters.

Claude API 529 overloaded_error — Bedeutung und richtige Vorgehensweise