Un rate limit (limite de débit) est un plafond strict fixé par un fournisseur d'API sur le volume de requêtes ou de tokens qu'un seul client (identifié par une clé API ou une organisation) peut consommer dans une fenêtre temporelle glissante — généralement par minute (RPM / TPM) ou par jour. Les appels dépassant ce plafond reçoivent une réponse 429 Too Many Requests et doivent être relancés après un délai.Pour les APIs LLM, les rate limits se déclinent en deux formes qui se cumulent : requests per minute (RPM) et tokens per minute (TPM). Un seul prompt volumineux peut épuiser votre budget TPM même si vous n'avez envoyé qu'une seule requête.
Pourquoi les rate limits sont importants pour les agents de code IA en 2026
Les agents de code sont structurellement hostiles aux rate limits. Ils émettent de nombreux appels petits et rapides — boucles d'utilisation d'outils, lectures de fichiers en parallèle, complétions en ligne — et chaque appel transporte un prompt qui peut déjà représenter des centaines de tokens avant même qu'un seul morceau de code ne soit joint. Sous une charge agent soutenue, les limites TPM sont généralement la contrainte déterminante, pas les RPM.
L'effet cumulatif
Une boucle agent typique ressemble à : lire un fichier → construire un prompt (300–800 tokens de boilerplate + contenu du fichier) → appeler le modèle → analyser le résultat → recommencer. Si le boilerplate est verbeux, chaque itération brûle des tokens inutilement. Atteindre le plafond TPM bloque toute la boucle avec un backoff exponentiel, ajoutant une latence réelle qui se cumule au fil d'une session.La réduction de tokens étend directement votre marge effective face aux rate limits : moins de tokens par appel signifie plus d'appels par minute avant d'atteindre le plafond. Voir réduire l'utilisation de tokens des agents IA pour des techniques concrètes.
Progression par paliers
La plupart des fournisseurs (Anthropic, OpenAI, Google) proposent des rate limits par niveaux qui s'étendent avec les dépenses cumulées. Les nouvelles clés API démarrent à des limites conservatrices — souvent 40k–100k TPM — qui sont rapidement saturées par un agent actif. Rester dans les niveaux inférieurs est gérable si et seulement si chaque appel est léger ; les prompts surdimensionnés poussent les équipes à payer pour des niveaux supérieurs plus tôt que nécessaire.
Multi-agent et utilisation d'outils en parallèle
Lorsqu'un orchestrateur lance des sous-agents en parallèle — courant dans les pipelines RAG qui distribuent plusieurs appels de récupération simultanément — chaque sous-agent puise dans le même bucket TPM. Cinq agents envoyant chacun des prompts de 10k tokens en parallèle représentent un burst de 50k tokens. Sans discipline sur les tokens, les agents parallèles atteignent le plafond dès la première action coordonnée.
Les serveurs Model Context Protocol qui proxifient les appels d'outils vers des APIs LLM introduisent une couche supplémentaire : les requêtes sortantes du serveur MCP comptent dans votre quota. Un outil MCP mal implémenté qui envoie l'intégralité de la transcription des appels d'outils à chaque invocation multiplie vos dépenses en tokens — et votre exposition aux rate limits — à chaque saut.
Diagnostiquer un problème de rate limit
Vérifiez l'en-tête de réponse. Les fournisseurs renvoient x-ratelimit-remaining-tokens (et des en-têtes équivalents) sur chaque réponse. Journalisez-les.
Distinguez 429 de 503. Un 429 est un rate limit ; un 503 est une erreur de capacité côté fournisseur. La logique de retry ressemble pour les deux, mais la cause racine diffère.
Profilez la taille du prompt, pas seulement le nombre de requêtes. Les équipes qui ne surveillent que les RPM passent complètement à côté de l'épuisement TPM. Profilez le nombre de tokens de chaque prompt au niveau de l'agent.
Quand les rate limits ne sont PAS le problème
Usage mono-utilisateur à faible fréquence. Une conversation interactive avec des questions de code occasionnelles approche rarement les plafonds TPM. Les rate limits deviennent une préoccupation à l'échelle des boucles agent, pas à l'échelle conversationnelle.
Workloads batch / asynchrones. La plupart des fournisseurs proposent une API batch avec des limites de débit plus élevées et un coût par token réduit. Si votre cas d'usage tolère des minutes de latence, le chemin batch contourne entièrement les rate limits en temps réel.
Modèles auto-hébergés. Si vous faites tourner Llama, Mistral, ou un modèle open-weight quantisé localement, il n'y a pas de rate limit externe — seulement la mémoire GPU et le débit d'inférence. Les rate limits sont une contrainte des APIs cloud.
Voir aussi
Token — l'unité dans laquelle les rate limits TPM sont mesurés
Context window — les prompts plus larges consomment davantage de TPM par appel