Comment nous livrons Statnive avec Claude Code sans brûler les tokens

La première fois que nous avons exécuté `/context`, il nous restait 12 %

Statnive est une petite équipe qui livre un plugin d’analytics WordPress axé sur la confidentialité. Notre base de code compte deux sous-modules git (le plugin et le site marketing), 80+ skills Claude Code, 24 connecteurs MCP et une porte de publication qui exécute 141 tests et 31 vérifications de conformité avant que quoi que ce soit ne soit livré.

Pendant les deux premiers mois, le développement assisté par IA semblait magique. Puis il a commencé à sembler coûteux. Les sessions expiraient en milieu de tâche. Le modèle semblait oublier des choses qu’il avait lues cinq minutes plus tôt. Notre facture Anthropic a dépassé 6 $ par jour pour un seul ingénieur.

Nous avons exécuté /context pour la première fois et avons compris pourquoi. Avant d’avoir tapé une seule invite, nous utilisions déjà 88 % de la fenêtre de contexte. Douze pour cent restaient pour le travail réel.

Cet article explique comment nous avons réduit cette surcharge d’environ deux tiers — sans supprimer aucun skill ni connecteur — et les quatre chiffres qui contrôlent désormais chaque publication.

Les chiffres clés : ~54 K tokens de surcharge de base (contre ~175 K), ~73 % de la fenêtre de contexte disponible pour le vrai travail, et les dépenses quotidiennes réduites de ~6 $ à ~2–3 $.

Ce qui vit réellement dans ces 200 K tokens

Claude Code vous donne une fenêtre de contexte de 200 K tokens. Cela semble généreux jusqu’à ce que vous compreniez ce qui la consomme avant votre premier message.

Composant	Ce que c’est	Non optimisé	Notre cible
Invite système	Instructions Claude Code intégrées	~3 200	~3 200
Outils intégrés	Read, Write, Bash, Grep, Glob, Edit	~11 600	~11 600
CLAUDE.md racine	Instructions du projet, toujours chargé	8 000+	≤ 1 500
Métadonnées de skills	Entrées `<available_skills>`	4 000+	≤ 2 500
Schémas d’outils MCP	24 connecteurs × nombreux outils	48 000–120 000	≤ 3 000
Tampon d’auto-compaction	Marge réservée	32 000	32 000

Trois de ces lignes constituent l’essentiel du problème : le CLAUDE.md toujours chargé, le registre de métadonnées de skills et le dump des schémas d’outils MCP. Tout le reste est fixé par le framework.

Le mécanisme sous-jacent est la divulgation progressive. Le système de skills de Claude Code charge uniquement les champs name et description de chaque skill au démarrage — environ 30–50 tokens par skill — et diffère le corps complet de SKILL.md jusqu’à ce que le skill soit réellement invoqué. La même astuce fonctionne pour les schémas d’outils MCP et la documentation de référence, si vous la configurez. Si vous ne le faites pas, chaque définition d’outil, chaque règle, chaque instruction reste dans le contexte pour toujours.

La surcharge des outils MCP était notre plus grande fuite

Exécuter /context pour la première fois est une expérience humiliante. Voici ce que nous avons vu avant de toucher quoi que ce soit :

Connecteur MCP	Outils	Tokens consommés
GitHub	35	~26 000
Playwright (automatisation de navigateur)	21	~13 647
Slack	11	~21 000
Context7 (docs de bibliothèques)	~15	~8 000
20 autres connecteurs	~200	~60 000+

Ces cinq lignes à elles seules consommaient environ 60 % de la fenêtre de contexte avant d’ouvrir un fichier. Le problème est l’architecture : chaque schéma d’outil MCP — nom, description, définitions de paramètres JSON complètes — est injecté dans le contexte au démarrage de session par défaut. Le serveur MCP de Docker livre 135 outils et consomme à lui seul ~126 000 tokens.

