Ce que révèle la consommation de tokens des agents IA

Un nouvel article de chercheurs de Stanford, du Michigan, de DeepMind, d’All Hands, de Microsoft AI et du MIT est l’étude empirique ouverte la plus détaillée que j’aie vue sur la façon dont les agents IA dépensent vraiment leurs tokens à grande échelle¹. Les auteurs font tourner huit modèles de pointe sur 500 tâches de SWE-bench Verified, à quatre exécutions chacune, et capturent la télémétrie complète des trajectoires, décomposée par type de token, par phase et par action. Ils publient le jeu de données avec l’article, ce qui est, à ma connaissance, le corpus public le plus fin de trajectoires d’agents aujourd’hui.

L’article est rigoureux, prudent sur ce qu’il avance, et met des chiffres solides sur des questions qui n’avaient jusqu’ici reçu que des anecdotes en réponse. Je te recommande de le lire en entier.

Ce qui suit passe en revue quatre de ses observations, entrecoupées de ce qu’on voit chez Flowstate, où les mêmes schémas ressortent dans les environnements de nos clients. On se place sur le chemin des requêtes, entre l’utilisateur et le fournisseur d’IA. On observe donc les mêmes trajectoires que l’article, mais en production, sur un éventail d’outils d’IA bien plus large que celui de SWE-bench.

Les deux séries d’observations se ressemblent à un point remarquable. Les chercheurs l’ont mesuré sur un benchmark, nous le voyons sur les appareils de nos clients. Cet accord est ce qui rend l’article si utile pour quiconque essaie de piloter cette dépense.

Les tokens d’entrée dominent la dépense des agents

La première conclusion de l’article, c’est que le code agentique consomme environ 1 000 fois plus de tokens que des tâches équivalentes de chat de code ou de raisonnement sur du code, avec un rapport entrée/sortie d’environ 153:1 (contre 1,33 pour le chat et 0,16 pour le raisonnement)².

La raison est structurelle. Les workflows agentiques accumulent du contexte d’un tour à l’autre, et le même contenu est renvoyé au modèle à chaque tour. Le cache de tokens aide à la marge, mais le volume de contexte accumulé écrase tout dans le coût.

On voit exactement le même schéma dans les usages non agentiques. L’usage de Claude, de ChatGPT et des outils du même genre en mode chat suit la même forme, parce que les utilisateurs poursuivent leurs conversations pendant des jours au lieu de repartir d’une session neuve avec un contexte explicite. Un client nous l’a décrit comme ça :

« On pense qu’ils créent des PowerPoint, et puis ils disent : “change ce mot sur la diapo trois”, et ils continuent à générer ces énormes documents. »

C’est la conclusion de l’article, version humaine. Une session de chat qui aurait dû être un prompt neuf devient un fil qui repaie tout son historique à chaque tour. L’utilisateur croit faire une petite retouche. On demande au modèle de retraiter le document entier. Le fournisseur facture en conséquence.

Ça veut dire qu’une part énorme du coût de l’IA qu’on peut maîtriser se joue en amont du modèle. De meilleurs prompts. Des sessions neuves. Un contexte explicite fourni une fois, plutôt que construit par touches au fil d’un après-midi. Le comportement de l’agent est en grande partie la conséquence de la façon dont on l’a installé.

Le choix du modèle crée des écarts de coût d’un ordre de grandeur

Sur les 230 tâches de SWE-bench que tous les modèles testés ont résolues, Kimi-K2 et Claude Sonnet 4.5 ont utilisé en moyenne 1,5 million de tokens de plus que GPT-5³. Mêmes problèmes, mêmes bonnes réponses, appétits en tokens très différents.

L’article prend soin d’écarter l’explication évidente : l’écart de coût persiste à la fois sur le sous-ensemble des réussites communes et sur celui des échecs communs. Les modèles les plus chers ne s’attaquaient pas à des problèmes plus difficiles. Ils dépensaient simplement plus de tokens sur les mêmes problèmes.

Ça colle avec un comportement qu’on observe sans cesse. Les utilisateurs prennent par défaut le modèle le plus en vue dans l’interface, et « le plus en vue » veut en général dire le plus cher. Opus quand Sonnet aurait fait l’affaire. Les fournisseurs n’ont aucun intérêt commercial à orienter les utilisateurs vers des modèles moins chers. D’une autre conversation avec un client :

