Was 529 Overloaded tatsächlich bedeutet
Der Fehler besagt, dass dem Anbieter gerade die Kapazität fehlt – nicht, dass Ihre Anfrage falsch ist. Eine Änderung an Ihrem Code hilft nicht; eine Änderung Ihrer Retry-Strategie schon.
Aktualisiert 2026-09-20
Vier Punkte
Überlastung beim Anbieter
Wird zurückgegeben, wenn die serverseitige Kapazität knapp ist. Unabhängig vom Kontingent Ihres Keys, Ihren Parametern oder dem Request-Body.
Sie werden per Rate Limit gedrosselt
Dieser Fehler bedeutet, dass Sie Ihre eigene Rate oder Ihr eigenes Kontingent überschritten haben. 529 und 429 erfordern unterschiedliche Behandlung – teilen Sie sich keinen Codepfad.
Die einzige wirksame Maßnahme auf Client-Seite
Exponentielles Backoff mit Jitter. Sofortige Wiederholungen verschärfen die Überlastung und führen schneller zu einem Rate Limit.
Strukturelle Entschärfung
Wenn dieselbe Arbeit bei einem anderen Anbieter landen kann, bedeutet ein überlasteter Anbieter keinen Ausfall mehr. Der Preis dafür: Sie müssen Unterschiede zwischen den Modellen in Kauf nehmen.
Wie sich 529 von 429 und 503 unterscheidet
529 bedeutet, dass der Server gerade überlastet ist – ein Kapazitätsproblem, meist vorübergehend. 429 bedeutet, dass Sie Ihre eigene Rate- oder Kontingentgrenze erreicht haben – ein Kontingentproblem. 503 bedeutet in der Regel, dass der Dienst nicht verfügbar ist oder gewartet wird. Keiner dieser Codes heißt, dass Ihre Anfrage fehlerhaft war, aber die Behandlung unterscheidet sich: Bei 529 sind Backoff und Wiederholung angebracht, bei 429 langsameres Senden oder höhere Limits, bei 503 Abwarten und ein Blick auf die Statusseite. Alle drei in einem einzigen catch-Block zusammenzufassen, ist der häufigste Fehler bei der Fehlerbehandlung.
Warum die Diskussion regelmäßig wieder aufflammt
Immer wenn ein neues Modell erscheint oder eine große Migration stattfindet, wird die Kapazität beim Anbieter für eine Weile knapp, und die Diskussion über 529 nimmt zu. Diese Wellen klingen meist ab, sobald Kapazität hinzukommt – für jemanden mit einer Deadline ist das Warten auf den Ausbau durch den Anbieter aber keine Option.
Reihenfolge der Diagnose
Bestätigen Sie, dass der Statuscode wirklich 529 und nicht 429 ist. Die Response-Bodys unterscheiden sich; zählen Sie beide in Ihren Logs getrennt.
Prüfen Sie die Statusseite des Anbieters. Bei einem breiten Vorfall ist jede Änderung auf Client-Seite bestenfalls eine Linderung.
Prüfen Sie, ob Ihre eigene Retry-Logik die Überlastung verstärkt: fehlender Jitter, fehlende Obergrenze und sofortige Wiederholung verstärken sie alle.
Klären Sie vor dem erneuten Versuch, welchen Code Sie tatsächlich erhalten haben
Was gesichert ist
529 signalisiert eine Kapazitätsüberlastung beim Upstream und hat nichts mit dem Inhalt der Anfrage zu tun – diese Semantik ist in der Dokumentation der Anbieter festgehalten. Exponentielles Backoff mit Jitter ist eine vielfach bewährte clientseitige Reaktion.
Nicht als Tatsache behandeln
Behauptungen wie „529 bedeutet, dass der Anbieter Vielnutzer stillschweigend drosselt“ sind nicht belegt und werden hier nicht aufgestellt. Der Unterschied zwischen 529 und 429 ist öffentlich dokumentiert; wer beide vermischt, greift zur falschen Abhilfe.
Zwei Reaktionen
Nur Backoff auf Client-Seite
Einfach umzusetzen und senkt die Zahl der Fehlschläge messbar. Solange der Upstream jedoch überlastet bleibt, können Sie nur abwarten.
Arbeit auf mehrere Upstreams verteilen
Ein überlasteter Anbieter bedeutet nicht mehr automatisch Ausfall. Der Preis dafür: Sie müssen unterschiedliche Eigenheiten der Modelle in Kauf nehmen, und jede Route hat ihre eigenen Fehlerbilder.
Retries richtig umsetzen
Drei Punkte. Erstens: exponentielles Backoff statt eines festen Intervalls – eine Sekunde warten, dann jedes Mal verdoppeln. Zweitens: zufälligen Jitter hinzufügen – wenn alle Clients gleich lange warten, wiederholen sie synchron in einer Welle, was die Überlastung verlängert. Drittens: Obergrenzen sowohl für die Anzahl der Wiederholungen als auch für die Gesamtwartezeit setzen, sonst wächst Ihre Aufgabenwarteschlange bei einer einzigen Überlastung unbegrenzt. Außerdem gilt: Bricht eine Streaming-Anfrage mittendrin ab, wiederholen Sie nicht blind von vorn, sondern prüfen Sie zuerst, ob sich das bereits Empfangene fortsetzen lässt.
Was QCode hier leisten kann und was nicht
Was möglich ist: Mit einem Key wechseln Sie bei Überlastung zu einer anderen Modellfamilie, statt auf die Erholung eines einzelnen Upstreams zu warten. Was nicht möglich ist: Wir sind nicht der Anbieter und können die Kapazität des Upstreams nicht ändern. Und um es klar zu sagen: Auch bei uns schlagen Anfragen fehl. In den vergangenen 7 Tagen war das von uns beobachtete Fehlerbild überwiegend 502 am Gateway, mit 0 Fällen von 529. Ein Dienst, der sich als fehlerfrei anpreist, veröffentlicht meist einfach seine Fehlerdaten nicht. Wir bieten mehrere Routen und einsehbare Fehlerprotokolle, kein Versprechen makelloser Verfügbarkeit.
FAQ
Sollte ich meine Anfrageparameter ändern, wenn ich einen 529 erhalte?
Nein. 529 hat nichts mit dem Inhalt der Anfrage zu tun; weder das Ändern von max_tokens oder von Modellparametern noch das Kürzen des Prompts lässt den Fehler verschwinden. Ändern Sie stattdessen die Retry-Strategie.
Kann ich für 529 und 429 dieselbe Retry-Logik verwenden?
Nicht empfehlenswert. Bei 529 sollten Sie abwarten und dieselbe Anfrage erneut senden; 429 bedeutet, dass Sie Ihre Senderate senken oder Ihre Limits erhöhen müssen – blinde Wiederholungen lösen das Limit immer wieder aus.
Wie lange sollte ich warten?
Üblich ist ein Start bei einer Sekunde, die sich mit jedem Versuch verdoppelt, mit zufälligem Jitter sowie Obergrenzen für die Zahl der Wiederholungen und die Gesamtwartezeit. Die genauen Werte hängen davon ab, wie viel Latenz Ihre Aufgabe verträgt.
Was ist, wenn eine Streaming-Anfrage mittendrin einen 529 erhält?
Prüfen Sie zuerst, ob das bereits Empfangene brauchbar ist. Wenn ja, setzen Sie fort; nur wenn nicht, wiederholen Sie die gesamte Anfrage. Ein blinder Neustart verursacht doppelte Abrechnung und verschärft die Überlastung.
Bekommt auch QCode 529-Fehler?
Die Überlastung bei den Upstreams ist real, und auch wir sind davor nicht gefeit. In unseren eigenen Beobachtungen der vergangenen 7 Tage waren unsere Fehler überwiegend 502, mit 0 Fällen von 529. Wir können dieselbe Arbeit auf eine andere Modellfamilie verlagern – wir versprechen aber nicht, dass keine Fehler auftreten.
Bedeutet Multi-Route, dass es keinen Single Point of Failure gibt?
Nein. Mehrere Routen senken die Wahrscheinlichkeit, dass ein einzelner Ausfall Ihre Arbeit stoppt, aber jede Route hat ihre eigenen Fehlerbilder, und auch die Routing-Schicht selbst kann ausfallen. Das ist eine Abmilderung, keine Beseitigung.
Quellen
Die Semantik der Statuscodes folgt der offiziellen API-Dokumentation des jeweiligen Anbieters. Diese Seite nennt bewusst keine Verfügbarkeitsquoten von Dritten – solche Zahlen ändern sich im Lauf der Zeit, und wir haben keine verlässliche unabhängige Messung, auf die wir verweisen könnten.
Wenn eine Route überlastet ist, nehmen Sie eine andere
Ein Key für sieben Modellfamilien – wechseln Sie und arbeiten Sie weiter, wenn eine Route unter Druck steht.
Weiterführende Artikel
Claude Code FAQ und Fehlerbehandlung
Was die gängigen Statuscodes bedeuten und wie Sie damit umgehen.
Claude Code Nutzungslimits
Wie Kontingent und Rate Limits angewendet werden.
Multi-Modell-Routing
Ein Key über mehrere Modellfamilien hinweg in der Praxis.
Die Semantik der Statuscodes folgt hier der offiziellen Dokumentation des jeweiligen Anbieters und kann sich zwischen Versionen ändern. Unsere eigenen Beobachtungen zu Fehlern beziehen sich auf einen bestimmten Zeitraum in unseren eigenen Logs und sind keine Verfügbarkeitszusage.