Un test contrôlé a placé Claude Code et OpenCode sur le même modèle et les mêmes tâches. Résultat : quand tu demandes aux deux une réponse d’une ligne, Claude Code envoie environ 33.000 tokens de system prompt, schémas de tools et scaffolding avant que ton prompt n’arrive au modèle. OpenCode en envoie environ 7.000. Avec Claude Fable 5 l’écart se réduit (environ 3,3x), car Claude Code envoie un system prompt plus court aux nouveaux modèles, mais reste quand même beaucoup plus lourd.

Pourquoi ça te concerne. Chaque token de surcharge est un coût, une latence et de l’espace soustrait au contexte utile. Si tu utilises des agents en production, ou si la ligne « prompt cache » du dashboard augmente sans que tu comprennes pourquoi, cette analyse explique où vont les tokens. Claude Code réécrit des dizaines de milliers de tokens de cache à chaque tour, tandis qu’OpenCode maintient un préfixe stable payé une seule fois par session. Sur une petite tâche exécutée avec deux sous-agents, le coût est passé de 121.000 à 513.000 tokens, car chaque sous-agent rembourse son propre coût de bootstrap et le parent consomme ensuite la transcription complète.

Une note de continuité. Comme nous l’avons raconté le 12 juillet, Claude Code vient de recevoir le navigateur intégré ; cette analyse montre le coût caché de cette puissance supplémentaire. Le test ne mesure pas la qualité du résultat final, seulement le poids de traîner l’infrastructure à chaque demande.

En détail

La méthode

La mesure a été effectuée en interceptant chaque requête entre l’harness et l’API : un proxy de logging capture le payload JSON complet (blocs système, schémas tools, messages) et le bloc usage retourné par l’API (tokens en entrée, cache write, cache read, sortie). Test sur Claude Sonnet 4.5, puis répété sur Claude Fable 5 pour vérifier si le modèle change la donne.

Conditions d’isolation : config vides, aucun serveur MCP, aucun fichier d’instructions (AGENTS.md), workspace vide, permissions contournées. Trois tâches : T1 (« Réponds exactement : OK »), T2 (lire un fichier et le résumer), T3 (boucle écris-exécute-teste-corrige sur FizzBuzz). Une variante sans tools pour séparer le poids du system prompt de celui des schémas.

Les chiffres sur la table

Sur la tâche minimale (T1), Claude Code part de 33.000 tokens avant de lire le prompt de l’utilisateur. OpenCode de 7.000. Avec Fable 5 Claude Code descend autour de 10.000-11.000 (Anthropic a réduit le system prompt pour les nouveaux modèles), mais l’écart reste 3,3x. Le système le plus léger reste toujours OpenCode, indépendamment du modèle.

Les multiplicateurs

C’est la base à configuration vide. Dans un repository de production, chaque composant ajoute son poids :

• Fichier d’instructions (AGENTS.md ou CLAUDE.md) : un fichier de 72KB ajoute environ 20.000 tokens à chaque requête.
• Serveurs MCP : cinq serveurs modestes (calendrier, email, filesystem, recherche, base de données) ajoutent 5.000-7.000 tokens de schémas.
• Sous-agent : une tâche coûtant 121.000 tokens faite directement coûte 513.000 tokens quand elle est décomposée sur deux sous-agents, car chaque sous-agent a son propre surcharge et le parent consomme ensuite la transcription complète.

Avec une configuration réelle, le compteur part de 75.000-85.000 tokens avant que l’utilisateur ait tapé un mot.

Le cache : là où se joue le match

OpenCode maintient un préfixe de requête identique octet pour octet à chaque exécution de la même session : tu paies le cache write une fois, puis tu lis pour quelques centimes. Claude Code au contraire réécrit des dizaines de milliers de tokens de cache en milieu de session, run après run. Sur l’une des tâches du test, Claude Code a écrit 54 fois plus de tokens de cache qu’OpenCode. Les cache writes sont facturés avec une prime, et expliquent pourquoi le dashboard augmente même quand tu penses réutiliser le contexte.

Une note en faveur de Claude Code

Sur une tâche multi-étapes, Claude Code s’en est sorti avec un total inférieur à OpenCode, car il regroupe les appels aux tools en un nombre inférieur de requêtes, tandis qu’OpenCode rembourse sa propre base (plus petite) à chaque tour. Le compteur part plus haut, mais comment se déroule la session décide qui dépense le plus à la fin.

Ce qui manque

Ce test ne mesure pas la qualité du résultat final : il mesure seulement le coût de l’infrastructure. Un harness qui coûte plus cher peut produire de meilleurs résultats, plus vite, ou avec moins besoin de correction. La bonne question est : pour mon cas d’usage, cette puissance supplémentaire vaut-elle le surcoût en tokens ?

La source complète (Systima) publie les données brutes et la méthode de mesure, permettant à quiconque de reproduire le test sur sa propre configuration. C’est le type de transparence qui est nécessaire quand tu dois justifier une ligne de dépense croissante en production.