« On sait très bien que les gens utilisent uniquement Opus. Ceux qui épuisent leurs tokens vont continuer, à moins qu’il y ait un moyen de les contrôler. On ne savait pas qu’il y avait un moyen de contrôler ça dans Claude. Je sais qu’il n’y en a pas. »

Il y a un moyen de le contrôler, mais il ne vit pas dans le produit du fournisseur. Sa place naturelle, c’est la couche qui voit la catégorie de la tâche et route au niveau de la requête : le code répétitif vers le modèle le plus léger, la planification de longue haleine vers le plus lourd. La conclusion de Stanford, selon laquelle la sobriété en tokens est une propriété du modèle et non de la tâche, est précisément ce qui rend le routage viable. Si les modèles lourds ne brûlaient plus de tokens que sur les problèmes plus durs, le routage ne servirait à rien. Ce n’est pas le cas, donc il sert.

La consommation de tokens varie beaucoup et se prédit mal

La troisième observation de l’article, c’est que quatre exécutions du même modèle sur la même tâche peuvent produire jusqu’à 30x d’écart sur le coût total en tokens⁴. L’exécution la plus chère sur un problème donné coûte en moyenne environ deux fois la moins chère. Plus le coût monte, moins on peut le prévoir.

Plus frappant encore : les auteurs testent si les agents savent prédire leur propre consommation de tokens avant d’exécuter une tâche. Ils trouvent des corrélations de 0,39 au mieux. Les huit modèles sous-estiment systématiquement⁵. Même l’agent ne sait pas ce que coûtera une tâche.

Côté clients, ce qu’on voit, ce sont des dirigeants qui essaient de piloter la dépense avec la seule donnée dont ils disposent. En général, un nombre de chats tiré du tableau de bord admin du fournisseur :

« Que font ces cinq personnes ? Elles répètent toujours qu’elles n’ont pas assez de tokens. »

Un nombre de chats ne répond pas à ça. Un nombre de tokens dit combien on a dépensé, pas pourquoi. Le « pourquoi » est structurellement invisible sur la facture. On ne le voit qu’au niveau de la requête, là où le travail réel est observable. Aucune prévision en amont ne comblera l’écart, parce que le travail lui-même est stochastique.

Dépenser plus ne donne pas plus de précision

L’article répartit les exécutions en quartiles de coût et constate que la précision culmine au deuxième quartile le moins cher, puis plafonne. Les exécutions les plus chères n’obtiennent pas de meilleurs résultats que celles aux prix modestes⁶.

Les auteurs relient ça à un comportement précis : dans le quartile de coût le plus élevé, les modifications répétées de fichiers sont environ 4x plus fréquentes que dans le quartile le moins cher, et les consultations répétées de fichiers 2x plus fréquentes⁷. Les exécutions chères ne font pas plus de travail. Elles refont le même travail, sur les mêmes fichiers.

L’article décrit poliment ça comme « une exploration improductive plutôt qu’un raisonnement plus profond ». On retrouve la même forme dans les usages de l’IA hors code. Régénération répétée du même livrable avec des changements marginaux. Sessions interminables que l’utilisateur a désertées depuis des heures. Prompts identiques relancés après la correction d’une faute de frappe. Aucun de ces cas n’est une défaillance de l’agent, ce sont des habitudes de l’utilisateur que l’agent hérite.

L’écart de mesure

Aucun des schémas ci-dessus ne peut être traité à grande échelle sans mesure au niveau de la requête. Les tableaux de bord des fournisseurs agrègent par outil et par tenant. Les passerelles d’IA (un proxy placé entre toi et ton fournisseur d’IA) couvrent le routage de production côté serveur. Les outils d’efficacité d’ingénierie couvrent quelques assistants de code, et s’arrêtent là.

On a construit Flowstate parce que la couche de mesure nécessaire pour agir sur ces schémas n’existait nulle part dans la pile.