La correction qui a fait 85 % du travail pour nous a été d’activer MCP Tool Search. Livré dans Claude Code v2.1.7, Tool Search construit un index léger de ~5 K tokens de noms et descriptions d’outils et charge le schéma complet d’un outil uniquement lorsque Claude l’appelle réellement. Les tests internes d’Anthropic ont montré une réduction de 134 K à ~5 K tokens — une réduction de 85 % — tandis que la précision sur les évaluations MCP a augmenté (Opus 4 : 49 % → 74 %).

L’activation se produit automatiquement lorsque les descriptions d’outils dépassent environ 10 % de la fenêtre de contexte, mais nous vérifions qu’elle est active à chaque session via /context et surveillons la ligne « tool search enabled ».

Nous avons écrit davantage sur les chiffres avant/après et les trois connecteurs que nous avons conservés en chargement immédiat dans un article dédié sur MCP Tool Search.

CLAUDE.md : 162 lignes, pas 800

Contrairement aux skills et aux outils MCP, chaque octet de CLAUDE.md se charge dans le contexte à chaque démarrage de session, sans chargement différé. Cela inclut le fichier racine, tout import via la syntaxe @chemin/vers/fichier (récursif jusqu’à 5 niveaux) et tous les fichiers globaux et d’entreprise.

Notre premier CLAUDE.md faisait 820 lignes. Il documentait chaque skill, chaque workflow, chaque standard de codage, chaque porte de publication, chaque nuance de notre configuration WordPress Coding Standards. C’était exhaustif. Il consommait également environ 12 % de la fenêtre de contexte à chaque session, y compris les sessions qui n’avaient rien à voir avec la plupart de ce qu’il décrivait.

Nous l’avons réduit à 162 lignes en déplaçant les protocoles et en les remplaçant par une table de déclenchement — un pattern compact de consultation de skills qui remplace la prose verbeuse par skill :

## Skill triggers
| Trigger keywords | Skill | Domain |
|------------------|-------|--------|
| sprint, backlog, iteration | pm-sprint-plan | PM |
| deploy, release, ship | statnive-release | Dev |
| security, audit | sec-audit-remediate | Security |

Ce pattern coûte ~800 tokens au lieu de 3 000+ pour une documentation verbeuse. Les protocoles détaillés vivent dans les fichiers SKILL.md individuels, chargés uniquement lorsque Claude y route. Les règles à portée de chemin sous .claude/rules/ prennent en charge les contraintes spécifiques au domaine (conventions React, standards de codage PHP, règles de porte de publication) uniquement lorsque Claude travaille avec des fichiers correspondants.

Le bilan complet avant/après est documenté dans notre article de refonte CLAUDE.md, mais le plus grand anti-pattern que nous avons supprimé était le @-import de grands fichiers de référence dans le CLAUDE.md racine. Chaque @import charge le fichier cible complet à chaque session — nous en avions trois, ajoutant environ 6 000 tokens de surcharge permanente pour du contenu dont le modèle avait rarement besoin.

Niveaux de skills : quatre niveaux, une règle

Nous avons plus de 80 skills couvrant la gestion de produit, l’infrastructure backend, l’assurance qualité, l’audit de sécurité, les patterns spécifiques à WordPress, le packaging de publication, et plus encore. Chargés naïvement, 80 skills × ~50 tokens de métadonnées chacun représentent 4 000 tokens de surcharge permanente. Grandir à 141 skills (comme le framework jaan.to sur lequel nous nous appuyons) peut dépasser 14 000.

La correction est le modèle de niveaux à quatre niveaux défini par le système de skills de Claude Code :

Niveau	Frontmatter	Coût en métadonnées	Quand l’utiliser
Toujours actif	(par défaut)	~40 tokens	Workflows principaux vers lesquels le modèle doit router automatiquement
Auto-invocable	(par défaut, description concise)	~40 tokens	Skills de domaine avec des mots-clés de déclenchement forts
Manuel uniquement	`disable-model-invocation: true`	0 token	Skills accessibles uniquement par commande slash — rares ou destructifs
Fork / sous-agent	`context: fork`	~40 tokens	Revues, audits, analyses multi-étapes qui ne doivent pas polluer le contexte principal

