La taxe cachée des tokens dans les agents de code IA

Le débat le plus utile de la semaine sur les agents de code ne portait pas sur l'outil qui paraît le plus intelligent. Il portait sur ce que l'agent envoie au modèle avant même de lire la tâche.

Le 12 juillet, Systima a publié une mesure comparant Claude Code et OpenCode à la frontière API. Le chiffre qui a circulé est simple: pour une demande triviale, répondre exactement "OK", Systima a mesuré environ 32 800 tokens au premier tour pour Claude Code et environ 6 900 pour OpenCode. Le 14 juillet, le fil Hacker News atteignait environ 687 points et 378 commentaires.

La réaction n'était pas seulement une guerre d'outils. Le post a touché une douleur réelle. Les agents de code sont assez utiles pour entrer dans le travail quotidien, mais leur coût et leur comportement restent difficiles à voir. Le prompt du développeur n'est qu'une partie de la facture. Le harness ajoute instructions système, tool schemas, consignes du dépôt, descriptions de serveurs MCP, rappels, plans de subagents, cache writes et historique.

La bonne question n'est pas "Claude Code mauvais, OpenCode bon". Les résultats de Systima sont plus nuancés. La question est de savoir si l'équipe voit ce que son stack d'agents envoie, pourquoi il l'envoie, et si la qualité justifie cette charge.

Ce que Systima a mesuré

Systima dit avoir placé un logging proxy entre le coding harness et l'endpoint modèle, puis comparé Claude Code 2.1.207 et OpenCode 1.17.18 sur la même machine, les mêmes tâches et la même famille de modèles. L'étude couvre une tâche minimale, une tâche avec outil et une tâche multi-step write-run-test-fix.

La tâche minimale a fait le tour du web. Elle demandait de répondre exactement "OK". Dans cette configuration, Systima a mesuré environ 33k tokens chez Claude Code avant le vrai travail, contre environ 7k chez OpenCode.

Selon les payloads, la cause n'était pas le prompt utilisateur. C'était le wrapper. Systima affirme que les tool schemas dominaient le baseline: Claude Code exposait 27 tools et environ 99 778 characters de tool schemas, contre 10 tools et environ 20 856 characters pour OpenCode. Même sans tools, le system prompt de Claude Code faisait environ 26 891 characters, soit 6,5k tokens, contre 8 811 characters et 2k tokens pour OpenCode.

C'est la taxe cachée des interfaces agentic. Dans le terminal, cela ressemble à une seule commande. En dessous, l'agent peut envoyer un petit manuel au modèle à chaque tour.

Plus petit ne veut pas toujours dire meilleur

Un baseline léger est séduisant. Il coûte moins, prend moins de context window et réduit souvent la latence. Mais Systima a aussi trouvé un cas où le harness plus lourd de Claude Code ne perdait pas clairement.

Dans la tâche multi-step, Claude Code a groupé plusieurs tool calls dans moins de model requests. OpenCode a fait davantage d'appels un outil par tour. Comme le baseline est repaid à chaque request, moins de requests peuvent compenser un baseline plus gros. Dans ce run Sonnet, Systima a mesuré environ 121k cumulative metered input tokens pour Claude Code et environ 132k pour OpenCode.

Cette nuance compte. Un outil lourd au départ peut être efficace s'il résout en moins de tours. Un outil léger peut coûter cher s'il sérialise trop. Le coût token doit être mesuré par tâche utile, pas seulement au premier request.

Les commentaires Hacker News ont aussi contesté la méthode: Meridian gateway, version de modèle figée, effet de l'envelope du gateway, et survie de certains toggles comme extended thinking. Systima a reconnu plusieurs caveats, et les reruns sur Fable ont changé une partie du tableau.

La conclusion honnête est plus étroite que le titre viral: l'overhead du harness peut être énorme et spécifique à l'outil. Ce n'est pas une loi disant qu'un agent sera toujours moins cher qu'un autre.

