Stanford et Michigan ont chiffré le coût des agents

La facture que personne n'avait vraiment mesurée

Jusqu'en avril 2026, personne n'avait publié de décompte rigoureux et à grande échelle de ce que coûte réellement une exécution d'agentic coding, en tokens, ventilé par type, sur plusieurs modèles de pointe, et sur un benchmark reproductible.

Les praticiens avaient des intuitions. Les éditeurs d'outils avaient des arguments marketing vagues. Mais une expérience contrôlée, huit modèles, 500 vrais tickets GitHub, quatre exécutions indépendantes par tâche, chaque token journalisé ? Cela n'avait jamais été fait.

Puis Longju Bai, Zhemin Huang, Xingyao Wang et leurs collaborateurs de l'University of Michigan, du Digital Economy Lab de Stanford, d'All Hands AI, de Google DeepMind, de Microsoft AI et du MIT l'ont fait exactement. Ils ont publié les résultats dans arXiv:2604.22750 — mis en ligne le 24 avril 2026, révisé en troisième version le 2 octobre 2026 — et je les ai lus attentivement, car c'est précisément le terrain sur lequel je travaille.

Les chiffres sont frappants. Pas parce qu'ils surprennent — j'observe les agents brûler des tokens de près depuis des années — mais parce qu'ils sont désormais consignés, avec une méthodologie que l'on peut auditer.

Ce que coûtent réellement 500 tâches SWE-bench

Les chercheurs ont fait tourner le framework d'agent OpenHands sur SWE-bench Verified : 500 vrais tickets GitHub, chacun exigeant de l'agent qu'il lise un dépôt réel, raisonne sur le problème, appelle des outils et soumette un patch. Huit modèles de pointe : Claude Sonnet-3.7, Sonnet-4, Sonnet-4.5, GPT-5, GPT-5.2, Qwen3-Coder-480B, Kimi-K2 et Gemini-3-Pro Preview. Quatre exécutions indépendantes par tâche, par modèle.

Le chiffre phare de l'étude : 4,17 millions de tokens par tâche en moyenne, pour un coût moyen de 1,857 $ par tâche.

Pour situer, ils ont aussi mesuré les mêmes types de problèmes de code dans deux autres modes — le raisonnement de code en un seul tour (autrement dit : résolution de problème en one-shot, sans outils) et le chat de code multi-tour. La comparaison est presque gênante à regarder :

Cet écart — 3 500× plus de tokens qu'une tâche de raisonnement en un seul tour, et 1 200× plus qu'un chat multi-tour, selon les termes mêmes de l'étude (l'abstract arrondit les deux à « 1000× ») — n'est ni une erreur d'arrondi ni une bizarrerie propre à un modèle. C'est le coût structurel de la boucle agentique : chaque tour d'action s'ajoute à la conversation, et l'historique complet de la conversation est renvoyé au modèle au tour suivant. Le contexte s'accumule. Le modèle n'oublie pas. Vous payez pour chaque token qu'il a jamais vu, à chaque appel ultérieur.

Les input tokens, voilà la vraie facture

Un chiffre de l'étude mérite une seconde lecture : le ratio input/output moyen en agentic coding est de 153,85. Pour chaque token que le modèle génère, il en traite 154 en entrée.

En code chat, ce ratio est d'environ 1,33. En agentic coding, il est supérieur de deux ordres de grandeur.

C'est le problème de compounding de la context window résumé en un seul chiffre. L'agent lit des fichiers, exécute des commandes dans le terminal, récupère une sortie verbeuse, puis relit tout cela — plus tout ce qu'il a déjà fait — au tour suivant. L'output (le modèle qui réfléchit et écrit effectivement du code) est bon marché. C'est l'input accumulé, ré-ingéré et recopié de tour en tour qui engloutit l'argent.

L'étude confirme que cela reste vrai même lorsque le prompt caching est actif. Dans leur analyse par phase de Claude Sonnet-4.5, les cache-read tokens constituaient la plus grosse catégorie de coût dans chaque phase de la tâche — Setup, Explore, Fix, Validate, Closeout — parce que le pur volume de contexte réutilisé est suffisamment important pour que, même au tarif réduit du cache read, il domine sur le coût bien plus élevé mais bien plus petit des output tokens.

Vous pouvez avoir le prompt caching activé et conserver une grosse facture, parce que le type de token le moins cher reste le plus volumineux d'un facteur de plusieurs milliers.

Plus de tokens, de moins bons résultats

