429 Too Many Requests with no obvious patternRetries make the problem worseOnly some requests fail while others succeed at the same momentRate limiting under a load that used to be fineAnbieter messen mehrere Dimensionen gleichzeitig – Anfragen pro Minute, Tokens pro Minute und manchmal gleichzeitige Anfragen. Das Token-Limit zu erreichen, während man weit unter dem Anfrage-Limit liegt, ist der Grund, warum „nur manche Anfragen“ scheitern.
Token-Limits zählen, was Sie senden, plus was Sie reservieren. Ein paar Anfragen mit großem max_tokens können ein Budget an Tokens pro Minute erschöpfen, während die Anfragezahl unbedeutend aussieht.
Sofortige Wiederholungen werden ebenfalls gezählt. Eine enge Retry-Schleife macht aus einer Sekunde Pause eine anhaltende Sperre – das ist der übliche Grund, warum ein vorübergehendes 429 dauerhaft wird.
Geben Sie bei einem 429 die Header aus statt des Bodys:
curl -s -D- -o /dev/null -X POST 'YOUR_BASE_URL/chat/completions' \
-H 'Authorization: Bearer YOUR_KEY' -H 'Content-Type: application/json' \
-d '{"model":"MODEL","messages":[{"role":"user","content":"hi"}]}' \
| grep -i 'retry-after\|ratelimit\|^HTTP'
Beachten Sie Retry-After, wenn vorhanden. Fehlt er, ist exponentielles Backoff mit Jitter ab etwa einer Sekunde der sichere Standard.
Zuletzt geprüft am 2026-10-01. Geschrieben aus Problemen, die auf einem laufenden OpenAI-kompatiblen Gateway diagnostiziert wurden – nicht von anderen Seiten zusammengetragen.