Pourquoi les équipes regardent soudain l'overhead

Pour un développeur, l'overhead apparaît comme une limite de subscription consommée trop vite, une session lente ou un contexte saturé. Pour une entreprise, c'est un problème de budget.

La documentation de Claude Code le dit explicitement: Claude Code facture par consommation de tokens API, avec des coûts par développeur très variables selon le modèle, la taille du codebase et les patterns comme instances multiples ou automation. Elle recommande aussi pilot groups, usage tracking, spend limits, org analytics, OpenTelemetry et gateway-based metrics.

Anthropic donne des repères enterprise: environ 13 dollars par développeur et par jour actif, 150-250 dollars par mois, et 90% des utilisateurs sous 30 dollars par jour actif. Cela peut être raisonnable. Mais les moyennes cachent les outliers.

Forbes a récemment décrit le token spend comme une nouvelle métrique de management après la phase "tokenmaxxing". Le cycle est connu en cloud: enthousiasme d'adoption, facture, puis governance.

Les agents de code entrent dans cette deuxième phase.

D'où vient le coût caché

Le prompt visible est rarement le poste le plus cher. Les coûts lourds sont structurels.

Les tool schemas d'abord. Chaque tool exposé a un nom, une description et un schema de paramètres. Si le harness expose fichiers, recherche, shell, navigateur, planning, tâches et MCP tools, le modèle reçoit un grand menu avant la vraie demande. Cela peut améliorer l'autonomie. Cela consomme aussi contexte et argent.

Les instructions projet ensuite. Un gros AGENTS.md ou CLAUDE.md peut être utile s'il contient de vraies règles de dépôt. Il peut aussi devenir une décharge de préférences anciennes, d'avertissements répétés et de style flou. Systima a mesuré qu'un fichier d'instructions réel de 72KB ajoutait un peu plus de 20k tokens par request.

Les serveurs MCP ajoutent leur taxe. Chaque serveur apporte descriptions et schemas. Systima a mesuré environ 1 000 à 1 400 tokens par petit serveur public, par request, avec un avertissement: les serveurs de production aux APIs riches peuvent être beaucoup plus gros.

Les subagents multiplient le problème. Si un orchestrator lance plusieurs agents et que chacun reçoit les mêmes instructions, tools et setup, l'équipe paie le baseline plusieurs fois avant d'améliorer le code.

Enfin, l'historique grossit. Une session longue consacre de plus en plus de contexte au scaffolding et à l'état ancien. Les remises de cache aident la facture, mais elles ne libèrent pas la context window.

Que mesurer avant de débattre d'outils

Un rollout pratique commence par une mesure à la frontière. Sans payload size, cache writes, cache reads, output tokens et request count, on discute surtout d'impressions.

Séparez model cost et harness cost. Un modèle premium est un choix. Un wrapper lourd en est un autre. L'équipe doit savoir si la facture vient du reasoning, des tool schemas, des instruction files répétés, de la metadata MCP, du fan-out de subagents ou de trop nombreux tours.

Mesurez par tâche, pas seulement par session. Un refactor à 300k tokens peut être rentable s'il remplace deux heures d'ingénieur senior. Un renommage à 80k tokens parce que l'agent a chargé tous les tools et instructions, probablement pas.

Mesurez par projet et dépôt. Certains repos ont besoin d'un contexte lourd. D'autres portent des instructions gonflées parce que personne ne les nettoie. La différence doit être visible.

Mesurez par mode d'agent. Planning, implémentation, test repair, code review, dependency updates et documentation ont des profils différents. Envoyer chaque tâche au même setup cher revient à lancer tous les cron jobs sur la plus grosse instance cloud.

Les règles de prompt ne remplacent pas le processus

