Inhaltsverzeichnis
Wurdest du in Claude Code schon einmal mitten in einer Aufgabe von einem Fehler wie diesem gestoppt?
API Error: 529 {"type":"error","error":
{"type":"overloaded_error","message":"Overloaded"}}
# oder
API Error: 500 Internal server error.
529 Overloaded bedeutet, dass die API von Anthropic vorübergehend über ihrer Kapazität (ausgelastet) ist, und 500 bedeutet, dass im Server ein unerwarteter Fehler aufgetreten ist. Beides liegt auf der Serverseite — und, am wichtigsten: es ist kein Fehler in deiner Anfrage oder deinen Einstellungen und auch nicht dein aufgebrauchtes Nutzungskontingent. Die offizielle Dokumentation sagt unmissverständlich, dass „ein 529 nicht dein Nutzungslimit ist und nicht auf dein Kontingent angerechnet wird". Mit anderen Worten: Das ist die Art Fehler, die sich meist mit „kurz warten und erneut versuchen" von selbst erledigt.
Die Kernpunkte vorweg. (1) 529/500 liegen auf der Serverseite — nicht deine Schuld (und verbrauchen kein Kontingent). (2) Claude Code wiederholt bereits automatisch bis zu 10 Mal mit exponentiellem Backoff, bevor dir überhaupt etwas angezeigt wird — wenn die freundliche Meldung erscheint, sind diese Wiederholungen schon aufgebraucht. (3) Die Lösung lautet „Statusseite prüfen → warten → mit /model das Modell wechseln". Die Kapazität wird pro Modell verwaltet, also kommt selbst dann, wenn Opus ausgelastet ist, Sonnet oft durch.
Das liegt am Server, nicht an dir
— Claude Code wiederholt bereits, bevor dir etwas angezeigt wird
Die Lösung lautet also „warten und erneut versuchen / mit /model wechseln / status.claude.com prüfen".
Es gibt im Grunde keinen Code und keine Einstellung zu reparieren.
1. Was dieser Fehler dir sagt
HTTP 529 (overloaded_error / Meldung „Overloaded") ist ein Zeichen dafür, dass die API von Anthropic vorübergehend über ihre Kapazität ausgelastet ist. Die offizielle Beschreibung lautet wörtlich „die API ist vorübergehend überlastet" und „kann auftreten, wenn APIs über alle Nutzer hinweg hohen Traffic erfahren". Das bedeutet: nicht die Schuld einer einzelnen Person, sondern dass die Gesamtnachfrage kurzzeitig das Angebot überstieg.
HTTP 500 (api_error) ist ein unerwarteter interner Fehler auf der Seite von Anthropic. Die Dokumentation sagt, er werde „nicht durch deinen Prompt, deine Einstellungen oder deinen Account verursacht". Verwandt ist 504 (timeout_error), wenn eine lange Anfrage in eine Zeitüberschreitung läuft (zu beachten ist, dass Anthropic 504 dokumentiert, während 502/503 meist von vorgelagerter Infrastruktur wie Gateways stammen).
Der entscheidende Punkt: „529 und 500 sind serverseitige Probleme und verbrauchen dein Nutzungskontingent nicht." Sie unterscheiden sich völlig vom Plankontingent usage limit reached und von deinem eigenen Ratenlimit 429 (wir grenzen das in §4 ab). Es besteht also kein Grund, sich zu verkrampfen und Code oder Einstellungen zu reparieren — die Standardlösung ist „warten und erneut versuchen".
2. Claude Code wiederholt bereits für dich
Tatsächlich hat Claude Code, bevor du die Fehlermeldung überhaupt siehst, im Hintergrund schon wiederholt. Laut offizieller Dokumentation —
Das automatische Wiederholungsverhalten
Serverfehler, Overloaded-Antworten, Zeitüberschreitungen von Anfragen, vorübergehende 429-Drosselungen und abgebrochene Verbindungen werden alle bis zu 10 Mal mit exponentiellem Backoff wiederholt. Während der Wiederholung zeigt der Spinner einen Retrying in Ns · attempt x/y-Countdown. In dem Moment, in dem die freundliche API Error:-Zeichenfolge erscheint, sind diese 10 Wiederholungen aufgebraucht.
Daher ist „kurz blitzte ein 529 auf, aber es lief weiter" normal — die automatische Wiederholung hat ihn abgefangen. Umgekehrt ist es, wenn du bis zur freundlichen Meldung gelangst („Repeated 529 Overloaded errors … try again in a moment. If it persists, check https://status.claude.com"), ein Zeichen dafür, dass die Last so stark ist, dass sich selbst die Wiederholungen nicht erholt haben. Du kannst die Wiederholungen über CLAUDE_CODE_MAX_RETRIES (Standard 10) und die Obergrenze pro Anfrage über API_TIMEOUT_MS (Standard 600000 ms = 10 Minuten) anpassen — senke die Anzahl, um in Skripten schnell zu scheitern, erhöhe sie, um einen längeren Vorfall durchzuwarten.
3. Was du tun kannst
Die Maßnahmen bei einem 529/500 sind eigentlich sehr einfach. Probiere sie der Reihe nach durch.
Warten, wechseln, prüfen
/feedback (gib die request_id an, um die Untersuchung zu beschleunigen).
Unsicher? 1) warten → 2) mit /model wechseln → 3) Status prüfen.
Auch das Verlegen in Nebenzeiten hilft. Es gibt im Grunde keine Einstellung zu reparieren.
Hinweis: Die Meldung „Server is temporarily limiting requests" wird offiziell ebenfalls als „eine kurzlebige serverseitige Drosselung ohne Bezug zu deinem Nutzungslimit" beschrieben. Auch sie erledigt sich mit kurzem Warten und ist etwas anderes als das Plankontingent usage limit.
4. Abgrenzung zu ähnlichen Fehlern
Die „es hat gestoppt"-Familie kann gegensätzliche Ursachen haben. Trenne zuerst nach „Serverseite oder deine Seite?"
| Fehler | Wessen Problem | Verbraucht Kontingent? | Hauptlösung |
|---|---|---|---|
| 529 Overloaded | Serverseite (Kapazität, betrifft alle) | Nein | Warten & erneut versuchen, /model, Status prüfen |
| 500 / 504 | Serverseite (interner Fehler / Zeitüberschreitung) | Nein | Erneut versuchen; bei Anhalten /feedback |
| 429 Rate limit | Deine Seite (Ratenlimit deines API-Schlüssels) | Ja (deine Rate) | Tempo drosseln, Tier erhöhen, retry-after abwarten |
| usage limit reached | Deine Seite (Kontingent des Pro/Max-Plans) | Ja (Plan) | Auf Reset warten; Lösungen |
| 400 Invalid request | Deine Seite (eine fehlerhafte Anfrage) | Nein | Den Anfragetext korrigieren |
Eine Eselsbrücke: 5xx (einschließlich 529) liegt auf der Serverseite = es erledigt sich, wenn du wartest. 429 und usage limit drehen sich um deine „Menge" = passe Rate oder Plan an. 400 dreht sich um deinen „Inhalt" = korrigiere die Anfrage. 429 und 529 sind besonders leicht zu verwechseln, aber 429 trägt einen retry-after-Header und verbraucht Kontingent, während 529 keinen Header trägt und kein Kontingent verbraucht — verschiedene Dinge. Zu weiteren häufigen Claude-Code-Fehlern siehe die Fehlerübersicht.
5. Für Entwickler (API/SDK)
Wenn du deine eigene App über die API/SDK betreibst, behandelt das richtige Design 529/500 als „ein vorübergehendes Ereignis, das normalerweise auftreten kann".
(1) Die offiziellen SDKs werfen typisierte Ausnahmen (OverloadedError, InternalServerError usw.) und wiederholen vorübergehende Fehler automatisch mit exponentiellem Backoff — fange die Ausnahmeklassen ab, keine String-Vergleiche. (2) Wenn du selbst wiederholst, nutze „exponentielles Backoff + Jitter". (3) Der retry-after-Header ist bei 429 vorhanden, NICHT aber bei 529, warte daher bei einem 529 mit deinem eigenen Backoff, nicht mit headergesteuertem Timing. (4) Halte ein Fallback-Modell bereit (Claude Code hat --fallback-model). (5) Steigere den Traffic schrittweise, um das 429-„Beschleunigungslimit" nach einer Nutzungsspitze zu vermeiden. Wenn du eine stetige Verfügbarkeit brauchst, sind auch Priority Tier und die Message Batches API Optionen. Zu den Grundlagen siehe Was ist eine KI-API.
6. Kurzzeitige Spitze oder ein Vorfall?
Dasselbe 529/500 bedeutet Unterschiedliches, je nachdem, ob es „eine Spitze ist, die sofort verschwindet" oder „ein anhaltender Ausfall, der sich wiederholt".
Eine kurzzeitige Spitze (einer oder wenige, die sich beim erneuten Versuch erledigen) liegt im normalen Bereich der Nachfrageschwankung. Die automatische Wiederholung fängt sie meist ab, und auf deiner Seite gibt es nichts zu reparieren. Andererseits ist „Repeated 529" oder ein 500, der die Wiederholungen übersteht, ein Zeichen, einen aktiven Vorfall zu vermuten — prüfe zuerst status.claude.com, und ist ein Ausfall gemeldet, ist auf die Wiederherstellung zu warten der einzig richtige Schritt. Hält ein 500 ohne gemeldeten Vorfall an, melde ihn über /feedback mit der request_id. So oder so kann ein Nutzer bei 529/500 nur „erneut versuchen, mit /model wechseln, Status prüfen und melden" — und das genügt tatsächlich.
Zusammenfassung
Claude Codes „API Error: 529 Overloaded" und „500 Internal server error" sind serverseitige Ereignisse, bei denen die API von Anthropic vorübergehend überlastet ist oder auf einen internen Fehler stößt. Sie sind kein Fehler in deiner Anfrage oder deinen Einstellungen, nicht dein aufgebrauchtes Kontingent, und sie verbrauchen kein Kontingent. Claude Code wiederholt automatisch bis zu 10 Mal mit exponentiellem Backoff, bevor dir überhaupt etwas angezeigt wird; die freundliche Meldung bedeutet, dass diese Wiederholungen aufgebraucht sind.
Die Lösung ist einfach: (1) warten und erneut versuchen -> (2) mit /model das Modell wechseln (Kapazität ist pro Modell) -> (3) status.claude.com prüfen -> (4) /feedback, wenn ein 500 anhält. Sie sind verschieden von 429 (deine Rate) und usage limit (dein Plan), und 529 trägt keinen retry-after. Entwickler sollten darum herum entwerfen mit der automatischen Wiederholung des SDK, exponentiellem Backoff + Jitter und einem Fallback-Modell. Wenn es sich wiederholt, vermute einen Vorfall und prüfe die Statusseite — so oder so gibt es im Grunde keinen Code und keine Einstellung zu reparieren. Verwandt: Lösungen für das Nutzungslimit, Vergleich Opus/Sonnet/Haiku, Claude-Code-Fehlerübersicht.
FAQ
Q. Wird „529 Overloaded" durch etwas verursacht, das ich falsch gemacht habe, oder durch meinen Code?
A. Nein — es ist ein serverseitiges Problem. Ein 529 bedeutet, dass die API von Anthropic vorübergehend über ihrer Kapazität ist (Engpass über alle Nutzer hinweg); deine Anfrage, deine Einstellungen und dein Account sind nicht beteiligt. Die Dokumentation sagt unmissverständlich, dass „ein 529 nicht dein Nutzungslimit ist und nicht auf dein Kontingent angerechnet wird." Es erledigt sich meist, wenn du kurz wartest und erneut versuchst.
Q. Es sagt mir ständig, ich solle es erneut versuchen — soll ich es selbst durch wiederholtes Drücken erzwingen?
A. Im Allgemeinen nein. Claude Code wiederholt bereits automatisch bis zu 10 Mal mit exponentiellem Backoff, bevor der Fehler angezeigt wird (Retrying in Ns · attempt x/y). Die freundliche Meldung erschien, weil diese 10 Wiederholungen aufgebraucht wurden. Warte ein wenig, und gib bei einem langen Prompt einfach „try again" ein, um ihn mit dem ursprünglichen Kontext erneut auszuführen. Du kannst die Anzahl mit CLAUDE_CODE_MAX_RETRIES anpassen.
Q. Was ist der Unterschied zwischen 529 und 429?
A. 529 ist eine serverseitige Überlastung (betrifft alle; verbraucht kein Kontingent von dir), während 429 dein eigenes Ratenlimit ist (du hast die RPM deines API-Schlüssels o. Ä. überschritten — es geht um dein Ratenkontingent). Ein Erkennungsmerkmal: 429 trägt einen retry-after-Header, 529 nicht. Ein 429 erfordert eine Anpassung auf deiner Seite (Tempo drosseln, Tier erhöhen); ein 529 braucht nur warten und erneut versuchen oder einen /model-Wechsel.
Q. Warum funktioniert der Wechsel mit /model manchmal?
A. Weil die Kapazität (der Engpass) pro Modell verwaltet wird. Selbst wenn Opus unter hoher Last steht, kommt Sonnet möglicherweise sofort durch, wenn es Spielraum hat. Claude Code selbst schlägt unter Last manchmal einen Wechsel vor („Opus is experiencing high load, please use /model to switch to Sonnet"). Wenn du es eilig hast, ist der Wechsel zu einem leichteren oder anderen Modell mit /model eine schnelle Behelfslösung.
Q. Ich bekomme ununterbrochen 529/500. Was soll ich tun?
A. Vermute einen aktiven Vorfall und prüfe status.claude.com. Ist ein Ausfall gemeldet, kannst du nur auf die Wiederherstellung warten. Hält ein 500 an, ohne dass ein Vorfall gemeldet ist, melde ihn über /feedback mit der request_id, damit Anthropic ihn untersuchen kann. Da 529/500 serverseitige Ereignisse sind, gibt es im Grunde keinen Code und keine Einstellung, die du reparieren kannst.