OpenAI API: 429-Fehler richtig behandeln statt blind zu wiederholen
Rate-Limit-Fehler mit Statuscode 429 bei der OpenAI API können ganz unterschiedliche Ursachen haben. Wer sie alle gleich behandelt, riskiert, aus kleinen Störungen große Ausfälle zu machen.
Veröffentlicht am 9. Oktober • Zuerst erschienen auf djangix.com
Zuerst veröffentlicht im Djangix-Blog: OpenAI API Rate Limit Errors (429): Which Ones to Retry and Which Ones to Stop
Ein 429 von der OpenAI API ist nicht nur ein Problem. Es sind mindestens zwei sehr unterschiedliche Probleme, die denselben Statuscode tragen, und wenn man sie gleich behandelt, verwandeln sich kleine Vorfälle in lange Ausfälle. Der erste Schritt besteht darin, den Fehlercode und die Response-Header zu lesen, nicht nur den Status.
Manche 429er sind temporäre Drucksignale: Man hat kurzfristig ein Limit für Requests pro Minute oder Tokens pro Minute überschritten, und die richtige Reaktion ist, das Tempo zu drosseln und es erneut zu versuchen. Andere, etwa ein Quota- oder Billing-Limit, lassen sich durch Wiederholen nicht beheben. In diesem Zustand verschwendet wiederholtes Nachfragen an die API nur Zeit und verzögert die Erholung zusätzlich. Solche Aufrufe sollten gestoppt werden, einen Alert auslösen und darauf warten, dass das zugrunde liegende Limit- oder Zahlungsproblem behoben wird.
Bei den wiederholbaren Fällen sollte man zunächst auf die integrierten Retries des SDK setzen und, falls mehr Kontrolle nötig ist, exponentielles Backoff mit Jitter und einem sinnvollen Cap ergänzen, damit nicht viele Worker alle im selben Augenblick erneut versuchen. Bei hohen oder schwankenden Workloads ist eine Queue, die die Request-Rate glättet, sicherer als sofortige Retries bei jedem einzelnen Request.
Vorbeugung hilft langfristig am meisten: Wiederholte Prompts cachen und deduplizieren, Arbeiten bündeln, wo immer möglich, ein realistisches max_tokens setzen statt es offen zu lassen, überdimensionierten Context kürzen und einfache Aufgaben an ein kleineres, günstigeres Modell weiterleiten, damit das Hauptmodell seine Kapazitätsreserven behält.
Vollständiger Artikel: OpenAI API Rate Limit Errors (429): Which Ones to Retry and Which Ones to Stop
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
Posted on Oct 9 • Originally published at djangix.com
Originally published on the Djangix blog: OpenAI API Rate Limit Errors (429): Which Ones to Retry and Which Ones to Stop
A 429 from the OpenAI API is not one problem — it is at least two very different ones wearing the same status code, and treating them the same is how small incidents turn into long outages. The first step is to read the error code and the response headers, not just the status.
Some 429s are temporary pressure signals: you have briefly exceeded a requests-per-minute or tokens-per-minute limit, and the right response is to slow down and try again. Others, such as a quota or billing limit, will not clear by retrying — hammering the API in that state only wastes time and makes recovery slower. Those calls should stop, surface an alert, and wait for the underlying limit or payment issue to be fixed.
For the retryable cases, lean on the SDK's built-in retries first, then, if you need more control, add exponential backoff with jitter and a sensible cap, so many workers do not all retry at the same instant. For heavy or bursty workloads, a queue that smooths out request rate is safer than immediate retries from every request.
Prevention helps most in the long run: cache and deduplicate repeated prompts, batch work where you can, set a realistic max_tokens instead of leaving it open-ended, trim oversized context, and route simple jobs to a smaller, cheaper model so your main model keeps its headroom.
Full article: OpenAI API Rate Limit Errors (429): Which Ones to Retry and Which Ones to Stop