Aller au contenu principal

Pourquoi les agents IA brûlent des tokens (et comment plafonner la facture)

Intermédiaire

Un tour de chat coûte une fraction de centime. La même question confiée à un agent — un agent qui lit des fichiers, appelle des outils et boucle jusqu'à la fin — peut coûter des dollars. Les équipes le découvrent à la dure : un agent de code laissé en marche accumule une facture qu'un humain au clavier n'aurait jamais faite. Le pire n'est pas la moyenne ; c'est que vous ne pouvez pas la prédire à l'avance, et que le coût de la même tâche peut varier énormément.

Cette page explique pourquoi les agents brûlent des tokens (le mécanisme n'est pas celui que la plupart des gens devinent), montre les chiffres qui surprennent même les bâtisseurs expérimentés, et vous donne les quatre leviers qui réduisent vraiment la facture — les mêmes leviers que vous soyez sur Claude Code, Cursor, Codex, ou une boucle maison sur n'importe quel modèle.

What you'll learn
  • Expliquer la boule de neige de contexte — pourquoi le coût d'un agent croît à peu près QUADRATIQUEMENT avec les étapes, pas linéairement
  • Citer les vrais multiplicateurs : les tâches agentiques ~1000× les tokens d'un chat, et la MÊME tâche variant jusqu'à 30×
  • Savoir quand un second agent en vaut la peine — et le benchmark qui montre que ce n'est généralement pas le cas
  • Tirer les quatre leviers de coût qui marchent : plafonds de budget, mise en cache des prompts, routage par niveau de modèle, élagage du contexte
  • Diagnostiquer une facture d'agent qui s'emballe et lui poser un plafond dur

La boule de neige de contexte : pourquoi le coût croît quadratiquement​

Voici le piège. Un chat, c'est un tour — une entrée, une sortie, terminé. Un agent, c'est une boucle : il lit une tâche, prend une action, lit le résultat, prend l'action suivante, et ainsi de suite jusqu'à ce que le travail soit fini. Le hic, c'est qu'à chaque étape, le modèle relit toute la conversation accumulée jusque-là — le prompt d'origine, chaque action antérieure, et chaque résultat d'outil — avant de décider quoi faire ensuite.

L'entrée croît donc à chaque étape, et vous payez pour toute la boule de neige à nouveau chaque fois qu'elle avance :

  • L'étape 1 traite le prompt.
  • L'étape 2 relit le prompt + l'action et le résultat de l'étape 1.
  • L'étape 3 relit tout cela + l'action et le résultat de l'étape 2.
  • …et ainsi de suite.

Additionnez l'entrée sur une exécution et le total croît à peu près comme le carré du nombre d'étapes, pas linéairement. Le Stanford Digital Economy Lab a constaté que les tâches agentiques sont « exceptionnellement coûteuses, consommant 1000× plus de tokens que le raisonnement de code et le chat de code » — et surtout, ce sont les tokens d'entrée qui dominent, pas la sortie. L'agent n'écrit pas plus ; il relit plus.

What you'll learn
  • Le moteur du coût, c'est la relecture, pas la réflexion. Chaque étape de boucle retraite toute la transcription, donc une exécution de 20 étapes paie le contexte initial ~20 fois.
  • C'est pourquoi « laisse l'agent se débrouiller » coûte cher : chaque étape supplémentaire qu'il prend se multiplie contre tout ce qui précède.
  • Les tâches à sortie lourde (écris-moi un essai) sont bon marché par comparaison ; les boucles à entrée lourde (explore ce dépôt, puis corrige le bug) sont là où l'argent part.

Les chiffres qui surprennent les gens​

Trois chiffres réinitialisent l'intuition de la plupart des gens :

  • ~1000×. Les tâches agentiques peuvent consommer environ mille fois les tokens d'un chat ou d'une complétion de code équivalents, selon l'analyse de Stanford — moteur : la boule de neige ci-dessus, pas un modèle plus gros.
  • Jusqu'à 30× de variance sur la même tâche. Le même agent, exécuté sur la même tâche, peut coûter jusqu'à 30× plus une fois qu'une autre — parce que le chemin qu'il prend (combien d'outils il appelle, jusqu'où il s'égare) est non déterministe. Vous ne pouvez sincèrement pas connaître la facture avant la fin. C'est pourquoi la « tarification au résultat » pour les agents est si difficile : vous ne voyez le coût qu'après que tout s'est exécuté.
  • Plus d'agents se rentabilise rarement. Les benchmarks de production 2026 ont constaté qu'une configuration multi-agent n'ajoutait que ~2,1 % de précision à 2× le coût face à un agent unique bien configuré sur 64 % des tâches. Un motif superviseur-hiérarchique a poussé une tâche documentaire de 85 % → 95 % de précision — mais à environ 0,15 $/tâche contre 0,003 $ pour l'agent unique (~50×). Plus d'agents achète un peu de précision pour beaucoup d'argent.
Watch out
  • Parce que la même tâche varie jusqu'à 30×, un budget basé sur la moyenne SERA fait exploser par la queue de distribution. Plafonnez le maximum, ne budgétez pas la moyenne.
  • Ajouter des agents « par sécurité » multiplie généralement le coût bien plus vite que ça n'ajoute de la précision. Ne prenez un second agent que lorsque la tâche se décompose vraiment en sous-tâches parallèles et indépendantes.

Votre surface d'outils fait partie de la facture​

Avant même que la boucle démarre, la façon dont l'agent atteint ses outils fixe un plancher de coût. Connecter un ensemble de serveurs MCP peut injecter des dizaines de milliers de tokens de définitions d'outils dans chaque étape de la boule de neige. Une comparaison brute que beaucoup de bâtisseurs rencontrent : une commande CLI simple fait ~200 tokens en moyenne, tandis que l'opération MCP équivalente peut coûter 32k–82k tokens une fois les schémas d'outils et l'enveloppe comptés. Cet écart s'accroche à chaque étape de boucle.

Cela ne rend pas MCP mauvais — c'est le bon choix pour l'authentification, la multi-location et l'accès gouverné. Cela signifie que la surface d'outils est un levier de coût que vous avez choisi à la conception. AILmanac a un approfondissement dédié : La taxe token de MCP couvre Tool Search, le chargement différé et l'exécution de code comme les trois correctifs.

Les quatre leviers qui réduisent vraiment la facture​

Les conseils d'optimisation sont infinis ; seuls quatre leviers font bouger le chiffre matériellement. Par ordre de levier approximatif :

Guided walkthrough1 of 4
  1. Fixez un plafond token/dollar par exécution ou par utilisateur qui ARRÊTE NET l'agent. Parce que la même tâche peut coûter 30× plus sur une mauvaise exécution, un plafond est la seule chose qui borne la queue. La plupart des harnais d'agent exposent une limite max-tokens ou max-steps — utilisez-la. C'est le contrôle le plus important.

Auditer un agent qui s'emballe (collez la répartition des tokens de votre exécution)

You are a cost engineer. Here is a token-usage breakdown of one agentic run
(input vs output tokens per step, tool calls, model used).

Diagnose where the money went, in priority order:
1. Is input or output driving cost? (Agents are almost always input-heavy.)
2. Which repeated content should be prompt-CACHED (system prompt, tools, rules)?
3. Which steps could run on a CHEAPER model without losing correctness?
4. Where is context snowballing — what can be pruned, compacted, or summarized?
5. What is a safe per-run token CAP that stops the worst tail without hurting the median run?

Give me the estimated % saving per fix and the ONE change to make first.

Quand un agent est le mauvais outil​

L'exécution agentique la moins chère est celle que vous ne faites pas. Si une tâche est une transformation unique et bien spécifiée — résume ceci, classe cela, réécris ceci — un simple appel chat/complétion la fait à une fraction du coût, avec aucune boule de neige du tout. Sortez un agent quand le travail exige vraiment lire, décider, agir et revérifier en boucle contre un environnement changeant (explorer un dépôt, déboguer à travers des fichiers, piloter un navigateur). Si vous pouvez écrire vous-même les étapes exactes, scriptez-les — ne payez pas un modèle pour les redériver à chaque exécution.

Appuyez sur Entrée ou Espace pour retourner la carte. Utilisez les flèches gauche et droite pour naviguer entre les cartes.Terme affiché.
1 / 5

Check yourself

0/3
  1. Pourquoi une exécution agentique coûte-t-elle tellement plus qu'un seul tour de chat pour la même question ?
  2. Un coéquipier veut ajouter un deuxième et un troisième agent « par sécurité » sur une tâche qu'un seul agent gère déjà à 85 % de précision. Que suggèrent les benchmarks 2026 ?
  3. Étant donné que la MÊME tâche peut coûter jusqu'à 30× plus sur une exécution qu'une autre, quelle est la bonne façon de contrôler la dépense ?

Sources et lectures complémentaires​