OpenAI API: 429 und 503 mit der richtigen Retry-Logik behandeln

OpenAI hat die Fehlerbehandlung seiner API präzisiert: Anwendungen können nun unterscheiden, ob der eigene Traffic zu schnell ansteigt oder ob ein Modell vorübergehend überlastet ist. Für Unternehmen ist das mehr als eine technische Detailänderung. Wer beide Situationen gleich behandelt, riskiert unnötige Wiederholungen, längere Warteschlangen und eine schwer erklärbare Nutzererfahrung. Die richtige Reaktion beginnt deshalb nicht mit einem pauschalen Retry, sondern mit einer sauberen Klassifikation des Fehlers.

Was OpenAI bei 429 und 503 unterscheidet

Bestätigt ist: Zu schnell wachsender Traffic kann mit HTTP 429 und dem Fehlercode slow_down beantwortet werden. Eine temporäre Modellüberlastung wird dagegen mit HTTP 503 und server_is_overloaded signalisiert. Beide Antworten können einen Retry-After-Header enthalten. Ist er vorhanden, sollen Anwendungen mindestens die dort angegebene Zeit warten. Fehlt die Angabe, empfiehlt OpenAI exponentielles Backoff.

• 429 slow_down: Der Anstieg der eigenen Anfragen ist zu schnell; die Anwendung sollte ihre Zuflussrate dämpfen.
• 503 server_is_overloaded: Das angefragte Modell ist vorübergehend überlastet; die Anwendung sollte kontrolliert warten.
• Retry-After vorhanden: Frühestens nach der vorgegebenen Wartezeit erneut anfragen.
• Retry-After fehlt: Wiederholungen mit exponentiellem Backoff zeitlich auseinanderziehen.

Warum eine gemeinsame Retry-Regel unnötige Kosten erzeugt

Daraus lässt sich für den Betrieb ableiten: 429 slow_down verlangt zuerst eine Kontrolle des eigenen Lastprofils. Ursachen können etwa gebündelte Jobs, gleichzeitig startende Agenten oder eine fehlende Begrenzung pro Mandant sein. Ein sofortiger, identischer Retry aller Worker würde denselben Anstieg wiederholen. Bei 503 server_is_overloaded liegt die unmittelbare Reaktion stärker auf kontrolliertem Warten und einer begrenzten Wiederholung. In beiden Fällen muss verhindert werden, dass Retries die ursprüngliche Last vervielfachen.

Auch wirtschaftlich sollten die Pfade getrennt werden. Wiederholte Anfragen belegen Worker, verlängern Prozesslaufzeiten und können nachgelagerte Systeme blockieren. Bei synchronen Nutzerprozessen entsteht zudem die Frage, wann eine verständliche Zwischenmeldung besser ist als weiteres Warten. Bei Hintergrundautomationen kann dagegen eine Warteschlange sinnvoll sein. Das ist eine nachvollziehbare betriebliche Ableitung aus den neuen Signalen, keine von OpenAI zugesicherte Wirkung.

Entscheidungsrahmen für eine belastbare Retry-Logik

1. Antwort klassifizieren: HTTP-Status und Fehlercode als strukturierte Felder erfassen, statt nur Freitext zu protokollieren.
2. Wartezeit bestimmen: Retry-After vorrangig verwenden und die dort genannte Mindestdauer respektieren.
3. Fallback definieren: Fehlt Retry-After, exponentielles Backoff mit einer klaren Obergrenze für Versuche und Gesamtdauer einsetzen.
4. Gleichzeitigkeit dämpfen: Wiederholungen verteilen, damit viele Worker nicht zur selben Zeit erneut anfragen.
5. Prozessart berücksichtigen: Für interaktive Anfragen, Batch-Jobs und Agentenläufe getrennte Zeitbudgets und Abbruchregeln festlegen.
6. Idempotenz absichern: Schreibende Folgeaktionen so gestalten, dass ein Retry keine doppelten Datensätze, Nachrichten oder Buchungen erzeugt.
7. Eskalation festlegen: Nach ausgeschöpftem Budget in eine Warteschlange, einen manuellen Prüfpfad oder einen definierten Fehlerzustand wechseln.

Die Trennung der Pfade bedeutet nicht, dass jede Anwendung zwei vollständig unabhängige Systeme braucht. Sinnvoll ist eine gemeinsame Retry-Komponente mit unterschiedlichen Regeln je Fehlerklasse. Sie sollte zentral konfigurierbar sein, aber pro Prozess ein eigenes Zeit- und Versuchsbudget zulassen. So bleibt die Technik wartbar, während geschäftskritische Abläufe andere Grenzen erhalten können als interne Komfortfunktionen.

Rolloutplan ohne Eingriff in alle Workflows zugleich

Für die Einführung empfiehlt sich ein begrenzter Rollout. Zuerst werden bestehende Logs darauf geprüft, ob 429 und 503 bisher getrennt erfasst werden. Danach lässt sich die neue Klassifikation in einer zentralen Client-Schicht ergänzen. Anschließend sollte ein einzelner, gut beobachtbarer Prozess umgestellt werden. Erst wenn Wartezeiten, Abbruchverhalten und Folgeaktionen nachvollziehbar funktionieren, wird die Regel auf weitere Integrationen übertragen.

1. Inventar der OpenAI-Clients, SDK-Wrapper, Agenten und Automationen erstellen.
2. Parser und Telemetrie für status, error code und Retry-After ergänzen.
3. Retry-Budgets nach interaktivem Prozess, Batch und Agentenlauf festlegen.
4. 429 und 503 in Tests gezielt simulieren, einschließlich fehlendem Retry-After.
5. Idempotenz und Abbruchpfade bei schreibenden Geschäftsprozessen prüfen.
6. Pilot beobachten, Grenzwerte dokumentieren und danach schrittweise ausrollen.

Was im Monitoring sichtbar sein sollte

Mindestens getrennte Zähler für 429 slow_down und 503 server_is_overloaded sind sinnvoll. Hinzu kommen die tatsächlich eingehaltene Wartezeit, die Zahl der Versuche, die gesamte Prozessdauer und der endgültige Ausgang. Für 429 sollte erkennbar sein, welcher Mandant, Jobtyp oder Zeitplan den Anstieg ausgelöst hat. Bei 503 ist relevant, welche Modelle und Prozesse betroffen waren. Alarmiert werden sollte nicht jeder einzelne Retry, sondern ein geschäftlich relevanter Zustand: ausgeschöpfte Retry-Budgets, wachsende Warteschlangen oder dauerhaft ausbleibende Abschlüsse.

Die Änderung liefert Unternehmen ein präziseres Signal, nimmt ihnen aber die Betriebsentscheidung nicht ab. Wer 429 als Hinweis auf das eigene Lastverhalten und 503 als temporäre Modellüberlastung behandelt, kann Retries gezielter steuern. Entscheidend bleiben klare Zeitbudgets, Idempotenz, beobachtbare Warteschlangen und ein definierter Ausstieg. So wird aus einem neuen Fehlercode eine belastbarere KI-Integration statt nur eine weitere Fallunterscheidung im Quellcode.