Tout le monde dit que Claude Code gaspille des tokens, mais à quel point ? Quelqu'un a enfin fait le calcul.
Une expérience comparative très intéressante a récemment été menée par l'équipe de Composio. Ils ont utilisé le même modèle, Kimi K3, et l'ont exécuté dans trois frameworks d'agent (harness) différents – Claude Code, Hermes et Kimi Code – pour tester 28 tâches identiques.
Les résultats montrent que les taux de réussite des trois harness sont similaires : Kimi Code a réussi 22 tâches sur 28, Hermes 21, et Claude Code 20. L'écart n'est pas énorme.
Ce qui fait vraiment la différence, c'est la consommation de tokens. Pour une même tâche, selon le harness utilisé, la quantité de tokens consommée peut varier jusqu'à 30 fois !
En valeur médiane, Kimi Code utilise environ 61 000 tokens, Hermes environ 67 000, tandis que Claude Code atteint les 340 000, soit environ 6 fois plus que Kimi Code.
En prenant le prix de Kimi K3 de 3 dollars par million de tokens d'entrée (les tokens d'entrée représentant généralement environ 95 % des flux de travail d'agent), le coût moyen par tâche est d'environ : Kimi Code 0,22 dollar, Hermes 0,28 dollar, et Claude Code atteint 2 dollars. L'écart est évident.
La vitesse diffère également. En temps médian, Hermes est le plus rapide avec 179 secondes ; Kimi Code prend 297 secondes ; Claude Code 348 secondes.
Ainsi, le plus rapide est Hermes, le plus économe en tokens est Kimi Code, les deux ne coïncidant pas.
L'équipe de Composio en tire une conclusion directe : si vous voulez réduire le coût de vos agents, vérifiez d'abord quel harness vous utilisez, plutôt que de changer de modèle en urgence. Selon leurs données, le harness à lui seul peut faire varier le coût par un facteur de 9, alors que les performances des modèles sont en réalité similaires.
Sebastian Raschka a commenté ces résultats, disant qu'ils correspondaient à ses observations précédentes avec Qwen3.6 : avec un taux de réussite similaire, Claude Code consomme souvent 2 à 3 fois plus de tokens que de nombreux autres harness.
Il a avancé plusieurs raisons possibles : un manque d'optimisation ? Un bug ? Ou une conception intentionnelle (car cela pourrait aider sur des tâches plus difficiles) ? Il a déclaré avoir besoin de plus de temps pour vérifier en détail.
Il a ensuite ajouté des observations faites le mois dernier lorsqu'il écrivait un article sur un agent de codage local. En analysant pourquoi Claude Code utilise plus de tokens, il a constaté que la différence provenait principalement des tokens d'entrée, et non de sortie. En d'autres termes, Claude n'écrit pas deux fois plus de contenu. Les journaux montrent que le harness de Claude réinjecte de manière répétée plus de contexte au modèle lors des interactions multi-tours, 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 tokens d'entrée, mais seulement environ 4 500 tokens de sortie, sur 25 tours. L'explication la plus probable est donc que le harness de Claude accumule ou compte un historique de prompt plus important lors des exécutions d'agent à plusieurs étapes.
Ces résultats semblent révéler une tendance inévitable : l'importance du harness n'est plus inférieure à celle du modèle lui-même.
Un article récent (de Writer, une entreprise qui développe une plateforme d'IA Agent pour les entreprises) le démontre systématiquement : grâce à une expérience à variables contrôlées, il prouve que changer la couche de harness réduit davantage les coûts que de changer de modèle, et cela profite à tous les modèles.
Plus précisément, ils ont mené une expérience stricte en « variables contrôlées » : en fixant 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 ont uniquement remplacé la couche d'orchestration – en substituant la boucle d'agent de production traditionnelle par le Harness propriétaire de Writer.
Les résultats montrent : une réduction moyenne de 41 % du coût par tâche (0,21 $ → 0,12 $), une réduction médiane de la latence de 44 % (48 s → 27 s), une consommation de tokens réduite de 38 % (14,2k → 8,8k), tandis que la qualité d'exécution des tâches reste globalement stable (0,78 → 0,81, considéré comme non significatif en raison de la petite taille de l'échantillon). En termes de rapport qualité-prix, l'amélioration de la qualité obtenue par dollar a augmenté de 82 %, et le nombre de tâches pouvant être accomplies par million de tokens est passé de 54,9 à 92,0.
Alors, maintenant que les modèles sont devenus des « commodités », le harness serait-il le climatiseur qui détermine votre facture d'électricité ? Autrement dit : alors qu'on disait autrefois « le modèle est le produit », est-ce que maintenant c'est « le harness est le produit » ?
Étant donné l'importance du harness, ne faudrait-il pas aussi faire des calculs plus précis à l'avenir ?
Certains soulignent qu'il est nécessaire d'ajouter un élément « taxe harness » aux benchmarks existants. Surtout lorsque les appels d'outils et les nouvelles tentatives entrent en boucle, cette « taxe » n'augmente pas de manière linéaire.
En d'autres termes, la compétition des agents de demain se jouera en deux temps : la première partie sera « qui peut le faire », la seconde partie sera « qui peut faire la même chose en consommant moins » – et le secret des économies ne réside pas dans le modèle, mais dans le harness.
Avez-vous eu des expériences similaires lors de l'exécution d'Agents ? Partagez-les dans les commentaires.
Cet article provient du compte WeChat « Machine Heart » (ID : almosthuman2014), auteur : Machine Heart