Le test à une question : la conversation principale doit-elle voir la sortie ? Si non — si le skill est autonome et retourne un résumé — c’est un candidat fork/sous-agent et son utilisation de tokens interne disparaît du contexte principal. Anthropic documente les sous-agents retournant ~500–1 000 tokens à partir de 10 000+ de travail interne — environ une réduction de 37 % du contexte principal sur des tâches complexes.

Nous marquons environ la moitié de nos skills comme disable-model-invocation: true — ils ne sont accessibles que via des commandes slash. Cela seul a économisé environ 2 000 tokens de métadonnées de base, et cela a en fait amélioré la qualité du routage pour les skills auto-invocables restants car Claude ne choisissait plus entre des quasi-doublons.

Le découpage complet niveau par niveau — y compris comment nous classons la bibliothèque de skills réelle de Statnive — est dans l’article sur les niveaux de skills.

Isolation des sous-agents pour le travail intensif

Trois catégories de travail ne touchent plus jamais notre contexte principal : les revues de code, les audits de sécurité et la recherche exploratoire. Elles s’exécutent dans des sous-agents — des instances Claude séparées avec leur propre fenêtre de contexte de 200 K tokens — et retournent un message résumé.

L’économie est subtile. Les sessions de sous-agents consomment plus de tokens au total que le travail inline : Anthropic documente que les équipes d’agents utilisent environ 7× plus de tokens au total car chaque agent génère une nouvelle instance Claude avec son propre chargement d’invite système et son initialisation d’outils.

Mais la dépense totale de tokens n’est pas ce que nous optimisons. Nous optimisons pour :

La propreté du contexte principal. Un audit de sécurité qui lit 40 fichiers et trouve 3 problèmes retourne un résumé de 600 tokens. Sans isolation, la boucle de lecture complète consommerait 40 K tokens de contexte principal, nous poussant vers la zone « perdu au milieu » où la qualité de récupération se dégrade de 15–47 %.
Le routage du modèle. Les sous-agents peuvent s’exécuter sur Haiku 4.5 (1 $/5 $ par MTok) tandis que la session principale utilise Sonnet ou Opus. L’exploration en lecture seule n’a pas besoin du modèle supérieur — l’avantage de coût 3× de Haiku se compose rapidement sur les audits qui lisent des centaines de fichiers.

À quoi ressemble désormais une journée de publication normale

Lors d’une journée de publication Statnive typique, nous brûlons environ 400 K–600 K tokens de travail réel. Voici où ils vont :

Travail	Modèle	Pattern
Revue de code matinale sur une PR ouverte	Sonnet (principal) + Haiku (fork sous-agent)	Fork la revue, retourner un résumé
Écriture d’une nouvelle fonctionnalité dans le Dashboard React	Sonnet (principal)	Skill `frontend-scaffold` auto-invocable, références chargées à la demande
Exécution de la porte de publication	Sonnet (principal)	Skill `statnive-release`, piloté par bash — pas de contexte supplémentaire
Écriture d’un de ces articles de blog	Sonnet (principal)	Rédiger inline, forker une passe de révision

La mise en cache des invites gère le reste. Claude Code met en cache le préfixe stable — invite système, définitions d’outils, métadonnées de skills, CLAUDE.md racine — qui se répète à chaque tour. Les lectures de cache coûtent 0,1× le prix de base, offrant environ 90 % de réduction de coût sur ce préfixe stable. Ordonner le contenu statique en premier et dynamique en dernier maximise les accès au cache, nous gardons donc le CLAUDE.md racine au-dessus de tout contexte dynamique injecté.

Ce que nous n’avons pas optimisé

Transparence sur les limites, pas seulement sur les capacités :