Voici le résultat sur lequel je reviens sans cesse, parce qu'il est réellement contre-intuitif jusqu'à ce qu'on en comprenne le mécanisme.

L'étude montre que des exécutions sur la même tâche peuvent varier d'un facteur allant jusqu'à 30× en consommation totale de tokens sur quatre tentatives indépendantes. Vous pourriez résoudre le même ticket GitHub en 800 000 tokens lors d'une exécution et en 24 000 000 lors de la suivante. Même tâche, même modèle, même environnement.

Lorsque les chercheurs ont classé les quatre exécutions de chaque tâche par coût — MinCost, LowerCost, UpperCost, MaxCost — et mesuré la précision à chaque niveau, ils ont constaté que la précision culmine à un coût intermédiaire puis sature ou décline au coût le plus élevé. L'exécution MaxCost n'est pas la meilleure. Elle est souvent moins bonne que l'exécution LowerCost.

Pourquoi ? Les exécutions coûteuses se caractérisent par davantage de consultations répétées de fichiers et d'éditions répétées : l'agent revient sur les mêmes fichiers qu'il a déjà lus, refait des modifications qu'il a déjà faites, accumulant du contexte sans progresser proportionnellement. Les données de coût en tokens des agents de coding IA que je suis de mon côté convergent vers la même explication — le gonflement du contexte n'est pas du raisonnement productif, c'est souvent l'agent qui tourne en rond.

Faire grimper l'usage de tokens ne fait pas grimper la précision. Il n'existe aucun montant en dollars à partir duquel l'agent comble de façon fiable l'écart restant sur un problème difficile. Les chercheurs l'ont confirmé face à des étiquettes de difficulté notées par des humains : 6,7 % des tâches notées « moins de 15 minutes » ont consommé plus de tokens au total que la tâche moyenne notée « plus d'1 heure ». Et 11,1 % des tâches difficiles ont consommé moins de tokens que la tâche facile moyenne. La difficulté perçue par les humains et l'effort de calcul du modèle sont au mieux faiblement corrélés (Kendall τb = 0.32).

Huit modèles, des appétits en tokens radicalement différents

Tous les modèles ne sont pas également coûteux. La comparaison par modèle de l'étude est la donnée la plus claire que j'aie vue sur ce sujet.

Sur les mêmes 500 tâches, Kimi-K2 et Claude Sonnet-4.5 ont consommé en moyenne plus de 1,5 million de tokens de plus que GPT-5. Cet écart persiste sur le sous-ensemble des succès partagés — les tâches que tous les modèles ont résolues correctement — ce qui signifie qu'il n'est pas dû au fait que certains modèles s'attaqueraient à des problèmes plus difficiles. C'est une propriété comportementale du modèle : la quantité de contexte qu'il accumule avant d'agir, la fréquence à laquelle il revisite les fichiers, la quantité d'output qu'il génère par tour.

L'étude distingue aussi ce qui se passe sur les tâches que tous les modèles échouent. Sur ces 100 échecs partagés, GPT-5 et GPT-5.2 ne dépensent que modérément plus de tokens que sur les tâches qu'ils réussissent, tandis que Kimi-K2 — l'exception qui cumule le coût le plus élevé et la précision la plus faible — continue de dépenser bien davantage sur les tâches qu'il ne parvient pas à résoudre. C'est le coût de l'absence d'un signal d'arrêt fiable : les modèles continuent d'explorer, de réessayer et de relire le contexte lorsqu'ils sont bloqués, accumulant des dépenses sans progresser. Certains modèles le font bien plus que d'autres.

L'implication pratique pour quiconque fait de l'agentic coding à grande échelle : le choix du modèle est en soi un levier de coût, car sur les tâches que tous les modèles résolvent, certains y parviennent avec bien moins de tokens que d'autres. L'étude ne chiffre pas cela en un seul pourcentage, et je ne vais pas en inventer un.

Une mise à jour depuis l'étude : les huit modèles testés ont désormais une ou deux générations de retard. En octobre 2026, Claude Code utilise Opus 5.5 par défaut, et Anthropic facture les cache reads sur ce modèle à 5 % du prix de l'input, au lieu des 10 % que payait Sonnet 4.5 (tarifs Anthropic). Cela réduit le poids en dollars de la montagne de cache reads mesurée par l'étude. Cela ne réduit pas la montagne : le volume de tokens est une propriété de la boucle d'agent, pas de la grille tarifaire.

Ce qu'aucun modèle ne peut vous dire à l'avance

