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 fineLes fournisseurs mesurent plusieurs dimensions à la fois : requêtes par minute, tokens par minute, et parfois requêtes simultanées. Atteindre la limite de tokens tout en restant bien sous la limite de requêtes explique pourquoi « seules certaines requêtes » échouent.
Les limites de tokens comptent ce que vous envoyez plus ce que vous réservez. Quelques requêtes avec un gros max_tokens peuvent épuiser un budget de tokens par minute alors que le nombre de requêtes semble dérisoire.
Les relances immédiates comptent aussi. Une boucle de relance serrée transforme une pause d'une seconde en blocage prolongé, ce qui explique généralement qu'un 429 passager devienne permanent.
Quand vous recevez un 429, affichez les en-têtes plutôt que le corps :
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'
Respectez Retry-After quand il est présent. En son absence, un backoff exponentiel avec jitter commençant vers une seconde est le choix par défaut sûr.
Dernière vérification le 2026-10-01. Rédigé à partir de problèmes diagnostiqués sur une passerelle compatible OpenAI en production, pas compilé à partir d'autres sites.