Imaginez la scène : vous ouvrez un assistant de programmation IA et tapez « OK » pour le confirmer. Deux caractères — et avant même qu’il ne « voie » ces deux caractères, il a déjà consommé silencieusement environ 33 000 tokens de quota de calcul en arrière-plan. Un autre outil au fonctionnement similaire, dans les mêmes conditions, n’en a utilisé que quelque 7 000.
Ce n’est ni une métaphore ni une estimation. C’est la conclusion d’une expérience réelle obtenue par l’équipe de Systima, qui a placé un proxy de journalisation devant l’API d’Anthropic et enregistré ligne par ligne les données brutes de chaque requête. Ils ont publié la méthode expérimentale complète et les chiffres originaux sur leur blog ; l’article a ensuite recueilli plus de 400 upvotes et 200 commentaires sur Hacker News.
L’auteur veut expliquer, en termes accessibles, trois choses derrière ce chiffre : que fait réellement un outil de programmation IA « avant de voir vos mots » ? Pourquoi les sous-agents sont-ils le véritable gouffre à tokens ? Et quel rôle joue le modèle économique à la demande ?
Qu’est-ce qu’un token ? Et pourquoi brûle-t-il comme de l’essence ?
Avant d’entrer dans les chiffres, expliquons un concept clé. On peut comprendre le token comme l’unité minimale de mesure du texte traité par une IA — ce n’est pas « un caractère », c’est environ 0,75 mot en anglais, ou un à deux caractères en chinois. Lorsque vous utilisez un service IA facturé à l’usage, chaque token traité génère une facture.
Un outil de programmation IA diffère d’une conversation IA ordinaire. Quand vous discutez avec Claude sur le web, il reçoit fondamentalement votre question. Mais un outil de programmation IA doit, en plus de votre question, injecter une quantité considérable de « préparation » — dire à l’IA qui elle est, quels outils elle peut appeler, quelles sont les règles de votre projet, quel est le répertoire de travail courant, les informations d’environnement du système d’exploitation, etc.
Ce contenu supplémentaire s’appelle le « harness overhead » (la surcharge du harnais). Le problème, c’est que la taille de ce harnais varie énormément.
33 000 contre 7 000 : la facture d’une simple réponse « OK »
L’expérience de Systima est directe : faire exécuter à deux outils de programmation IA — Claude Code d’Anthropic, et l’open source OpenCode — la même tâche minimale : répondre « OK ».
Avant de lire ces deux caractères « OK », Claude Code a d’abord envoyé environ 33 000 tokens à l’API. Voici la composition de ces tokens : environ 6 500 tokens pour le prompt système (qui dit à l’IA « qui vous êtes, que devez-vous faire »), environ 24 000 tokens pour les définitions de 27 outils (lire un fichier, écrire un fichier, exécuter une commande, gérer des sous-agents, des tâches planifiées…), et environ 2 000 tokens pour des blocs de rappel injectés (état de la tâche, liste des compétences disponibles, informations d’environnement courant).
OpenCode n’a utilisé que quelque 7 000 tokens : environ 2 000 tokens de prompt système, environ 4 800 tokens pour les définitions de 10 outils. Pas de bloc de rappel supplémentaire, une structure très allégée.
Un détail facile à négliger : ces 33 000 tokens ne sont pas « dépensés une seule fois ». Dans le mode de travail d’un outil de programmation IA, chaque tour de dialogue — chaque aller-retour avec le modèle — doit renvoyer tout ce contenu de harnais. Autrement dit, si votre tâche exige 10 allers-retours avec l’IA, le seul harnais consommera 330 000 tokens, sans compter votre code et vos échanges réels.
Le cache aurait dû faire économiser, mais Claude Code a gâché l’affaire
Les fournisseurs d’IA proposent généralement un mécanisme appelé « prompt caching » (mise en cache des prompts) : si la majeure partie d’une requête consécutive ne change pas, elle peut être lue depuis le cache à très bas prix, au lieu d’être recalculée. C’est un levier clé de maîtrise des coûts.
Mais Systima a repéré une différence cruciale : les préfixes de requête d’OpenCode sont à chaque fois identiques à l’octet près, ce qui signifie qu’il n’a besoin d’écrire le cache qu’une fois, puis chaque lecture est facturée au dixième du prix. Or Claude Code, dans des requêtes consécutives pour une même tâche, a réécrit des dizaines de milliers de tokens en cache à plusieurs reprises — soit 54 fois plus d’écritures en cache qu’OpenCode pour une même tâche.
L’écriture en cache coûte beaucoup plus cher que la lecture. En d’autres termes, la hausse du montant facturé s’explique en grande partie par une utilisation inefficace du cache.
La facture réelle en production : de 33K à 85K
Les 33 000 ci-dessus sont encore à l’état « nu » — sans configuration de projet, sans plugin, sans outil supplémentaire. À quoi ressemble un véritable environnement de production ?
Systima a mené une « expérience de superposition ». Ils ont d’abord testé dans un projet vide, puis ajouté progressivement des configurations de scénarios de développement réels :
Première étape : placer un fichier d’instructions de projet de 72 Ko (AGENTS.md ou CLAUDE.md, qui indique à l’IA vos conventions de code). Cette seule étape ajoute environ 20 000 tokens à chaque requête.
Deuxième étape : brancher 5 serveurs MCP légers (permettant à l’IA de lire/écrire des e-mails, gérer des tâches, interroger des bases de données, etc.). Encore environ 5 000 à 7 000 tokens en plus.
Au total, dans un environnement de développement réel, Claude Code a déjà consommé 75 000 à 85 000 tokens avant de lire la question de l’utilisateur. OpenCode gonfle aussi dans des conditions similaires, mais comme son point de départ est bas, l’absolu reste maîtrisé.
Les sous-agents : le véritable gouffre à tokens
Si la consommation du harnais est une « consommation de carburant élevée », les sous-agents, c’est « un réservoir qui fuit ».
Les sous-agents sont une fonction importante de Claude Code : quand une tâche est complexe, l’agent principal peut déployer plusieurs « avatars » travaillant en parallèle, chacun lisant le code, analysant le problème et renvoyant des résultats indépendamment. Cela paraît efficace, mais le coût est stupéfiant.
Systima a comparé sur une même tâche : exécution directe = 121 000 tokens ; avec deux sous-agents en parallèle, la consommation a explosé à 513 000 tokens — soit 4,2 fois plus.
Pourquoi un tel écart ? Parce que chaque sous-agent est une unité de travail indépendante. Il a son propre prompt système (plus allégé que l’agent principal), son propre ensemble d’outils, et doit relire les fichiers du projet pour comprendre le contexte. Une fois sa tâche terminée, tout son historique de conversation est « avalé » par l’agent principal comme référence. C’est comme si vous envoyiez deux personnes se renseigner, et que chacune revienne non seulement avec la réponse, mais avec une caisse entière de tous les documents originaux qu’elles ont consultés.
Le témoignage d’un utilisateur sur HN est encore plus extrême. Il a écrit : « I gave Claude Code a fairly large task, it immediately spun up 7 sub-agents, and before my budget ran out, not one of them had completed the task. Tried again 5 hours later, same result. » Et la même tâche, exécutée séquentiellement par l’agent principal, se passait parfaitement.
L’impasse du modèle économique d’Anthropic
À ce stade, une question naturelle surgit : s’agit-il d’un défaut de conception ou d’un effet du modèle économique ?
L’API d’Anthropic est facturée au token. Claude Code, en tant qu’outil officiel, plus sa consommation de tokens est élevée, plus les revenus d’Anthropic augmentent. Mais cela ne signifie pas nécessairement une « conception délibérée » — c’est plus probablement une incitation structurelle : quand vos revenus dépendent de la quantité de tokens consommés par l’utilisateur, vous n’avez pas, comme la communauté open source, une forte motivation à alléger le harnais.
La raison pour laquelle OpenCode atteint le « plancher » de 7 000 tokens tient en grande partie à son statut de projet open source — son objectif de conception n’inclut pas la maximisation des revenus API. Les 27 outils de Claude Code, ses multiples blocs de rappel, son mécanisme complet de guidage des sous-agents : chaque décision de conception a une justification légitime de « fonctionnalité plus complète ». Mais quand ces « fonctionnalités plus complètes » s’empilent, la facture de l’utilisateur devient un sous-produit.
Mais Claude Code gagne aussi
À titre d’équité, les tests de Systima ont aussi révélé un scénario favorable à Claude Code.
Dans une tâche exigeant des opérations multi-étapes (écrire du code, lancer les tests, corriger selon les erreurs, retester), la consommation totale de Claude Code était en fait inférieure à celle d’OpenCode. La raison : Claude Code regroupe plusieurs appels d’outils dans une seule requête, tandis qu’OpenCode fait un appel d’outil par tour de requête. Bien que la base de chaque requête de Claude Code soit plus lourde, OpenCode, faute de capacité de regroupement, a payé neuf fois le coût de base, et au final la facture totale est plus élevée.
Cette découverte révèle un fait subtil : l’efficacité en tokens d’un outil ne dépend pas seulement de la légèreté de sa base, mais aussi de la façon dont il organise son flux de travail. Base lourde mais capable de regrouper, contre base légère mais devant tourner en boucle : l’avantage dépend de la tâche précise.
Que signifie tout cela pour l’utilisateur ordinaire ?
Si vous ne codez pas, vous pourriez penser que c’est « un problème de programmeurs ». En réalité, à mesure que les outils IA passent du « chat » à « l’exécution de tâches », ce modèle de facturation à l’usage touchera chaque utilisateur.
Quand vous modifiez une ligne de code dans Cursor, ou demandez à Claude Code de corriger un bug, derrière chaque action se joue une histoire similaire : d’immenses instructions système sont renvoyées à répétition, des sous-agents naissent et disparaissent en arrière-plan, le cache est réécrit sans cesse — et la facture s’accumule silencieusement dans ces gestes invisibles.
L’expérience de Systima a tiré au grand jour des chiffres jusqu’alors enfermés dans la boîte noire. En tant qu’utilisateur, savoir que ces chiffres existent est en soi un moyen d’être informé.
Ou, plus simplement : la prochaine fois que vous verrez votre facture API, vous saurez que la plus petite partie seulement correspond à ce que vous avez réellement utilisé.
Liens de référence :
- Systima : Claude Code vs OpenCode Token Overhead
- Discussion HN (item?id=48883275)