Résumez cet article avec :
L’écart de surcharge de tokens de 4,7 fois entre Claude Code et OpenCode résulte d’un choix de conception, et non d’un défaut.
La consommation de base d’environ 33 000 tokens de Claude Code finance des définitions d’outils plus détaillées, davantage de contraintes de sécurité et une structure contextuelle plus riche. Ces éléments peuvent améliorer la fiabilité de l’agent de codage sur les tâches complexes.
À l’inverse, la consommation initiale d’environ 7 000 tokens d’OpenCode privilégie la rapidité, la maîtrise des coûts et la stabilité du cache. Cette approche est particulièrement efficace pour les tâches simples, comme la recherche dans une base de code, la classification d’erreurs ou les modifications ciblées.
Les conséquences sur le coût des agents de codage IA s’accumulent principalement par trois mécanismes :
- La base de 33 000 tokens est facturée à chaque tour de conversation, et pas uniquement lors de la première requête.
- Le préfixe de cache moins stable de Claude Code peut générer 54 fois plus de tokens d’écriture en cache qu’OpenCode, avec un tarif supérieur de 25 %.
- La multiplication des sous-agents répartit cette consommation initiale entre plusieurs agents exécutés en parallèle. Des incidents documentés ont ainsi atteint 47 000 dollars pour une seule session.
La stratégie la plus efficace consiste donc à adopter un routage hybride des tâches. Les équipes peuvent utiliser des environnements à faible surcharge, associés à des modèles économiques, pour l’exploration, la recherche et les modifications simples. Claude Code et les modèles de pointe peuvent alors être réservés aux tâches difficiles, pour lesquelles leur surcharge en tokens est justifiée par un meilleur taux de réussite.
Les équipes qui adoptent cette approche déclarent jusqu’à 62 % de réduction des coûts, sans dégradation notable de la qualité. La bonne question n’est donc pas de savoir quel agent de codage choisir entre Claude Code et OpenCode. Il faut déterminer quel agent utiliser à chaque étape du processus de développement.
Lorsque vous lancez Claude Code et saisissez un prompt d’un seul mot, l’outil a déjà consommé environ 33 000 tokens en prompt système, définitions d’outils et éléments de contexte injectés, avant même que le modèle ne traite le premier caractère de votre instruction.
Pour une tâche identique, OpenCode, l’agent de codage open source en ligne de commande développé par l’équipe SST, envoie approximativement 7 000 tokens. Cet écart de 4,7 fois sur la surcharge fixe de tokens est loin d’être négligeable. Il découle d’un choix structurel qui influence directement le coût de vos appels API, la latence des réponses et le nombre maximal de requêtes que votre infrastructure peut traiter.
Une équipe de Systima AI a comparé les deux environnements en utilisant le même modèle, Claude Sonnet 4.5, la même machine et les mêmes tâches. Un proxy de journalisation placé entre chaque agent de codage et le point de terminaison du modèle leur a permis d’analyser précisément les requêtes envoyées.
Leurs résultats, publiés en juillet 2026, ont confirmé ce que de nombreux développeurs soupçonnaient depuis le début de l’année 2025 : la charge initiale de Claude Code fonctionne comme l’amorçage complet d’une plateforme, et non comme un simple message système de conversation.
Comparaison de la surcharge en tokens :
Les schémas d’outils constituent le principal facteur de coût pour les deux harnais. Environ 24 000 des 33 000 tokens de base de Claude Code correspondent aux définitions d’outils : opérations sur les fichiers, commandes shell, recherche, ainsi que l’ensemble de la suite d’agents en arrière-plan et d’orchestration (CronCreate, Monitor, la famille Task, la gestion des worktrees et les notifications push). OpenCode fournit 10 outils de programmation classiques totalisant environ 4 800 tokens. Le reste de l’écart provient des trois blocs <system-reminder> injectés par Claude Code, qui répertorient les types d’agents, les compétences disponibles et le contexte utilisateur avant même l’arrivée du prompt de l’utilisateur.
Même lorsque tous les outils sont supprimés (--tools ""), le prompt système de Claude Code représente à lui seul 26 891 caractères, soit environ 6 500 tokens, plus de trois fois les 8 811 caractères d’OpenCode, soit environ 2 000 tokens. La différence restante correspond à des directives comportementales : règles de ton, consignes de sécurité, instructions de gestion des tâches et description de l’environnement.
Où vont les tokens : prompts système, schémas d’outils et structure contextuelle
La base de 33 000 tokens n’est pas monolithique. Elle se décompose en six catégories, chacune ayant des implications différentes en matière d’optimisation.
Répartition des tokens par composant
La plupart des développeurs commettent deux erreurs lorsqu’ils estiment les coûts en tokens. Premièrement, ils calculent leurs dépenses à partir de la longueur du prompt et de la longueur de réponse attendue, en oubliant la base de 33 000 tokens avec laquelle commence chaque appel Claude Code. Une étude menée en 2025 par Latent Space a révélé que 68 % des utilisateurs de Claude Code sous-estimaient leur consommation réelle de tokens d’au moins 40 %.
Deuxièmement, ils supposent que tous les agents de codage présentent une surcharge similaire. Ce n’est pas le cas : le mode chat de GitHub Copilot utilise environ 12 000 tokens de surcharge, le mode agent de Cursor se situe autour de 15 000 tokens, les 7 000 tokens d’OpenCode représentent le niveau le plus faible parmi les outils populaires, tandis que les 33 000 tokens de Claude Code constituent le niveau le plus élevé.
Inspecter votre propre charge utile
Vous pouvez mesurer ce que votre harnais envoie réellement en faisant transiter le trafic par un proxy de journalisation :
import json
from mitmproxy import http
class TokenLogger:
def request(self, flow: http.HTTPFlow):
if "anthropic.com" in flow.request.pretty_host:
body = json.loads(flow.request.content)
system = body.get("system", [])
tools = body.get("tools", [])
messages = body.get("messages", [])
system_tokens = sum(len(json.dumps(s)) // 4 for s in system)
tool_tokens = sum(len(json.dumps(t)) // 4 for t in tools)
msg_tokens = sum(len(json.dumps(m)) // 4 for m in messages)
print(f"System: {system_tokens}t | "
f"Tools: {tool_tokens}t | "
f"Messages: {msg_tokens}t | "
f"Tools count: {len(tools)}")
addons = [TokenLogger()]
Exécutez ce proxy, lancez une tâche triviale (« Réponds exactement : OK »), et vous verrez précisément combien de tokens chaque composant consomme avant que votre instruction n’atteigne le modèle.
Mise en cache des prompts : le multiplicateur de coûts caché
La mise en cache des prompts constitue l’optimisation des coûts ayant le plus fort impact pour les charges de travail utilisant l’API Claude en 2026. Selon le modèle tarifaire d’Anthropic, les écritures en cache coûtent 1,25 fois le prix de base des tokens d’entrée, tandis que les lectures en cache coûtent 10 % du prix de base des tokens d’entrée. Lorsque votre harnais envoie un préfixe stable et strictement identique au niveau des octets à chaque requête, vous ne payez la prime d’écriture qu’une seule fois, puis vous le relisez pour une fraction du prix.
OpenCode exploite parfaitement ce mécanisme. Le préfixe de ses requêtes, composé du bloc système, des schémas d’outils et de la structure des messages, est strictement identique au niveau des octets lors de chaque exécution enregistrée par l’équipe de Systima. Il ne paie donc la mise en cache de sa charge utile de 7 000 tokens qu’une seule fois par session, puis la relit à un dixième du prix des tokens d’entrée lors des tours suivants.
Claude Code ne fonctionne pas ainsi. Il réécrit des dizaines de milliers de tokens du cache de prompt en cours de session, exécution après exécution. Pour une même tâche, Claude Code a écrit jusqu’à 54 fois plus de tokens en cache qu’OpenCode. Comme les écritures en cache sont facturées avec une majoration de 25 % par rapport aux tokens d’entrée standards, ce comportement explique pourquoi le tableau de bord d’utilisation augmente plus rapidement avec Claude Code, même lorsque la tâche est identique.
Exemple économique de mise en cache
Model: Claude Sonnet 4.6 ($3/M input, $15/M output)
Cache write: $3.75/M (1.25x base)
Cache read: $0.30/M (0.10x base)
Scenario: 1,000 API calls, 33K baseline per call
Without caching:
33,000 tokens x 1,000 = 33M tokens
Cost: 33 x $3 = $99.00
With stable caching (OpenCode pattern):
Write once: 33K tokens x $3.75/M = $0.12
Read 999 times: 33K x 999 x $0.30/M = $9.89
Total: $10.01 (89% savings)
With unstable caching (Claude Code pattern):
Assume 50% cache writes, 50% reads:
Writes: 16.5M x $3.75/M = $61.88
Reads: 16.5M x $0.30/M = $4.95
Total: $66.83 (33% savings, but 6.7x more expensive)
La différence entre un préfixe strictement identique au niveau des octets et un préfixe réécrit dynamiquement entraîne un multiplicateur de coût de 6,7 fois pour une même charge de base. Il s’agit du coût invisible le plus élevé de la pile des agents de codage.
Surcharge de configuration : le coût de CLAUDE.md et des serveurs MCP
La base de 33 000 tokens suppose une configuration minimale : aucun fichier d’instructions, aucun serveur MCP et aucun paramètre utilisateur. Dans les environnements réels, les configurations sont considérablement plus lourdes.
Le fichier d’instructions CLAUDE.md ou AGENTS.md d’un dépôt en production, qui contient généralement 50 à 100 Ko de normes de développement, de notes d’architecture et de contexte métier, ajoute environ 20 000 tokens à chaque requête. Cinq serveurs MCP de taille modeste, par exemple pour le système de fichiers, GitHub, Slack, la base de données et les tests, ajoutent encore 5 000 à 7 000 tokens, car chaque serveur MCP connecté charge l’intégralité de son schéma d’outils dans chaque message. Lorsqu’une configuration de travail réelle envoie sa première requête, elle a déjà consommé entre 75 000 et 85 000 tokens avant même que l’utilisateur n’ait saisi un seul mot.
Coût des schémas MCP selon le nombre de serveurs
OpenCode rencontre le même problème avec les MCP, mais à une échelle plus réduite : le schéma complet de chaque outil MCP connecté est chargé à chaque tour, et le système d’autorisations détermine si un outil peut être exécuté, et non si sa définition consomme des tokens. Une issue GitHub ouverte (#17482) dans le dépôt OpenCode demande le chargement dynamique ou différé des schémas d’outils MCP afin d’éviter précisément cette surcharge.
Auditer la surcharge de vos MCP
# Count tool definitions injected by each MCP server
for server in filesystem github slack; do
echo "=== $server ==="
cat ~/.claude/mcp/$server/schema.json 2>/dev/null | \
python3 -c "import sys,json; d=json.load(sys.stdin); print(f'Tools: {len(d.get(\"tools\",[]))}, Chars: {len(json.dumps(d))}')"
done
# Measure total CLAUDE.md weight
wc -c CLAUDE.md AGENTS.md 2>/dev/null
# Rule of thumb: divide chars by 4.2 for approximate token count
Multiplication des sous-agents : quand les coûts en tokens explosent
Le système de sous-agents de Claude Code est puissant et dangereux. Chaque sous-agent fonctionne comme un agent indépendant qui relit son propre prompt système et ses schémas d’outils à chacun de ses tours. Une exécution en parallèle multiplie donc le nombre de charges de base actives.
L’équipe de Systima a mesuré ce phénomène directement : une petite tâche ayant consommé 121 000 tokens dans la session principale en a consommé 513 000 lorsqu’elle a été répartie entre deux sous-agents, soit une augmentation de 4,2 fois. L’agent parent ne récupère que le résultat renvoyé par chaque sous-agent, et non l’intégralité de sa transcription, mais chaque sous-agent paie tout de même sa propre base de 33 000 tokens à chaque tour.
Cette consommation augmente de manière non linéaire. Un développeur a signalé une consommation de 887 000 tokens par minute pendant une session Claude Code de 2,5 heures utilisant des sous-agents en parallèle. Un autre incident documenté par Finout a généré une facture de 47 000 dollars à la suite d’un seul événement de multiplication des sous-agents. Huit schémas documentés de pics de consommation peuvent multiplier les coûts de Claude Code par 10 à 500, la multiplication des sous-agents étant le plus dangereux.
Projection du coût des sous-agents
def estimate_subagent_cost(
base_overhead: int, # tokens per turn (e.g., 33000)
turns_per_agent: int, # average turns per subagent (e.g., 5)
num_subagents: int, # parallel subagents (e.g., 4)
input_price: float, # $/M tokens (e.g., 3.0)
cache_write_ratio: float # fraction of turns that rewrite cache (e.g., 0.5)
):
"""Estimate the token cost of a subagent fan-out task."""
cache_write_price = input_price * 1.25
cache_read_price = input_price * 0.10
per_subagent = base_overhead * turns_per_agent
total_tokens = per_subagent * num_subagents
write_tokens = total_tokens * cache_write_ratio
read_tokens = total_tokens * (1 - cache_write_ratio)
cost = (write_tokens / 1_000_000 * cache_write_price +
read_tokens / 1_000_000 * cache_read_price)
print(f"Subagents: {num_subagents}")
print(f"Total tokens: {total_tokens:,}")
print(f"Estimated cost: ${cost:.2f}")
return cost
# Baseline: 1 agent, no fan-out
estimate_subagent_cost(33000, 5, 1, 3.0, 0.5)
# → Total tokens: 165,000, Cost: $0.35
# Fan-out: 4 parallel subagents
estimate_subagent_cost(33000, 5, 4, 3.0, 0.5)
# → Total tokens: 660,000, Cost: $1.40 (4x increase)
Le paradoxe des tâches en plusieurs étapes : quand une surcharge plus élevée devient avantageuse
La question de la surcharge présente un aspect contre-intuitif. Sur les tâches en plusieurs étapes, le coût total d’une session Claude Code peut être inférieur à celui d’OpenCode, malgré une charge de base plus élevée à chaque tour. Cela s’explique par le fait que Claude Code regroupe les appels d’outils dans un nombre plus limité de requêtes HTTP, tandis qu’OpenCode paie de nouveau sa base plus légère de 7 000 tokens tour après tour.
L’équipe de Systima a constaté cet avantage lors de son premier test de modèle avec Claude Sonnet 4.5. Cependant, lorsqu’elle a exécuté de nouveau la même tâche avec un modèle plus récent, Claude Fable 5, l’avantage s’est inversé : Claude Code a effectué deux fois plus de requêtes et consommé environ 298 000 tokens, contre 133 000 pour OpenCode. Le compteur démarre plus haut, mais c’est le déroulement de la session qui détermine quel outil consomme le plus.
Un benchmark réalisé en conditions réelles dans une entreprise fintech de 120 personnes illustre ce compromis. L’entreprise a exécuté deux pipelines identiques de revue de code, l’un avec Claude Code et l’autre avec OpenCode, sur 500 pull requests :
Calcul des coûts : l’impact sur votre facture API
Selon les tarifs publiés en juin 2026, la différence de surcharge en tokens se traduit directement en coûts financiers. Voici le coût d’une tâche triviale unique (« Réponds exactement : OK ») selon les harnais et les modèles :
Pour une équipe exécutant 10 000 appels automatisés par mois, la différence de surcharge entre Claude Code et OpenCode représente 770 dollars supplémentaires par mois avec Sonnet 4.6, soit 9 240 dollars par an. Aux tarifs d’Opus 4.8, l’écart atteint 1 430 dollars par mois, soit 17 160 dollars par an. Ces montants correspondent uniquement à la charge de base, avant même de comptabiliser les tokens consacrés au travail réel.
Coût mensuel selon le profil d’utilisation
Stratégie pratique : routage hybride des agents
L’approche optimale ne consiste pas à « utiliser OpenCode pour tout » ni à « utiliser Claude Code pour tout ». Elle consiste à effectuer un routage selon chaque étape : un modèle économique pour l’exploration, un modèle intermédiaire pour les correctifs standards et un modèle de pointe pour les échecs complexes, associé au harnais qui minimise la surcharge à chaque étape.
Modèle de routage à trois niveaux
Pour les équipes utilisant une plateforme d’API multi-fournisseurs, ce routage devient très simple à configurer. Vous pouvez définir le niveau d’exploration économique afin d’acheminer la recherche de fichiers et la synthèse des logs vers DeepSeek V4 Flash, le niveau de développement par défaut vers Claude Sonnet pour la génération de correctifs, et le niveau d’escalade vers Claude Opus pour les décisions d’architecture, le tout avec une seule clé API et un suivi des coûts par fournisseur.
Mise en œuvre : routeur tenant compte des tokens
import os
import anthropic
class CodingAgentRouter:
def __init__(self):
self.tiers = {
"scout": {
"model": "deepseek-v4-flash",
"max_tokens": 2000,
"harness": "opencode", # low overhead
},
"coder": {
"model": "claude-sonnet-4-6",
"max_tokens": 8000,
"harness": "opencode",
},
"escalation": {
"model": "claude-opus-4-8",
"max_tokens": 16000,
"harness": "claude-code", # accepts higher overhead
},
}
def classify_task(self, prompt: str) -> str:
"""Route based on task complexity signals."""
escalation_signals = [
"architecture", "redesign", "debug this",
"refactor entire", "security audit"
]
scout_signals = [
"list files", "search for", "summarize",
"what does", "find all"
]
prompt_lower = prompt.lower()
if any(s in prompt_lower for s in escalation_signals):
return "escalation"
if any(s in prompt_lower for s in scout_signals):
return "scout"
return "coder"
def route(self, prompt: str):
tier = self.classify_task(prompt)
config = self.tiers[tier]
print(f"Routing to {tier}: {config['model']} via {config['harness']}")
return config
Checklist de contrôle des coûts
- Comptez les tokens des transcriptions réelles des agents, et pas seulement ceux de la réponse finale.
- Maintenez les instructions système stables et compatibles avec la mise en cache, en évitant les structures contextuelles dynamiques.
- Résumez le contexte du dépôt avant chaque nouvelle tâche au lieu de le renvoyer intégralement.
- Acheminez les étapes peu coûteuses, comme la recherche de fichiers et la synthèse des logs, vers des modèles économiques.
- Limitez la longueur des réponses pour les modifications courantes.
- Utilisez les tarifs des API Batch ou Flex pour les tâches non interactives lorsqu’ils sont disponibles.
- Suivez les boucles d’échec de compilation et de test comme une métrique de coût distincte, car les nouvelles tentatives s’accumulent.
- Auditez les schémas des serveurs MCP chaque trimestre et supprimez les outils inutilisés.
- Définissez des budgets de tokens stricts pour chaque invocation de sous-agent.