Nous ne sommes pas passés à un contexte piloté par hooks intensifs. La recherche suggère que les hooks SessionStart peuvent injecter un contexte dynamique (branche actuelle, fichiers modifiés, services en cours d’exécution) pour remplacer le contenu statique de CLAUDE.md — des études de cas communautaires montrent une réduction supplémentaire de ~62 %. Nous l’avons essayé, nous avons fait marche arrière. Le risque que exit code 2 accumule du texte d’erreur dans le contexte nous a effrayés. Nous reconsidérerons après que la diagnostique des hooks de Claude Code aura mûri.
Nous utilisons encore Opus pour certaines tâches architecturales. La recherche dit de prendre Sonnet par défaut pour 80 % du travail et de réserver Opus pour le raisonnement complexe. Nous le faisons pour les fonctionnalités, mais nous surpondérons Opus pour les publications car le coût d’une publication cassée dépasse la facture Anthropic marginale.
Nous n’avons pas encore créé de portes CI pour les budgets de tokens. Le manuel de recherche — faire échouer la PR si le CLAUDE.md racine dépasse ~1 500 tokens, si les règles non délimitées dépassent 400, ou si un SKILL.md dépasse 500 lignes — empêcherait les régressions. C’est sur la feuille de route. Pour l’instant, nous appliquons avec des vérifications /context manuelles à chaque session.
Nos chiffres sont auto-rapportés. Nous sommes une petite équipe. Les chiffres publics d’Anthropic (134 K → 5 K pour Tool Search, 37 % pour l’isolation des sous-agents, 90 % pour la mise en cache des invites) tiennent dans nos mesures, mais nous n’avons pas publié un benchmark rigoureux comme nous l’avons fait pour les performances des plugins d’analytics WordPress.

L’effet cumulatif est réel

Les quatre optimisations — mise en cache des invites, routage du modèle, isolation des sous-agents et différé des outils MCP — sont multiplicatives, pas additives. Chacune seule semble modeste. Empilées, elles transforment une fenêtre de contexte de 200 K d’étroite à confortable, et transforment une habitude de 6 $/jour en un outil de ~2–3 $/jour. La description complète de la comptabilité des coûts est dans l’article sur l’économie.

Ce que cela signifie pour les utilisateurs de Statnive : la même équipe qui livre un plugin d’analytics axé sur la confidentialité peut travailler à l’échelle d’une équipe beaucoup plus grande, sans compromis sur la couverture des tests ou la rigueur de conformité. Chaque publication réussit toujours les mêmes 141 tests et 31 vérifications de conformité. Le flux de travail IA est un échafaudage, pas un raccourci.

Pourquoi nous avons publié ceci

Nous écrivons des articles comme comment nous avons construit le Tracker WordPress le plus rapide et comment nous testons Statnive parce que nous pensons que l’écosystème WordPress mérite des récits d’ingénierie plus honnêtes. Il en va de même pour le développement assisté par IA : beaucoup de contenu prétend que Claude Code va transformer votre équipe, presque aucun ne montre la comptabilité des tokens.

Si vous êtes une équipe de plugin WordPress, ou toute petite équipe d’ingénierie, exécutant Claude Code à grande échelle : exécutez /context aujourd’hui. Voyez ce qui consomme votre fenêtre. Les quatre chiffres qui contrôlent chacune de nos publications sont maintenant : surcharge de base inférieure à 30 %, CLAUDE.md racine inférieur à 1 500 tokens, MCP Tool Search vérifié actif et zéro @-import dans la configuration racine. Ceux-ci sont réalisables en une après-midi.

Essayez Statnive

Le plugin d’analytics WordPress axé sur la confidentialité construit avec ce workflow est gratuit sur WordPress.org. Code source complet sur GitHub — incluant notre CLAUDE.md, notre skill de porte de publication et la suite de tests complète. Vos données restent sur votre serveur. Les nôtres restent sur le nôtre.