Flowstate observe chaque appel d’IA qu’un utilisateur passe, que ce soit ChatGPT dans le navigateur, Claude Code dans le terminal, Midjourney pour les images ou Suno pour l’audio, et relie chaque appel à un utilisateur, un projet, un modèle et une classe de coût⁸. Les clients gardent leurs propres contrats et leurs propres clés d’API chez chaque fournisseur qu’ils utilisent. On ne vend pas d’accès à l’IA et on ne limite pas les outils auxquels les gens peuvent recourir.

Cette position d’architecture a des conséquences au-delà de la mesure des coûts. La même instrumentation qui fait ressortir le gaspillage de tokens fait aussi ressortir des schémas qui comptent pour la sécurité. Des prompts qui contiennent des données personnelles de clients et partent vers un outil d’IA grand public. Du code source collé dans ChatGPT. Des employés qui font tourner leurs projets perso sur l’abonnement de l’entreprise. On les voit sur le terrain uniquement parce que la couche des requêtes est le seul endroit où ils sont visibles.

L’article de Stanford fait un argumentaire économique net à partir d’un benchmark. Nos observations font exactement le même à partir d’environnements d’entreprise réels. Les schémas qui font grimper le coût de l’IA sont massifs, mesurables et constants. Il te faut juste la tuyauterie pour les voir.

Bai, L., Huang, Z., Wang, X., Sun, J., Mihalcea, R., Brynjolfsson, E., Pentland, A., and Pei, J. (2026). How Do AI Agents Spend Your Money? Analyzing and Predicting Token Consumption in Agentic Coding Tasks. arXiv:2604.22750v2. Les auteurs reconnaissent des travaux concomitants sur la distribution des tokens dans les systèmes multi-agents (Salim et al. 2026, Wang et al. 2025) et sur la dynamique des prix dans les modèles de raisonnement (Chen et al. 2026). Mais la combinaison d’échelle, de finesse et de données ouvertes fait de cet article le plus utile que j’aie vu pour comprendre à quoi ressemble vraiment la dépense agentique. Les auteurs publient aussi un site de projet avec le jeu de données des trajectoires, un dépôt de code d’analyse pour reproduire les figures, et un petit jeu interactif, Can You Guess the Token Cost?, qui fait passer la conclusion phare de l’article en une trentaine de secondes. ↩
Bai et al., Figure 1. Le code agentique coûte en moyenne 4,17 M de tokens par tâche et 1,86 $, contre 3,39 k tokens pour les tâches de chat de code et 1,19 k tokens pour le raisonnement sur code en un seul tour. Le chiffre de 1 000x est le rapport avec le raisonnement. Avec le chat, il est d’environ 1 200x. ↩
Bai et al., Figure 6 et Section 4. La Section 4 répond précisément à l’objection « les tâches plus dures coûtent naturellement plus » en montrant que l’écart persiste sur le sous-ensemble des réussites communes (n=230 tâches résolues par tous les modèles testés). Les auteurs décrivent la différence comme « model-specific behaviour rather than intrinsic task difficulty ». ↩
Bai et al., Figures 2a et 2b. Jusqu’à 30x de variance entre instances. Sur une même tâche, à travers quatre exécutions, l’exécution la plus chère coûte en moyenne environ 2x la moins chère. ↩
Bai et al., Figure 10 et Figure 11. La meilleure corrélation sur les huit modèles est 0,39 (Claude Sonnet 4.5, tokens de sortie). La prédiction des tokens d’entrée est uniformément moins bonne que celle des tokens de sortie. Chaque modèle sous-estime systématiquement. La Figure 11 montre des prédictions regroupées bien sous la diagonale, partout. ↩
Bai et al., Figure 3b. La précision augmente nettement du quartile le moins cher au deuxième quartile le moins cher, puis plafonne. Les troisième et quatrième quartiles ne se distinguent pas statistiquement du deuxième. ↩
Bai et al., Figure 4 et Annexe A. Coefficients de régression à effets mixtes d’environ 4x pour les modifications répétées et 2x pour les consultations répétées dans le quartile de coût le plus élevé, tous deux significatifs à p < 0,001 par rapport au groupe de coût minimal, en contrôlant l’identité du modèle. L’analyse des tokens de sortie en annexe montre le même schéma. ↩
Flowstate. Je l’ai cofondé, donc la mention évidente de conflit d’intérêts s’applique. ↩