Accueil → Aide

Bien lire un 429 : retry-after et les en-têtes de limite

Un 429 contient normalement un en-tête Retry-After, en secondes, et souvent un ensemble d'en-têtes indiquant quelle limite est épuisée et quand elle se réinitialise. Attendre ce délai la lève ; relancer immédiatement la prolonge.

Ce que vous voyez

Pourquoi cela arrive

Les 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.

Vérifiez si c'est bien la cause

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.

Comment le corriger

  1. Respectez Retry-After avant votre propre backoffSi l'en-tête indique 12 secondes, attendre 12 secondes fonctionne. Votre backoff d'une seconde, non, et il vous coûte en plus la tentative suivante.
  2. Ajoutez du jitterSans décalage aléatoire, tous les clients de votre parc relancent en même temps et recréent le pic dont vous essayez de vous éloigner.
  3. Vérifiez s'il ne s'agit pas en fait d'un problème de soldeCertaines passerelles renvoient 429 pour un compte vide. Celui-là ne se lève jamais en relançant : lisez le corps de l'erreur avant de supposer une limitation de débit.
Sur APICLAN, un 429 dû à un solde vide et un 429 dû à une congestion de l'amont disent des choses différentes dans le corps. Le premier nécessite une recharge et ne réussira jamais en relançant ; le second se lève généralement en quelques secondes.

Voir aussi

Unexpected token '<' lors d'un appel à une API compatible OpenAI401 invalid API key : quand la clé semble correcte mais échoue quand même

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.