La troisième contribution de l'étude est aussi la plus inquiétante. Ils ont testé si les agents pouvaient prédire, avant de démarrer une tâche, combien de tokens ils dépenseraient. La réponse : à peine.

Tous modèles confondus, la corrélation entre l'usage de tokens prédit et réel plafonne à r = 0,39 (Sonnet 4.5, sur les output tokens) — faible à modérée. Les output tokens étaient un peu plus prévisibles que les input tokens, ce qui a du sens : ce que le modèle va écrire est en partie planifiable ; la quantité de contexte qu'il va accumuler via les tool calls et les lectures de fichiers ne l'est pas. Tous les modèles ont aussi systématiquement sous-estimé leur usage réel de tokens. Les modèles ne savent pas à quel point ils vont coûter cher.

Cela compte pour le problème du tarif des tokens d'API LLM bien plus que la plupart des gens ne l'imaginent. Vous ne pouvez pas fixer un budget par tâche en demandant au modèle ce qu'il coûtera. Le modèle vous donnera un chiffre trop bas, et il sera significativement faux.

Ce que cela signifie pour vos coûts (ESTIMATION)

Les conclusions de l'étude convergent vers un seul levier actionnable : c'est le volume d'input tokens, pas l'output, qui pilote le coût de l'agentic coding. Le ratio input/output de 153,85 signifie qu'une réduction de 40 % des input tokens diminue le volume total de tokens d'environ 39,7 % — 40 % × (153,85 / (153,85 + 1)). En dollars, la baisse est un peu plus faible, car l'output coûte plusieurs fois plus cher par token, mais l'analyse par phase de l'étude montre que l'input (surtout des cache reads) reste le premier poste de coût dans chaque phase.

Les mécanismes derrière l'excès d'input tokens sont bien compris — ce sont exactement ceux que couvre le guide de réduction des tokens :

• Le contexte qui croît sans limite tout au long de la conversation, renvoyant du matériel déjà mis en cache
• La sortie d'outils verbeuse (stack traces complètes, git log brut, sortie entière de la suite de tests) injectée intégralement dans le prompt suivant
• Les lectures de répertoires entiers en début de session, là où la semantic search trouverait les fichiers pertinents avec une fraction des tokens
• Les lectures de fichiers répétées alors que le contenu n'a pas changé

Si vous prenez la moyenne de l'étude de 1,857 $ par tâche et une réduction conservatrice de 40 % des input tokens :

Ce sont des estimations grossières extrapolées des chiffres moyens de l'étude. Les coûts réels varient considérablement selon le modèle, la complexité de la tâche et le nombre de schémas ci-dessus que votre agent déclenche. Le calculateur de coût de tokens vous permet de faire tourner ces chiffres pour votre propre volume et votre choix de modèle.

Les pourcentages de réduction sont mon hypothèse, fondée sur ce que fait réellement l'optimisation des input tokens. Le point de référence publié le plus proche que je connaisse est Lindenbauer et al. (JetBrains Research, workshop DL4C de NeurIPS 2025) : sur SWE-bench Verified, le simple masquage des anciennes observations d'outils a réduit le coût de plus de 50 % par rapport à l'agent brut, sans dégrader le taux de résolution. Cela ne change pas ce que le modèle génère. Cela change la quantité de contexte que le modèle est forcé de relire à chaque tour.

L'étude que tout constructeur d'agents devrait lire

Ce qui rend Bai et al. digne d'être lu, ce ne sont pas seulement les chiffres. C'est qu'ils ont mesuré le mécanisme, pas seulement le résultat. Ils ont retracé les trajectoires individuelles tour par tour. Ils ont séparé l'input de l'output, le mis en cache du non mis en cache, phase par phase (Explore et Fix représentent à elles seules environ 64 % des tours). Ils ont montré ce que font réellement de différent les exécutions coûteuses (plus d'accès répétés aux fichiers), pas seulement qu'elles coûtent plus cher.

Le résultat que je continuerai de citer : la précision culmine à un coût intermédiaire puis plafonne. L'exécution MaxCost n'est pas la meilleure. Il n'existe aucune version du « donne-lui juste plus de tokens » qui comble de façon fiable l'écart de capacité. Ce que l'on peut faire — ce que vise un outillage comme Tokenade — c'est extraire le contexte gaspillé pour que les tokens qui atteignent le modèle soient ceux qui comptent.

Jusqu'à environ 10 millions de tokens économisés par mois, gratuitement. Commencez gratuitement — sans carte bancaire.