Le tokenmaxxing est mort, vive le tokenmaxxing
(12gramsofcarbon.com)- Aux débuts de l’adoption de l’IA en entreprise, le volume de tokens utilisés a été relié à l’évaluation des performances : ce tokenmaxxing a généré des coûts inutiles, mais il a aussi forcé la diffusion des outils d’IA dans les organisations
- Chez Meta, lorsque l’usage individuel de tokens a été lié à l’évaluation, on a même vu apparaître des usages purement formels, comme faire converser deux agents toute la journée pour faire monter le compteur de tokens
- Par le passé, exécuter des agents pendant de longues périodes était risqué à cause de l’erreur cumulative (compounding error), où de petites erreurs s’accumulent, mais une tendance inverse émerge aujourd’hui : la justesse cumulative (compounding correctness), où davantage de tokens produisent de meilleurs résultats
- Dans la sécurité, des approches consistant à consacrer de gros budgets de tokens à des modèles comme Mythos pour trouver des vulnérabilités apparaissent, créant une structure où les défenseurs doivent dépenser plus de calcul que les attaquants
- À l’avenir, plutôt que de dépenser sans limite dans des modèles haut de gamme coûteux, le centre de gravité pratique du tokenmaxxing pourrait être de faire tourner plus souvent des modèles open source bon marché en boucle
Le tokenmaxxing a commencé par une consommation de tokens dénuée de sens
- Le tokenmaxxing désigne le phénomène par lequel des dirigeants incitent les employés à consommer beaucoup de tokens, y compris pour des tâches à faible valeur réelle
- Exemple emblématique : Meta a été critiquée pour avoir relié l’évaluation des performances au volume de tokens utilisé par chaque personne
- Un employé de Meta a raconté avoir fait dialoguer deux agents entre eux toute la journée pour augmenter son nombre de tokens
- Vu de l’extérieur, cela donnait l’impression que la direction brûlait des coûts sans revenus en face, mais on peut aussi y voir une politique destinée à imposer la diffusion des outils d’IA
- Il y a encore quelques mois, de nombreux profils seniors au sein des organisations refusaient fortement d’utiliser les outils d’IA, et même lorsqu’on parvenait à les convaincre, ils les employaient parfois de façons étranges ou susceptibles de produire de mauvais résultats
- Dans ce contexte, la pression venue d’en haut pour utiliser des tokens a servi de moyen de contrainte brutal pour faire tomber les barrières
La première politique d’usage illimité s’est heurtée à la pression des coûts
- Les politiques de tokenmaxxing ont produit un certain effet, et aujourd’hui presque toutes les équipes codent au moins un peu avec l’IA
- Beaucoup d’équipes n’ont pas encore construit leurs propres systèmes comme Ramp Inspect ou Stripe Minions, mais elles en sont au moins arrivées à utiliser Cursor dans une barre latérale
- Alors que l’usage de tokens a fortement augmenté, OpenAI et Anthropic, dans un contexte de préparation à l’introduction en Bourse, ont limité les volumes inclus dans les abonnements et relevé les prix des API
- Les subventions sur les tokens ont également diminué, poussant certaines équipes à revenir sur les politiques d’usage illimité
- Le tokenmaxxing illimité, au sens traditionnel, approche d’un stade où il devient difficile de résister à l’examen des coûts
De l’erreur cumulative à la justesse cumulative
- L’intérêt des outils d’IA est de leur faire prendre en charge des tâches difficiles et fastidieuses sans supervision humaine constante
- De grandes migrations de code
- Une veille concurrentielle chaque matin
- Le traitement de flux inbound et outbound
- Autrefois, plus on faisait tourner une IA longtemps, plus les petites erreurs et hallucinations du modèle s’accumulaient dans le projet, jusqu’à devenir difficiles à corriger
- Ce phénomène était appelé erreur cumulative (compounding error), et comme il exigeait beaucoup de supervision humaine, il y avait peu de raisons de faire tourner des agents 24 heures sur 24
- Aujourd’hui, l’environnement évolue vers une justesse cumulative (compounding correctness), où consommer davantage de tokens augmente la probabilité d’obtenir une bonne réponse
- Si la dépense en tokens est liée à la qualité des résultats, l’incitation à utiliser beaucoup de tokens réapparaît
La course aux budgets de tokens apparaît d’abord dans la sécurité
- En cybersécurité, on voit déjà des cas où la dépense en tokens est directement liée à la performance
- Cybersecurity is Proof of Work Now prend l’exemple de Mythos d’Anthropic et estime que, pour renforcer un système, les défenseurs doivent consacrer à la découverte de vulnérabilités davantage de tokens que les attaquants n’en utilisent pour les exploiter
- L’AISI a budgété 100 M de tokens par tentative avec Mythos, soit 12 500 $ par tentative et 125 000 $ pour 10 exécutions
- Les modèles dotés d’un budget de 100 M de tokens n’ont montré aucun signe de rendements décroissants, et l’AISI a indiqué que, dans la plage de budgets de tokens testée, les modèles continuaient de progresser à mesure que le budget augmentait
- Dans cette structure, la quantité de calcul et le budget de tokens que l’on peut payer deviennent plus importants que l’ingéniosité
Les boucles et l’exécution prolongée d’agents
- L’intérêt pour les loops évoquées par Boris Cherny sur la scène de Claude Code s’inscrit dans la même dynamique
- Le principe de base des loops est de laisser l’agent s’exécuter jusqu’à la fin de son tour, puis de relancer le même prompt une fois ce tour terminé
- Cela permet de découper automatiquement une spécification lourde et de laisser l’agent en résoudre les différentes parties au fil du temps
- Le concept n’est pas nouveau : il existe depuis juillet dernier et a un temps été appelé « Ralph Wiggum loop »
- Auparavant, il fallait une compréhension approfondie du prompt engineering et du comportement des agents, mais grâce à la justesse cumulative, il devient plus facile d’espérer un résultat approximatif qui s’améliore avec les répétitions
Les modèles open source rendent les itérations rentables
- À long terme, les gagnants du tokenmaxxing pourraient être les plateformes de modèles open source
- Dépenser massivement des tokens auprès des modèles des laboratoires de pointe passe difficilement l’examen d’un CFO
- À mesure que les modèles open source s’améliorent, faire tourner plus souvent des modèles bon marché dans des boucles devient plus attractif
- Par exemple, si Claude apporte une amélioration de 1,1× par itération et GLM 5.2 une amélioration de 1,05×, mais pour un coût environ cinq fois inférieur, il peut être préférable de faire tourner la boucle GLM 5.2 cinq fois plus
- Dans la section « Other things », GLM 5.2 est également décrit comme n’étant pas à l’état de l’art, mais nettement moins cher que les modèles frontier
- GLM 5.2 : environ 1,4 $ par million de tokens en entrée, environ 4 $ par million de tokens en sortie
- Série Opus 4.X : 5 $ par million de tokens en entrée, 25 $ par million de tokens en sortie
- Haiku 4.5 : 1 $ par million de tokens en entrée, 5 $ par million de tokens en sortie
- GLM 5.2 serait plus performant que Haiku et, sur certains benchmarks, parfois plus performant que GPT 5.5
La différence entre dépenses pour développeurs et dépenses pour pipelines
- Le tokenmaxxing prend deux formes différentes
- La première est la dépense de tokens pour les développeurs
- Les développeurs utilisent des outils comme Claude Code, exécutent des loops et consomment beaucoup de tokens
- Si cela améliore la productivité des ingénieurs, il peut s’agir d’une bonne dépense
- La seconde est la dépense de tokens pour les pipelines
- Les développeurs continuent d’écrire le code à la main, puis s’en servent pour créer des agents jetables dédiés à une tâche précise
- Ces agents fonctionnent de manière non déterministe et fragile tout en consommant beaucoup de tokens
- La dépense n’est bonne que si le pipeline fonctionne réellement, mais ces agents n’étaient pas aussi précis que des pipelines déterministes
- Si l’on ajoute un agent de contrôle qualité pour réduire le coût des hallucinations, puis un autre agent pour détecter les erreurs de cet agent de contrôle, le coût en tokens triple
- Les outils de type pipeline jetable sont de plus en plus remplacés non par des agents dédiés à une tâche, mais par des plateformes généralistes habillées d’une couche adaptée à la tâche
Usines logicielles et dépenses extrêmes en tokens
- L’aboutissement naturel est la software factory, voire la dark factory
- Dans cette structure, la base de code crée du code, le relit, corrige les bugs et écrit les tests sans supervision humaine
- L’humain se contente de fournir les spécifications et de recevoir l’application
- La software factory de StrongDM est citée comme un exemple poussé à l’extrême dans cette direction
- StrongDM a affirmé que les ingénieurs devraient viser 1 000 $ de tokens par jour, mais cette affirmation est jugée fortement exagérée et promotionnelle
- Sa propre software factory dépenserait environ 600 $ par mois, et dépenser dès aujourd’hui en tokens, par ingénieur, l’équivalent du coût d’un ingénieur senior chez Google est considéré comme excessif
- Il existe toutefois potentiellement une incitation à dépenser beaucoup d’argent en tokens, même si elle attend encore de se diffuser
1 commentaires
Avis de Hacker News
Tokenmaxxing n’était qu’un moyen de forcer les employés à basculer vers un usage significatif de l’IA.
Les entreprises qui mesuraient la performance à la dépense en tokens peuvent maintenant lever le pied. Les employés ont appris ce qui était possible ou non en essayant l’IA même pour des tâches où ils ne l’auraient pas utilisée auparavant.
Personne n’est assez idiot pour prendre éternellement la dépense en tokens comme critère de performance et accorder un budget illimité. Je pense que c’était, dès le départ, une mesure temporaire pour faire passer les employés dans un nouvel environnement.
Les dirigeants avaient le sentiment que les employés n’adoptaient pas l’IA assez vite, d’où les nombreux articles grand public en 2025 sur des CEO qui mettaient la pression en disant qu’ils licencieraient ceux qui n’utilisaient pas l’IA. Tokenmaxxing était l’extrême opposé, et les entreprises finiront par trouver un point d’équilibre.
Inutile de trop intellectualiser.
Au passage, une réponse citait ce post sur X comme exemple montrant pourquoi les dirigeants ont dû prendre ce genre de mesure. Transformer une entreprise de centaines, milliers ou dizaines de milliers de personnes est difficile, et il faut envoyer des messages simples, un par un. https://x.com/danluu/status/1487228574608211969?lang=en
En réalité, cela ressemble davantage à une couche de managers surpayés, trop éloignés du terrain où se crée la valeur pour comprendre les limites des LLM, qui a suivi aveuglément la mode.
Dans la plupart des entreprises, au mieux, c’était « les autres le font, donc nous aussi » ; au pire, plutôt « voyons si Joe le développeur peut être aussi productif que toute l’équipe, puis virons les autres ».
Dans les faits, beaucoup d’entreprises ont licencié massivement des employés au motif que leur « dépense en tokens était faible, donc leur performance insuffisante ».
Elle peut tout simplement s’appliquer telle quelle à ce cas particulier de stupidité managériale, mais plus généralement, c’est un très beau morceau d’écriture.
J’aimerais pouvoir accorder à n’importe quel humain — sans même parler d’un CEO — une croyance aussi décalée de ce genre.
Quelqu’un qui était junior à l’époque racontait que son entreprise avait introduit pour les tests A/B un système du genre « Tokenmaxxing ». Plus on lançait de tests, plus cela jouait en faveur de l’évaluation de performance ; sur le moment, il trouvait ça idiot, mais au final cela avait bien eu pour effet de familiariser tout le monde avec ce qu’est une expérimentation et la façon de la faire tourner.
Mais dans une grande entreprise, il est bien plus probable que les managers aient reçu de leur VP la pression de faire de l’IA, que les VP aient reçu la même pression des dirigeants, et que les dirigeants aient eux-mêmes été poussés à produire une stratégie IA crédible et quasi magique, capable de faire croître l’entreprise à l’infini tout en réduisant les coûts.
Dans ce contexte, il paraît plus vraisemblable de copier-coller des graphiques Gartner, d’y mélanger des buzzwords entendus en conférence, puis d’espérer que quelqu’un, quelque part, finira un jour par transformer tout cela en quelque chose qui ressemble à du progrès.
Cela fait au moins un an que j’entends dire « cette fois c’est différent, les agents accumulent les succès plutôt que les erreurs », mais je ne le vois toujours pas.
J’ai eu la chance de suivre une formation IA d’une semaine à 50 000 dollars par personne auprès de gens qui tenaient ce discours, et l’une des rares recommandations concrètes utiles était de vider souvent le contexte pour éviter que le travail parte de travers.
Cela dit, pour la recherche de failles de sécurité, cela peut ne pas avoir d’importance. Tokenmaxxing fonctionne clairement pour cet usage. Le secteur est en train d’adopter une forme de fuzzing continu très coûteuse et complexe.
Zed, qui avait autrefois ce genre de fonctionnalité, ainsi que Text Threads, nommé plus tard, l’ont désormais supprimée.
Je me demande qui c’était, pour que quelqu’un puisse penser qu’un tel investissement en valait la peine.
Dire « imaginez qu’un dirigeant d’entreprise sérieux, par exemple quelqu’un comme Mark Zuckerberg, annonce que Meta va brûler de l’argent », c’est un peu comme annoncer par exemple une transition vers le métavers et même changer le nom de l’entreprise pour montrer son sérieux.
La partie « dépenser plus de tokens produit généralement de meilleurs résultats. Nous appelons cela la capitalisation de l’exactitude » est étrange.
Sommes-nous vraiment entrés dans cette phase ? Est-il généralement vrai que plus on dépense de tokens, meilleurs sont les résultats ? Cette position est tellement bizarre que je me demande si l’auteur ne tire pas un intérêt financier de Tokenmaxxing.
C’est l’enfer. Si l’enfer consistait à être coincé pour l’éternité dans des montagnes russes inconfortables et mal entretenues, ce serait exactement ça.
Un titre plus adapté au contenu aurait été : « Les annonces de la mort de Tokenmaxxing ont été grandement exagérées ».
Personnellement, je déteste l’usage de ce tic de titre absurde du type « x est mort, vive x ».
Que signifie ici cette boucle ? Répéter le même prompt jusqu’à obtenir le résultat voulu ? Les résultats successifs ne sont-ils pas trop similaires entre eux ?
https://github.com/topics/loop-engineering
Ces critères ne sont souvent rien de plus qu’une liste de tâches mise à jour. L’un de ces « harnais » extrêmement simples a même été appelé Ralph Wiggum Loop[1], pour évoquer le Tokenmaxxing obtus mais obstiné qui en résulte.
[1] https://awesomeclaude.ai/ralph-wiggum
Ce genre de chose semble se répéter pendant les premières années de l’adoption de la plupart des grandes technologies.
Au début des années 2010, pendant le boom du big data, des dirigeants achetaient déjà des clusters Spark et des data lakes sans cas d’usage analytique clair ni gouvernance.
« On entend rarement un dirigeant d’entreprise dire qu’il va brûler de l’argent juste pour se sentir bien », vraiment ?
Il y a environ quatre ans, notre CEO a fait venir plusieurs fois des consultants en avion pour des exercices de team building. Nous ne pouvons pas nous permettre de remplacer nos serveurs tous les trois ans, mais payer ces consultants n’a posé aucun problème.
Plus récemment, il a aussi fait venir des consultants en branding, et nous avons dépensé des milliers de dollars en frais AWS pour rebrander toutes les photos. Nous opérons sur un marché captif. Pour vendre sur notre marché, il faut obligatoirement être abonné à notre service, et en dehors de ce marché, il est impossible de s’abonner. Au final, le branding augmente le chiffre d’affaires de 0.
Dans une entreprise où j’ai travaillé auparavant, l’une des premières actions du nouveau CTO a aussi été de définir des règles de renommage des serveurs. Il fallait utiliser des noms de villes du monde entier peu familiers pour des employés majoritairement américains : les serveurs de base de données portaient des noms de villes suisses, les serveurs web des noms danois, le stockage des noms finlandais. On est passé de noms traités comme du bétail à des noms d’animaux de compagnie, et ce CTO a tenu environ six mois.
D’après mon expérience, les directions d’entreprise ne sont pas aussi frugales que cet article semble le croire.
Il est difficile d’imaginer avoir travaillé dans un environnement d’entreprise sans jamais voir d’exemples flagrants de ce genre de gaspillage. Les consultants surpayés et les budgets qu’il faut absolument dépenser sont des classiques.
Le film Office Space est sorti il y a 27 ans et son intrigue se moque de « consultants en efficacité » surpayés dont le seul rôle est de dire aux dirigeants de licencier des gens.
Plus exactement, c’est plutôt « parce que ça va aider ma carrière ».