Vous déployez une fonction qui appelle l'API GPT. Elle fonctionne parfaitement en environnement de staging. Les cent premiers utilisateurs l'utilisent en production, et vos logs se remplissent de 429 Too Many Requests. Vous vous demandez alors : s'agit-il de requêtes par minute, de jetons par minute, ou de plafonds journaliers ? Êtes-vous toujours au niveau 1 ? Le modèle vers lequel vous êtes passé la semaine dernière avait-il des limites plus strictes que l'ancien ?
Si vous avez déjà travaillé avec OpenAI, vous savez que l'histoire des limites de débit est devenue plus compliquée avec chaque nouveau modèle. GPT-5.5 a des plafonds différents de GPT-4.1, les modèles d'images sont comptabilisés différemment des modèles de texte, et votre niveau d'utilisation évolue silencieusement à mesure que vos dépenses augmentent. Apidog vous offre un espace de travail unique pour inspecter les en-têtes de réponse de chaque requête, simuler le trafic concurrent et confirmer précisément la limite que vous atteignez avant de déployer du code. Téléchargez Apidog si vous ne l'avez pas encore ; le flux de travail ci-dessous fonctionne avec le plan gratuit.
Les quatre limites qui comptent vraiment
OpenAI applique plusieurs limites de débit à chaque clé API GPT. Vous verrez les quatre appliquées pour toute application de production :
- RPM (requêtes par minute) : le nombre d'appels API que vous pouvez envoyer par minute. Le plafond le plus bas sur la plupart des niveaux.
- TPM (jetons par minute) : le total des jetons d'entrée et de sortie que vous pouvez traiter par minute. Le plafond que la plupart des gens oublient.
- RPD (requêtes par jour) : un plafond journalier sur les clés gratuites et de niveau 1. Disparaît aux niveaux supérieurs pour la plupart des modèles de texte.
- Limites IPM / TPD / de file d'attente par lots : plafonds spécifiques au modèle pour la génération d'images, l'audio, les embeddings et les points de terminaison par lots. Chaque famille de points de terminaison a son propre plafond.
Lorsque votre requête est refusée, l'API renvoie un code HTTP 429 et un corps JSON comme celui-ci :
{
"error": {
"message": "Rate limit reached for gpt-5.5 in organization org-abc on tokens per min (TPM): Limit 30000, Used 28432, Requested 3120.",
"type": "tokens",
"param": null,
"code": "rate_limit_exceeded"
}
}
Notez que le corps vous indique la dimension que vous avez dépassée : tokens, requests, ou parfois tokens_usage_based. C'est la première chose que vous lisez lorsque quelque chose ne fonctionne pas. L'erreur d'un dépassement de TPM est différente de celle d'un dépassement de RPM, et la solution est également différente. Un 429 n'est pas un 429 n'est pas un 429.
Pour une référence complète sur ce que signifie le 429 au niveau HTTP, consultez la documentation MDN sur le 429 et la spécification RFC 6585. Pour le comportement spécifique à OpenAI concernant les en-têtes de relance et l'évolution des niveaux, OpenAI maintient une page officielle sur les limites de débit que vous devriez mettre en favori.
Comment fonctionnent les niveaux, et pourquoi vous continuez d'être promu (ou bloqué)
Votre clé API GPT se situe dans un niveau d'utilisation OpenAI. Les niveaux déterminent les chiffres réels derrière vos plafonds de RPM et TPM. Vous progressez dans les niveaux en fonction de deux éléments : les dépenses totales sur votre compte et la date de votre premier paiement. Il existe six niveaux, du gratuit au niveau 5, et la structure générale ressemble à ceci pour les modèles de texte :
| Niveau | Seuil de dépense | Délai d'attente | RPM Texte | TPM Texte |
|---|---|---|---|---|
| Free | aucun | aucun | 3 | 40k |
| 1 | 5 $ payés | aucun | 500 | 30k–200k selon le modèle |
| 2 | 50 $ payés | 7 jours | 5,000 | 450k |
| 3 | 100 $ payés | 7 jours | 5,000 | 1M |
| 4 | 250 $ payés | 14 jours | 10,000 | 2M |
| 5 | 1 000 $ payés | 30 jours | 10,000 | 2M+ |
Les chiffres ci-dessus sont illustratifs ; les plafonds exacts varient avec le temps et selon les modèles. Lisez vos limites en direct directement depuis le tableau de bord ou, mieux encore, depuis les en-têtes de réponse de votre propre API (couvert ci-dessous) avant de dimensionner une charge de travail.
Deux implications pratiques :
- Vous êtes automatiquement promu lorsque vous payez. Les niveaux ne sont pas optionnels. Dès que vos dépenses dépassent un seuil de niveau et que le délai d'attente est passé, la prochaine requête que vous faites est soumise aux nouveaux plafonds. Aucune notification, aucune étape de migration.
- Vous pouvez être déclassé. Si votre compte devient inactif pendant une longue période ou si votre méthode de paiement échoue, vous pouvez rétrograder. Testez en production après tout changement de facturation.
Pour une comparaison côte à côte avec les systèmes de niveaux d'autres fournisseurs de modèles, consultez notre explication des limites de débit utilisateur de l'API OpenAI, le guide des limites de débit de l'API Claude, et le guide des limites de débit de l'API Grok-3. Le modèle mental est le même chez tous les fournisseurs ; les chiffres et les dimensions spécifiques ne le sont pas.
Lisez vos limites en direct depuis les en-têtes de réponse
Vous n'avez pas besoin de fouiller dans les tableaux de bord pour trouver vos limites actuelles. Chaque réponse de l'API GPT les contient dans les en-têtes. Recherchez ces quatre éléments :
x-ratelimit-limit-requests: votre plafond de RPM pour ce point de terminaison.x-ratelimit-remaining-requests: combien il vous en reste cette minute.x-ratelimit-limit-tokens: votre plafond de TPM.x-ratelimit-remaining-tokens: combien de jetons il vous reste cette minute.
Il y a généralement aussi x-ratelimit-reset-requests et x-ratelimit-reset-tokens, qui vous donnent tous deux une durée lisible par un humain avant que le "seau" ne se remplisse (par exemple 6s, 1m30s).
La manière la plus propre de les lire est d'envoyer une seule requête de complétion de chat, de regarder les en-têtes revenir et de confirmer que vous êtes au niveau que vous pensez être. Apidog simplifie cela en un seul clic.
Étape 1 : configurer la requête GPT dans Apidog
Ouvrez Apidog, créez un nouveau projet et ajoutez-y une nouvelle requête.
Méthode : POST URL : https://api.openai.com/v1/chat/completions
Dans l'onglet En-têtes :
| Clé | Valeur |
|---|---|
Authorization |
Bearer {{OPENAI_API_KEY}} |
Content-Type |
application/json |
La syntaxe à double accolade utilise une variable d'environnement Apidog, ce qui signifie que votre clé ne se trouve jamais à l'intérieur de la requête elle-même. Définissez la variable une fois sous Environnements, changez d'environnement pour basculer entre les clés personnelles et d'équipe, et le reste de la collection se met à jour automatiquement. La même astuce fonctionne pour les identifiants d'organisation et de projet qu'OpenAI vous permet d'inclure pour l'attribution de la facturation.
Dans l'onglet Corps, choisissez JSON et collez :
{
"model": "gpt-5.5",
"messages": [
{"role": "user", "content": "ping"}
],
"max_tokens": 10
}
Cliquez sur Envoyer. Vous devriez obtenir une complétion normale. Cliquez maintenant sur l'onglet En-têtes dans le panneau de réponse et faites défiler jusqu'aux lignes x-ratelimit-*. Ces quatre chiffres représentent votre vérité actuelle. Faites une capture d'écran. C'est la base sur laquelle vous effectuerez vos tests.
Si vous souhaitez approfondir la configuration des requêtes de complétion de chat, notre guide sur la façon de tester l'API ChatGPT avec Apidog couvre l'authentification, le streaming et les appels d'outils de bout en bout.
Étape 2 : confirmer les limites avec un pic délibéré
La lecture des en-têtes vous indique le plafond. L'envoi d'une seule requête ne prouve rien sur le comportement au niveau du plafond. Pour vérifier que le bridage s'active bien là où les en-têtes l'indiquent, vous voulez un petit test de pic.
Apidog est livré avec un exécuteur de tests qui peut envoyer la même requête N fois simultanément. Ouvrez votre requête enregistrée, cliquez sur le menu déroulant à côté de Envoyer et choisissez Exécuter dans le scénario de test. Définissez :
- Itérations : 50 (ou toute valeur confortablement supérieure à votre RPM déclaré)
- Concurrence : 10
- Délai entre les itérations : 0 ms
Exécutez-le. Deux résultats sont utiles :
- Certaines requêtes renvoient 429 avant la fin du pic. Bien. Cela confirme que le plafond de l'en-tête de réponse et l'état de votre compte sont synchronisés.
- Les 50 requêtes réussissent et les en-têtes montrent que
remaining-requestsdécrémente comme prévu. Votre RPM est plus élevé que vous ne le pensiez ; vérifiez le panneau de réponse pour la valeur exacte.
L'exécuteur de tests d'Apidog enregistre chaque réponse, vous pouvez donc trier par code d'état et regrouper tous les 429 dans une seule vue. Cliquez sur une ligne 429 et lisez son corps. Le champ message vous indique si vous avez dépassé le RPM, le TPM ou un plafond quotidien. C'est la dimension que vous dimensionnez dans votre code de production.
Pour une introduction à ce qu'il faut faire une fois que vous avez atteint la limite, le guide "limite de débit dépassée" passe en revue toutes les surfaces 429 que vous êtes susceptible de voir.
Étape 3 : séparer les dépassements de RPM des dépassements de TPM
Le premier pic ci-dessus mesure le RPM, car chaque requête est minuscule. Pour sonder le TPM, vous devez envoyer moins de requêtes mais chacune plus grande. Modifiez le corps de votre requête pour que messages contienne une charge utile beaucoup plus importante :
{
"model": "gpt-5.5",
"messages": [
{"role": "system", "content": "<3,000 tokens of context here>"},
{"role": "user", "content": "Summarise the above in one sentence."}
],
"max_tokens": 200
}
Exécutez un autre scénario, cette fois avec peut-être 20 itérations à 5 concurrences. Si vous êtes au niveau 1 avec un plafond de TPM de 30k, vous atteindrez les limites de jetons bien avant d'atteindre les limites de requêtes.
Cette séparation est importante car la solution est différente. Si votre charge de travail réelle envoie de nombreuses petites requêtes, corrigez le RPM : mettez en file d'attente, regroupez par lots ou échelonnez. Si elle envoie moins de grosses requêtes, corrigez le TPM : réduisez les invites système, mettez en cache les contextes avec le mécanisme prompt_cache, ou divisez la requête.
Étape 4 : simuler des utilisateurs concurrents
Les tests de pic mesurent votre propre plafond. Le trafic de production est différent : de nombreux utilisateurs, des tailles de requêtes variées, des pics au-dessus d'une ligne de base stable.
Dans Apidog, créez un scénario de test qui boucle à travers trois ou quatre variations de la requête (petite, moyenne, grande) avec des pauses aléatoires entre les itérations. L'exécuteur prend en charge les scripts JavaScript de pré- et post-requête, vous pouvez donc :
- Choisir une longueur de message aléatoire par itération.
- Lire
x-ratelimit-remaining-tokensaprès chaque réponse et interrompre le scénario lorsqu'il descend en dessous d'un seuil. - Enregistrer la latence séparément pour les 200 par rapport aux 429 afin de voir comment le bridage affecte le p95.
Lorsque le scénario est terminé, le rapport vous donne un histogramme des codes d'état. Cet histogramme est l'artefact le plus utile que vous puissiez épingler dans un manuel d'exploitation. Au moment où un collègue dit « sommes-nous limités en débit ? », vous le réexécutez et comparez.
Que faire en cas de bridage
Une fois que vous avez mesuré où se trouve le mur, vous avez trois options honnêtes.
Recommencez plus tard. Enveloppez chaque appel GPT dans une nouvelle tentative avec un backoff exponentiel. Lisez l'en-tête x-ratelimit-reset-tokens de la réponse 429 et utilisez-le comme premier délai de nouvelle tentative ; cet en-tête est la réponse littérale d'OpenAI à « attendez ce temps ». Un simple time.sleep(2 ** attempt) fonctionne aussi, mais cela gaspille des secondes que vous n'auriez pas eu à attendre.
File d'attente. Si votre trafic est en rafale, placez les requêtes dans une file d'attente et videz-la à un rythme légèrement inférieur à votre plafond. Un limiteur de type « token-bucket » (seau à jetons) ajusté légèrement en dessous de votre TPM est le modèle standard. Nous examinons les compromis d'implémentation dans comment implémenter la limitation de débit d'API et implémenter la limitation de débit dans les API.
Traitement par lots. L'API de traitement par lots d'OpenAI fonctionne avec des plafonds plus élevés et à moitié prix par rapport aux appels synchrones. Si votre charge de travail tolère un délai d'exécution de 24 heures (enrichissement nocturne, classification de documents, reconstruction d'embeddings), déplacez-la vers le traitement par lots et libérez votre quota synchrone pour le trafic orienté utilisateur.
Si vous souhaitez une lecture plus approfondie sur la distinction entre le bridage et la limitation de débit avant de choisir, bridage vs. limitation de débit est le chemin le plus court à travers la terminologie.
Erreurs 429 GPT courantes et leur signification
Trois types de 429 couvrent environ 90 % des cas réels.
Limite de débit atteinte... sur les requêtes par minute (RPM) signifie que votre code envoie trop d'appels par minute, quelle que soit leur taille. Ajoutez un contrôle de concurrence. Ne déclenchez pas chaque enregistrement dans un map parallèle ; plafonnez votre pool de workers à votre RPM divisé par un facteur de sécurité de deux.
Limite de débit atteinte... sur les jetons par minute (TPM) signifie que vos appels sont trop volumineux. Auditez l'invite. La plupart des dépassements de TPM proviennent d'invites système qui ont grossi avec le temps ou de pipelines RAG qui intègrent des documents entiers dans le contexte. Réduisez, mettez en cache ou divisez.
Vous avez dépassé votre quota actuel, veuillez vérifier votre plan et les détails de facturation ressemble à un 429 mais il s'agit en fait d'un mur de facturation, pas d'une limite de débit. Votre compte a atteint un plafond de dépenses mensuel fixe, la carte enregistrée a échoué, ou le solde prépayé est tombé à zéro. La solution se trouve dans le tableau de bord de facturation, pas dans votre code.
FAQ
Le test des limites de débit GPT avec Apidog est-il payant ? Non. Le plan gratuit couvre les tests de requêtes uniques et les petites exécutions de tests concurrents. Vous n'avez besoin d'un plan payant que si vous souhaitez des charges de test plus importantes, des espaces de travail d'équipe ou des exécutions planifiées. Voir les tarifs Apidog pour plus de détails.
Puis-je tester les limites de débit sans dépenser de jetons réels ? Partiellement. La vérification de base la moins chère est une requête unique avec max_tokens: 1 et un message d'un seul caractère ; elle coûte des fractions de centime et les en-têtes reviennent complets. Pour les tests de pic, vous dépensez des jetons réels, mais vous pouvez garder chaque appel minuscule. Si vous voulez une répétition entièrement hors ligne, utilisez le serveur de maquette d'Apidog pour simuler la forme de réponse 429 et prouver que votre logique de nouvelle tentative fonctionne sans appeler OpenAI du tout.
Pourquoi ma clé de niveau 1 semble-t-elle plus lente que celle d'un collègue de niveau 1 ? Les plafonds de niveau sont par organisation, pas par clé. Si votre clé se trouve dans une organisation partagée avec d'autres utilisateurs intensifs, vous êtes en concurrence avec leur trafic. Apidog peut le montrer clairement : exécutez la même requête à partir des deux clés côte à côte et comparez la diminution de x-ratelimit-remaining-tokens.
Comment savoir quel modèle a quelle limite ? Lisez les en-têtes de réponse. Ne faites pas confiance aux tableaux génériques des articles de blog (y compris celui-ci). Envoyez une requête peu coûteuse à chaque modèle depuis Apidog et enregistrez les en-têtes. Les modèles ayant le même nom mais des versions d'instantanés différentes (par exemple gpt-5.5 vs gpt-5.5-0901) peuvent avoir des plafonds différents.
Les requêtes de streaming sont-elles comptabilisées différemment ? Oui pour le TPM. Une requête de streaming réserve des jetons à l'avance en fonction de max_tokens, de sorte qu'une longue valeur de max_tokens peut consommer votre budget TPM même si la complétion réelle était courte. Réduisez max_tokens au plafond réaliste le plus strict. Nous couvrons le comportement du streaming dans comment tester l'API ChatGPT avec Apidog.
Puis-je partager mon test de limite de débit Apidog avec mon équipe ? Oui. Enregistrez la requête et le scénario de test dans un projet partagé. N'importe quel membre de votre espace de travail peut exécuter le même pic sur sa propre clé en changeant d'environnement. Cela fait de la question « ma clé est-elle bridée ou la leur ? » une question de 10 secondes.