1 000× plus de tokens, r ≤ 0,39 : l'étude Stanford/MIT qui enterre le pricing prévisible des agents IA

Avril 2026. Une équipe Stanford / Michigan / AllHands AI / Google DeepMind / MIT publie sur arXiv la première étude empirique grande échelle sur la consommation de tokens des agents IA (Bai et al., 2604.22750v2). 500 tâches SWE-bench Verified, 8 modèles frontières, 4 runs par instance. Trois résultats détonent pour le bilan CSRD : (1) une tâche agentique coûte 1 000× plus de tokens qu'un chat (4,17 M vs 3,4 k), (2) deux runs identiques peuvent diverger de 30×, et (3) les modèles frontières n'arrivent pas à prédire leur propre consommation(corrélation r ≤ 0,39, sous-estimation systématique). Conséquence directe : il n'existe pas de chiffre ex-ante défendable — la seule voie auditable passe par la métadonnée post-exécution.

1 000× plus de tokens — l'ordre de grandeur que ton inventaire 2026 ignore

Bai et al. comparent trois familles de tâches sur le même benchmark :

Source : Bai et al., arXiv 2604.22750v2, Figure 1. Coût moyen calculé sur les tarifs publics des huit modèles frontières testés (Claude Sonnet 3.7 / 4 / 4.5, GPT-5, GPT-5.2, Qwen3-Coder-480B, Kimi-K2, Gemini-3-Pro).

Le facteur 1 000× n'est pas une multiplication mécanique des tours de boucle. Il vient du ratio input/output qui explose: 153,85 pour un agent contre 0,16 pour un chat. À chaque tour, l'agent ré-injecte tout l'historique, plus les résultats des tool calls, plus le contenu des fichiers lus. Et c'est précisément ce qui rend le caching nécessaire : sans lui, le coût exploserait encore d'un ordre de grandeur.

30× de variance sur la même tâche — l'ex-ante est mort

Sur les 500 instances SWE-bench Verified, Bai et al. relancent chaque problème quatre fois par modèle. Résultat (Figure 2) :

• L'instance la plus chère consomme ~7 M tokens de plus que la moins chèresur l'ensemble du benchmark, soit une dispersion totale d'ordre 10⁷.
• Sur une même tâche, le ratio max / min entre runs identiques dépasse 2× pour tous les modèles, et atteint ~30× sur les instances les plus volatiles.
• La queue de distribution est lourde à droite : les tâches les plus chères sont aussi celles avec le plus de variance entre runs — donc les moins prédictibles.

Concrètement : si tu fais tourner Claude Code sur le même ticket Jira deux fois de suite, tu peux avoir un facteur 2 à 30 d'écart sur la facture, donc sur la ligne Scope 3. Aucune estimation a-priori— y compris ton propre historique sur des tâches « semblables » — n'est défendable face à un commissaire aux comptes.

Plus de tokens ≠ meilleure réponse (inverse test-time scaling)

Sur la même tâche, l'accuracy pique à un coût intermédiaire puis sature ou dégrade au quartile le plus cher (Figure 3b). Bai et al. tracent ça à deux comportements identifiables dans les trajectoires des runs chers :

• Modifications répétées du même fichier (coefficient × 4 entre quartile min et quartile max).
• Re-lectures redondantes du même fichier (coefficient × 2,5).

Autrement dit : les runs chers sont des runs perdusen boucle d'exploration redondante. Ce n'est pas du raisonnement supplémentaire, c'est du gâchis. Pour un sustainability lead, c'est l'argument sobriété béton : le budget tokens optimal n'est pas infini, il est intermédiaire. Plafonner l'auto-approve à un budget explicite n'est pas une contrainte business — c'est ce que l'article valide statistiquement.