Un sous-fil HN a touché un point très concret: si vous dites à l'agent dans le prompt de toujours lancer les tests, il peut dépenser des tokens à raisonner sur cette politique et à exécuter de larges checks. Parfois c'est utile. Souvent, cela appartient à des hooks, CI ou scripts spécifiques.

Même chose pour les règles de style, checks sécurité et étapes de release. Si une règle est déterministe, mettez-la là où le logiciel l'applique à bas coût. Pre-commit hooks, pre-push hooks, CI jobs et scripts de dépôt sont ennuyeux, mais ils évitent au modèle de se rappeler et réinterpréter la même règle à chaque tour.

Utilisez les instructions pour le jugement. Utilisez l'automatisation pour la répétition.

L'agent reste alors concentré sur ce qui demande langage et raisonnement: comprendre le changement, choisir l'approche, parcourir le codebase, expliquer les trade-offs et corriger des échecs non évidents.

Gouverner le coût sans tuer l'adoption

La mauvaise réaction serait d'interdire les agents puissants parce qu'un benchmark paraît cher. L'autre mauvaise réaction est d'offrir un accès illimité et d'espérer que la facture ressemble à la démo.

Un rollout sain ressemble davantage à du FinOps pour développement AI.

Commencez par un pilot group. Mesurez du vrai travail, pas des toy prompts. Incluez petits fixes, code review, test repair, migrations et changements multi-file. Comparez token spend et outcomes: temps gagné, bugs trouvés, PR cycle time et satisfaction développeur.

Définissez budgets et alerts. Un développeur doit savoir quand une session brûle contexte ou limites. Les managers doivent voir des tendances par projet et équipe sans transformer le tracking en surveillance.

Routez les tâches. Utilisez le meilleur modèle quand il le faut. Utilisez des modèles moins chers ou des harnesses plus petits pour edits routiniers, explication, formatage et tâches de recherche. Si l'agent supporte les subagents, ceux-ci doivent pouvoir descendre vers des modèles moins chers pour les travaux étroits.

Auditez les instruction files. Supprimez les règles obsolètes. Divisez les instructions géantes en skills ou guidance spécifique si le harness le permet. Les instructions du dépôt doivent être concises et testables.

Auditez les serveurs MCP. Ne connectez pas tous les serveurs à toutes les sessions. Un outil de base de données, navigateur, ticket tracker ou cloud admin peut être précieux. Pas forcément dans chaque prompt de code.

Surveillez le cache. Cache writes, cache reads et context window use sont différents. Un cache read remisé peut tout de même remplir le contexte.

Au-delà du code

Les coding agents rendent simplement le problème visible plus tôt. Le même pattern apparaîtra dans les agents sales, legal research, support automation, data analysis et bots d'opérations internes.

Chaque framework d'agent porte son overhead: role instructions, tool schemas, memory, policies, examples, retrieved context et historique. Une partie améliore la fiabilité. Une autre relève du cargo cult. Sans observabilité, l'équipe ne peut pas les distinguer.

Le marché passe de "donnez plus de contexte au modèle" à "prouvez que ce contexte vaut la peine d'être envoyé". C'est une bonne évolution. Elle ne rend pas les agents moins utiles. Elle les rend plus proches de l'infrastructure.

La leçon pratique

Le post de Systima est devenu viral parce qu'il a nommé un coût que beaucoup ressentaient sans le voir. 33k tokens avant le prompt est un exemple spectaculaire. La leçon est plus large: les agents AI ont une bill of materials.

Cette facture inclut modèle, harness, tools, instruction files, servers, subagents et habitudes de l'organisation. Si un agent coûteux produit de meilleurs résultats, utilisez-le. S'il brûle des tokens dans un scaffolding que personne ne comprend, corrigez le scaffolding.

La prochaine phase mature de AI Practice n'est pas moins d'AI. C'est de l'AI mesurable. Les équipes doivent répondre à des questions simples: qu'a envoyé l'agent, combien cela a coûté, qu'a-t-il accompli, et quelle partie du stack a fait la différence?