Tout le monde dit que Claude Code gaspille des jetons, mais combien en consomme-t-il exactement ? Enfin, quelqu'un a calculé le chiffre exact.
Récemment, une expérience comparative intéressante a été menée par l'équipe de Composio. Ils ont utilisé le même modèle Kimi K3, exécuté séparément dans trois frameworks d'agent différents (harness) —— Claude Code, Hermes et Kimi Code —— Au total, 28 tâches identiques ont été testées.
En conséquence, les trois harness ont des taux de réussite similaires pour accomplir la tâche : Kimi Code a réussi 22 sur 28, Hermes 21 et Claude Code 20. L'écart n'est pas important.
Ce qui fait vraiment la différence, c'est la consommation de tokens. Pour une même tâche, l'utilisation de tokens peut varier jusqu'à 30 fois selon le harness utilisé !
En médiane, Kimi Le code utilise environ 61 000 tokens, Hermes environ 67 000, tandis que Claude Code atteint directement 340 000, soit environ Kimi Six fois le code.
Appuyez sur Kimi Le coût est calculé à 3 dollars par million de tokens d'entrée (les tokens d'entrée représentent généralement environ 95 % dans les flux de travail des agents), le coût moyen par tâche est d'environ : Kimi Code à 0,22 $, Hermes à 0,28 $, Claude Code à 2 $. L'écart est évident.
Les vitesses sont également différentes. En termes de temps médian, Hermes est le plus rapide, à 179 secondes ; Kimi 297 secondes ; Claude Code 348 secondes.
Ainsi, le plus rapide est Hermes, le plus économe en tokens est Kimi Code, les deux ne se chevauchent pas.
L'équipe de Composio en déduit une conclusion directe : si vous souhaitez réduire les coûts des agents, examinez d'abord quel harness vous utilisez, plutôt que de vous précipiter pour changer de modèle. Selon leurs données, le harness seul peut faire varier les coûts jusqu'à 9 fois, tandis que les performances des modèles sont en réalité similaires.
Sebastian Raschka a également posté après avoir vu ce résultat, disant que cela correspond à ses observations précédentes avec Qwen3.6 : Claude Code utilise souvent deux à trois fois plus de tokens que beaucoup d'autres harness, tout en ayant un taux de réussite similaire.
Il a évoqué plusieurs causes possibles : est-ce dû à une faible optimisation ? À un bogue ? Ou est-ce délibérément conçu ainsi (car cela pourrait aider sur des tâches plus complexes) ? Il a indiqué qu’il devait consacrer davantage de temps à une analyse approfondie.
Il a ensuite ajouté les observations qu'il avait faites en écrivant son article sur les agents de codage locaux le mois dernier. À l'époque, il avait analysé pourquoi Claude Code utilisait plus de jetons et avait constaté que la différence provenait principalement des jetons d'entrée, et non des jetons de sortie. Autrement dit, Claude n'écrivait pas deux fois plus de contenu. Les journaux indiquent que le harnais de Claude réintroduit répétitivement davantage de contexte dans le modèle au cours d'interactions multiples, y compris les messages précédents, les appels d'outils, les sorties de commandes et le contenu des fichiers. Par exemple, lors d'une exécution, Claude a utilisé environ 578 000 jetons d'entrée, mais seulement environ 4 500 jetons de sortie, répartis sur 25 cycles. La meilleure explication est donc que le harnais de Claude accumule ou inclut un historique de prompt plus vaste lors de l'exécution en plusieurs étapes d'un agent.
These test results appear to reveal a trend that cannot be ignored: the importance of harness is now on par with the model itself.
Un article récent (de Writer, une entreprise qui développe une plateforme d'agents IA pour les entreprises) révèle systématiquement cela : il démontre par des expériences à variables contrôlées qu'changer la couche de harness coûte moins cher que de changer le modèle, et que tous les modèles en bénéficient.
Plus précisément, ils ont mené une expérience rigoureuse « à variables contrôlées » : en gardant fixes 22 tâches d'entreprise et 6 modèles de base (Claude Sonnet 4.6, Gemini 3.1, Gemini Flash 3.5, Qwen 3.6, GLM 5.1, Palmyra X6), ils n'ont remplacé que la couche d'orchestration — en substituant le cycle d'agent de production traditionnel par le Harness propre à Writer.
Les résultats de l'expérience montrent une réduction moyenne de 41 % du coût par tâche (de 0,21 $ à 0,12 $), une diminution de 44 % du délai médian (de 48 secondes à 27 secondes), et une réduction de 38 % de la consommation de tokens (de 14,2k à 8,8k), tandis que la qualité de réalisation des tâches reste globalement stable (0,78 à 0,81, considérée comme sans différence significative en raison de la taille échantillonnale réduite). En termes de rapport qualité-prix, la qualité obtenue par dollar dépense augmente de 82 %, et le nombre de tâches accomplies par million de tokens passe de 54,9 à 92,0.
Donc, après que le modèle est devenu « eau, électricité, gaz », le harness est-il l’air conditionné qui détermine votre facture d’électricité ? Autrement dit : auparavant, on disait « le modèle est le produit », maintenant c’est « le harness est le produit » ?
Since harness is so important, shouldn't the subsequent accounting be more detailed?
Quelqu'un a souligné qu'il était nécessaire d'ajouter la « taxe harness » aux benchmarks existants. Cela est particulièrement pertinent compte tenu du fait que, dès lors que les appels d'outils et les réessais entrent en boucle, cette taxe ne croît pas de manière linéaire.
Autrement dit, dans les futures compétitions d’agents, la première mi-temps se jouera sur la capacité à le faire, et la seconde mi-temps sur qui le fera le plus économiquement — et le secret de l’économie ne réside pas dans le modèle, mais dans le harness.
Avez-vous eu une expérience similaire lors de l'exécution de l'Agent ? N'hésitez pas à en discuter dans les commentaires.
Cet article provient du compte WeChat « Machine Heart » (ID : almosthuman2014), auteur : Machine Heart