Le choix de modèle = +1,5 M tokens par tâche (sans gain d'accuracy)

Sur les 230 tâches résolues par tous les modèles (donc à difficulté égale, contrôlée), Kimi-K2 et Claude Sonnet 4.5 consomment en moyenne 1,5 million de tokens de plus que GPT-5(Figure 6b). Sans accuracy supérieure : sur le sous-ensemble partagé, ils résolvent par construction le même nombre de problèmes. Bai et al. tracent ça à des compteurs d'actions granulaires :

Source : Bai et al., Figure 7, sous-ensemble « shared success » (n=230). Le ranking relatif est stable que les modèles réussissent ou échouent — c'est un trait comportemental du modèle, pas de la tâche.

Pour le RSE / FinOps : le choix de modèle est un levier carbone chiffrable. Passer une équipe de Claude Sonnet 4.5 à GPT-5 sur des tâches agentiques peut diviser la facture tokens par ~2,5 sur les tâches partagées, à accuracy équivalente. C'est exactement le type de décision que la dashboard carbon-llm rend visible — segmentation tenant × modèle × période.

Le verdict qui clôt le débat « pricing prévisible » : r ≤ 0,39

Le papier formule pour la première fois la tâche de prédiction ex-ante de consommation: on donne au modèle l'énoncé du problème, on lui demande de prédire combien de tokens il va consommer pour le résoudre. Résultat (Figure 10) :

• Corrélation Pearson entre prédiction et conso réelle : r entre 0,04 et 0,39 — soit inutilisable à utilisable-pour-une-tendance.
• Tous les modèles sous-estiment systématiquement (Figure 11) : la calibration est sous la diagonale, surtout pour les input tokens.
• Le coût de la prédiction elle-même peut atteindre 2× le coût de la tâche (Sonnet 3.7 et Sonnet 4) sans pour autant améliorer la corrélation.

Implication méthodologique pour la mesure carbone : il n'y a pas de chiffre ex-ante défendable. Un commissaire aux comptes qui voit « consommation tokens estimée à partir du nombre de tickets résolus » dans ton ESRS E1 a, par cette publication, une référence pair-reviewée pour exiger la mesure ex-post sur métadonnée provider. C'est exactement le périmètre que carbon-llm couvre depuis POST /api/v1/track.

Où les tokens partent : la décomposition par phase

Bai et al. annotent les trajectoires Sonnet 4.5 en cinq phases (Table 1). La décomposition est utile pour cibler les actions de sobriété :

Le phase Fixà 33,53 % est aussi celle où apparaissent les modifications répétées (le pattern de gâchis identifié plus haut). C'est le levier #1 pour une politique sobriété : limiter explicitement le budget tokens de la phase Fix.

Et un fait technique qui valide la méthodologie carbon-llm : les cache reads dominent le volume et le coût dans toutes les phases (Figure 8). C'est pour ça que notre méthodologie sépare explicitement les compteurs input_tokens, cache_creation_input_tokens, cache_read_input_tokens et output_tokens— les facteurs énergie et CO₂e diffèrent d'un ordre de grandeur entre ces catégories.

Ce que ça change pour ta ligne ESRS E1 / Scope 3 catégorie 1

Trois implications opérationnelles avant la clôture comptable 2026 :

1. Sépare la sous-ligne « agents IA » de la ligne « LLM chat ». Le facteur 1 000× rend toute moyenne pondérée inopérante. Si tu déclares 50 k tokens / dev / jour sur la base d'une mesure chat, tu sous-déclares le réel agentique d'un facteur 1 000.
2. Abandonne toute estimation ex-ante par extrapolation. Le papier confirme statistiquement (r ≤ 0,39) qu'il n'existe pas de proxy fiable. La seule donnée auditable est la métadonnée tokens retournée par le provider après chaque appel.
3. Capture l'ensemble {prompt_tokens, completion_tokens, cache_creation_input_tokens, cache_read_input_tokens} — pas seulement les deux premiers. Sur agentique, les cache reads dominent (Figure 8) et ont un facteur CO₂e très différent de l'input non-caché.

Comment carbon-llm couvre exactement ce périmètre

Trois canaux complémentaires, alignés sur la méthodologie validée par Bai et al. :

• Intégration MCP Claude Code / Cursor — capture des quatre compteurs token (incluant cache_read et cache_creation), status line live avec coût + CO₂e. Voir /claude-code-carbon et la doc /docs/claude-code.
• Extension navigateur — Claude.ai web, ChatGPT, Gemini, Mistral. Capture client-side, aucun prompt lu. Voir /extension.
• REST /api/v1/track — langage-agnostique, un appel par génération, mêmes coefficients que la dashboard. Voir la documentation.

L'export par défaut est un PDF type ESRS E1 avec ligne Scope 3 catégorie 1 dédiée « agents IA », segmentation tenant × modèle × période, signature pour l'audit. Bai et al. te donnent la référence pair-reviewée à citer en méthodologie ; carbon-llm te donne la mesure.