94% de mes tokens Claude Code sont allés au mauvais modèle. J'ai donc arrêté de payer Opus pour faire le travail de Haiku.

12 min read

Vous avez l'impression d'avoir tout fait comme il faut avec Claude Code. Hooks installés. CLAUDE.md peaufiné à 6 890 tokens. Tous les serveurs MCP éliminés, avec cette discipline dont vous êtes secrètement fier un vendredi soir.

Puis arrive le mercredi, trois jours avant le reset de vos limites hebdomadaires, et vous êtes déjà à 80% d'usage. Même avec le plan Max.

C'est là que vous commencez à vous demander ce que cette discipline vous rapportait vraiment.

TLDR. Vous pouvez triturer votre config Claude Code tant que vous voulez. J'ai trouvé un outil gratuit qui ne ment pas sur le bloat, réduit drastiquement les coûts, et rend Claude plus affûté, pas juste moins cher. Voici ce que j'ai fait, et comment vous pouvez reproduire.

Des mois que j'écoutais Boris Cherny et lisais les essais d'Anthropic sur l'ingénierie de contexte. J'avais fait mes devoirs. MCPs supprimés. CLAUDE.md allégé. Quand j'ai aussi archivé les fichiers MEMORY et installé le hook SessionEnd, les chiffres parlaient d'eux-mêmes : 643 sessions en trente jours avec zéro crash et zéro panique /context.

Au bout de mes tokens, je suis parti chercher. Et j'ai trouvé une pépite. Un outil d'audit qui ne se contente pas de compter les tokens. Il vous dit quand Claude devient idiot.

Scène de bureau en écran divisé : employé stressé entouré de factures imposantes et d'écrans de chargement vs employé détendu avec des coûts minimaux affichés sur un tableau de bord
Payer Opus pour faire le travail de Haiku ? C'est juste de la souffrance coûteuse.

Le Score Qui M'a Fait Fermer l'Onglet

Je l'ai lancé la semaine dernière. Six agents en parallèle, soixante secondes. Premier truc à l'écran : Health Score C, 69 sur 100.

Pas D, pas F. C. La note d'un gamin qui pensait avoir bien révisé. J'avais de la marge, ou que dis-je, un gouffre.

Total Session Overhead : 23,5K tokens, 2,3% de la fenêtre d'un million de tokens. CLAUDE.md global à 6 890. Skills à 1 809. Commands 1K, zéro outil MCP, le reste posé où je l'attendais. Les chiffres étaient petits.

Et puis j'ai vu la ligne qui m'a fait arrêter de scroller.

Real session baseline averages 43.2K tokens (+83.9% vs estimate). Gap is from unmeasured system overhead.

L'outil d'audit me disait lui-même qu'il sous-mesurait. Le framing XML, les instructions MCP, les prompts système qui partent avec chaque appel de modèle (avouez, vous ne vérifiez pas ça non plus). Des trucs que je ne vois jamais dans /context, que je payais à chaque message.

Ce que je pensais mesurer représentait la moitié de ce qui était réellement facturé.

C'est le moment où le cadrage a basculé. Le score est une note d'architecture déguisée en jauge de remplissage. La moitié du bloat que je payais, je ne la voyais jamais.

La Dette de Tokens N'est Pas Que Financière

Tous les posts Medium sur les coûts de Claude Code cadrent le truc pareil. Votre contexte est plein. Vous payez trop cher. Allégez votre CLAUDE.md.

À moitié juste. L'autre moitié, c'est que la dette de tokens est double.

La couche financière est l'évidente. L'API Anthropic est stateless. Chaque tour recharge toute la pile. Le prompt caching divise le coût par dix mais la fenêtre elle-même ne rétrécit pas. Donc si vous avez un fichier fantôme de 1 410 tokens qui traîne dans MEMORY pour un projet fini, et que vous envoyez 3 347 messages par jour, et que vous faites ça pendant dix-huit jours... ça fait 85 millions de tokens facturés pour zéro valeur. D'un seul fichier.

Pour l'échelle : 137 millions de tokens facturables, c'est ce que j'ai consommé le mois dernier, total. Un seul fichier fantôme a bouffé plusieurs pourcents du volume. En silence.

La couche cognitive est celle dont personne ne parle. Selon les recommandations publiées d'Anthropic et confirmé par la conception de l'outil d'audit, la qualité chute après 50-70% de remplissage du contexte. La compaction fait perdre des infos. Avec 9,7 millions de tokens en moyenne par session dans une fenêtre d'un million de tokens, ça fait environ dix compactions par session. Six mille compactions en trente jours. Chacune rogne quelque chose (une règle, une convention, un bout de scope que vous avez défini il y a deux heures).

Et puis il y a l'overhead que vous ne pouvez pas voir. L'équipe d'ingénierie d'Anthropic a rapporté que les définitions d'outils MCP consommaient 134K tokens avant qu'ils livrent Tool Search. Un utilisateur Reddit a documenté 67 000 tokens perdus juste en connectant quatre serveurs MCP. Rien de tout ça n'apparaît dans /context.

Les tokens inutilisés vous coûtent de l'argent. Le coût le plus lourd, c'est que vous payez pour dégrader la qualité de votre propre raisonnement, à chaque tour.

J'avais écrit, en février, que CLAUDE.md est le nouveau .env, pas le nouveau README. Je traitais le fichier comme un problème de config. C'était la moitié du tableau. La couche cognitive, je ne l'avais pas vue.

Six Agents, Soixante Secondes, Un Verdict

L'outil s'appelle token-optimizer. C'est un plugin Claude Code, open source, sur le GitHub d'Alex Greensh. Vous l'installez en une ligne : /plugin marketplace add alexgreensh/token-optimizer.

L'architecture est honnête. Six agents qui tournent en parallèle. Sonnet gère les décisions, Haiku fait le travail de comptage, et Opus n'intervient qu'à la fin pour la synthèse. Un dashboard vit sur localhost:24842 et se met à jour automatiquement à chaque hook SessionEnd.

Ce qu'il fait que rien d'autre ne fait : il traque à quel point votre IA devient plus bête au fil de la session. Citation du repo, pas de moi. /context vous montre la jauge. Ça vous montre l'architecture sous la jauge ET la dégradation qualité dans le temps.

L'outil admet aussi ses propres limites. Le +83,9% de sous-mesure que j'ai cité plus tôt ? Ça vient de l'audit qui me dit lui-même : "Gap is from unmeasured system overhead." Un outil qui assume ce qu'il ne peut pas voir est plus crédible qu'un qui prétend tout voir.

Il y a trois semaines, j'écrivais sur le jour où mon plan Pro Max a duré quinze minutes avant que je lance /context et voie le bloat pour la première fois. Je pensais avoir vu le pire. /context vous dit que le frigo est plein. Token-optimizer vous dit que la moitié de la bouffe est périmée.

Ça colle aussi avec une thèse que je pousse depuis des mois. La raison pour laquelle ça marche, c'est que c'est un plugin CLI-natif, pas un serveur MCP. Ça tourne dans la boucle d'exécution de Claude Code, pas sur un protocole d'outil distant. C'est un petit point de données dans pourquoi les outils CLI-natifs battent les serveurs MCP pour les agents IA.

Six agents, soixante secondes, un dashboard. Et chaque trouvaille qu'il produit, vous devez l'appliquer vous-même.

Le Levier Visible Rapporte le Moins

Voici ce que l'audit a trouvé en premier. Trois fichiers MEMORY de projet, archivés de travaux finis. L'un d'eux faisait 1 410 tokens à lui seul. Faites le calcul : 1 410 tokens × 3 347 messages par jour × 18 jours que le fichier est resté dans MEMORY après que j'aie arrêté de toucher au projet. Ça fait 85 millions de tokens facturés pour zéro valeur, d'un seul fichier.

Pour l'échelle, ma consommation facturable totale ce mois-là était de 137 millions. Un seul fichier fantôme a bouffé environ 0,6% de tout mon volume mensuel, sans rien contribuer.

Multipliez ça sur les autres : deux autres fichiers MEMORY archivés. Six citations d'anciens incidents Twitter dans le CLAUDE.md global, retirées. Descriptions de skills verbeuses allégées. Commandes de plugins que je n'invoquais jamais, élaguées.

Le nettoyage total mesuré : -1 386 tokens par message sur la couche fichier, une baisse de 5,9%. Plus 2 565 tokens rasés du corpus à la demande.

La règle que je généraliserais : si un fichier MEMORY n'a pas été référencé dans un prompt depuis 14 jours, archivez-le par défaut. Les docs d'Anthropic recommandent un cap de 200 lignes en auto-load. Le vrai cap pratique est 14 jours de référence.

Maintenant voici la vérité qui dérange.

5,9% n'est pas la demi-bouchée de pain que ça sonne. C'est la couche que vous pouvez voir, ce qui en fait la couche sur laquelle tout le monde s'obsède. Mais c'est aussi la couche qui rapporte le moins.

Le fichier fantôme, c'est l'apéro. Le plat principal est ailleurs.

Deux Bonnes Pratiques Que J'ai Copiées de Threads. Les Deux M'ont Coûté.

Deux trouvailles que l'audit a signalées que vous n'attraperiez pas en lisant tous les docs Anthropic de bout en bout.

La première. J'avais une skill appelée questionnaire-prospect avec une description qui faisait 438 caractères. L'audit l'a signalée au-delà du seuil. Passé environ 250 caractères, Claude Code tronque silencieusement la description dans le menu des skills. Le SKILL.md complet se charge toujours quand la skill est invoquée, mais dans le menu où Claude décide s'il faut déclencher la skill en premier lieu, la description est mutilée.

Résultat : Claude voit une phrase coupée, ne comprend pas quand la skill devrait se déclencher, et l'ignore discrètement. La skill ne plante pas. Elle arrête juste de se déclencher de façon fiable. J'ai raccourci la description à 223 caractères. L'optimum recommandé par l'audit est 80 caractères. Aucun des docs officiels Anthropic que j'ai lus ne mentionne ce comportement de troncature.

Ce que vous écrivez dans une description, et ce que Claude voit réellement, ne sont pas garantis d'être la même chose.

La deuxième. Un hook PostToolUse qui lance vitest après chaque Edit/Write. TDD appliqué au workflow d'agent, aucun état cassé jamais livré. Ça sonnait bien sur Reddit. Ça sonnait bien sur un thread que je lisais.

Dans la vraie vie, avec un fichier édité trente fois pendant un refactor : trente lancements de tests. Trente rapports vitest qui polluent le contexte de Claude (chaque rapport est un message système dans sa fenêtre de contexte). Trente hits de latence. L'audit l'a signalé dès qu'il a tourné. J'ai désactivé le hook. La latence s'est nettoyée. Le contexte est resté plus propre.

La règle qui va au-delà de vitest : un hook PostToolUse générique qui matche Edit/Write est presque toujours un piège. Les hooks devraient se déclencher sur les transitions de phase (SessionEnd, fin de feature, deploy). Pas sur les opérations atomiques.

Fil conducteur des deux : les bonnes pratiques génériques ne sont pas les mêmes que les bonnes pratiques pour VOTRE projet à VOTRE volume. Un dev senior ne lance pas la suite de tests après chaque sauvegarde. Il la lance avant commit. Même logique pour les agents.

Ce sont les patterns que j'ai dénoncés dans chaque tutoriel Claude Code qui s'effondre en production. J'avais collectionné les bonnes pratiques comme les skills : dans un dossier, au cas où, payées en silence.

Pourquoi le Routage a Rendu l'IA Plus Affûtée, Pas Juste Moins Chère

C'est la trouvaille que l'audit a classée numéro un. Et c'est la section vers laquelle pointe le titre.

Trente jours d'usage. 643 sessions. 137 millions de tokens facturables. Mix de modèles : 94% Opus, 0% Sonnet, 4% Haiku, 2% autres.

Sonnet à zéro. Sur 137 millions de tokens.

Je n'avais pas choisi Opus plutôt que Sonnet. Je n'avais simplement jamais configuré le routage au départ. L'audit l'a tagué avec une projection d'économies de 50-75%. Sur les sept jours visibles dans le rapport, j'ai dépensé 1 668$. Une discipline de routage à 50% économise 834$ par semaine. 75% économise 1 250$.

C'est là que l'angle coût atterrit honnêtement, pas sur le nettoyage de fichiers. Mais le coût n'est que la moitié de l'histoire. Le pivot que fait le titre est celui-ci : le routage n'économise pas que de l'argent. Il rend l'IA plus affûtée. Trois mécanismes.

Opus a un tempérament. Il est réglé pour réfléchir. Quand vous lui donnez une tâche bornée, il l'élargit, parce que c'est ce qu'il fait bien. Prenez une semaine type. Je débugge un flow dans ma boutique WooCommerce et je pose une question simple à un agent Explore : "trouve toutes les références à checkout_cta dans la vitrine." Une tâche de grep. Littéralement. Haiku fait ça en quatre secondes pour une fraction de centime.

En mode 94% Opus, l'agent lit 23 fichiers, contextualise les usages, remarque une incohérence entre les formats markdown bullet et blockquote dans les modules anciens versus nouveaux, propose un refactor, ouvre une discussion sur la factorisation du pattern dans un template partagé. Je n'avais rien demandé de tel. Je voulais une liste de fichiers. J'ai eu une mini revue d'architecture. Coût : environ 0,30$, huit minutes, contexte bouffé pour rien parce que j'étais passé à autre chose après.

Routé vers Haiku, même requête : liste en quatre secondes, 0,001$, contexte intact.

Opus n'est pas mauvais ici. Opus est mal casté. Demander à Opus de faire du grep, c'est comme demander à un architecte senior de compter des cartons dans un placard.

Sonnet sur les refactors bornés est plus discipliné qu'Opus. Pour les transformations dans un scope défini, refactoriser un module, ajouter une feature dans un périmètre, Sonnet livre un output qui reste aligné. Moins de propositions alternatives non sollicitées. Bon outil, bon scope.

Opus libéré des tâches bornées devient meilleur sur les décisions architecturales dont vous avez vraiment besoin. Quand vous laissez Opus gérer grep ET comptage ET lookup ET décisions architecturales, au moment où vous l'invoquez sur le problème dur, son contexte est déjà pollué par 47 sessions de grep. La règle "la qualité chute après 70%" vit ici. Vous ne payez pas juste Opus pour faire le boulot d'Haiku. Vous payez aussi le prix caché : votre Opus est moins affûté quand vous en avez vraiment besoin.

Opus reste le bon choix pour le raisonnement complexe, c'est pour ça qu'Anthropic le règle. Haiku n'est pas "plus intelligent" en absolu. La nuance, c'est qu'Haiku est mieux casté, sur la bonne tâche, avec un contexte propre.

Le Levier Que l'Audit Ne Pouvait Pas Tirer Pour Moi

L'audit vous montre. L'audit ne répare pas tout.

Parmi les trouvailles du rapport, le nettoyage de fichiers est auto-applicable. Archivez un fichier, il reste archivé. Le bloat des skills est partiellement auto : les descriptions sont raccourcies en place. Le hook vitest est binaire, on ou off.

Le routage de modèles ? C'est différent.

L'outil injecte un bloc de routage dans CLAUDE.md global avec un TTL de 48 heures. Si je ne le rafraîchis pas, il s'auto-supprime, parce que les patterns d'usage dérivent. Je ne peux pas m'auto-discipliner depuis un fichier de config. Je dois consciemment dispatcher : Explore et lookup vont vers Haiku. Les refactors dans le scope vont vers Sonnet. Les décisions architecturales vont vers Opus.

C'est de la discipline humaine. Mesurable, mais pas automatisable.

Le vrai message de l'audit n'est pas "voici les fichiers à archiver." C'est plutôt : voici la dette que votre workflow accumule, et le levier dominant passe par vous, pas par moi.

Même structure que quelque chose que j'ai livré il y a quelques mois, quand j'ai laissé Claude Code auditer mes propres trois cent soixante-quatorze sessions et que le rapport est revenu inconfortablement honnête. /insights auditait mon comportement. token-optimizer audite ma config. Dans les deux cas, la correction est humaine.

Le chiffre 50-75% est une projection au moment de l'audit. Mon gain réel dépend de ma discipline de routage sur les deux semaines suivantes. Cadrage honnête.

Deux Semaines Plus Tard : Ce Que le Score a Bougé et Pas Bougé

J'ai relancé l'audit deux semaines plus tard. Score différent, forme différente.

Le nettoyage de fichiers a tenu. Les fichiers MEMORY archivés sont restés archivés. Les descriptions de skills sont restées allégées. -1 386 tokens par message sur la couche fichier, baseline. -2 565 tokens sur le corpus à la demande. Ces gains ne demandent pas de volonté. Ils sont structurels.

La couche routage, c'est là qu'était le vrai test. Je m'étais engagé à dispatcher les tâches Explore et lookup vers Haiku, les refactors vers Sonnet, les décisions architecturales vers Opus. Deux semaines de dispatch conscient. Le mix de modèles a bougé, mais pas aussi proprement que je l'avais imaginé. Le TTL de 48 heures sur le bloc de routage dans CLAUDE.md global a fait son boulot : quand j'ai redérivé vers default-Opus un mardi après-midi, l'audit l'a attrapé la fois suivante où je l'ai lancé.

La détection de dérive est la feature que j'avais sous-estimée. L'outil snapshote votre config à l'install et surveille ce qui revient. Si un hook que j'ai désactivé se réinstalle, je le vois. Si un fichier memory que j'ai archivé revient, je le vois aussi. Le mix de modèles qui reglisse vers 90% Opus atterrit aussi en rouge sur le dashboard.

Ce que je vois clairement maintenant : le côté qualitatif est réel. Les tâches Explore que je route vers Haiku reviennent plus vite, dans un contexte plus propre, et les appels Opus que je garde pour les décisions architecturales arrivent sur un contexte qui n'a pas déjà été mâché. Les sessions qui touchaient 70% de remplissage avant compaction l'atteignent maintenant un tiers plus tard. La facture n'enregistrera pas ce changement. L'output si.

Un C n'est pas "mauvais." Ça veut dire qu'il y a de la marge, et vous savez maintenant où.

Les vrais leviers ne sont pas là où Medium continue de pointer. Ils sont dans le routage, et dans les hooks que vous copiez de threads sans tester sur votre propre setup.

Token-optimizer fait partie de ma routine maintenant, à côté de graphify, qui est une histoire pour un autre jour. Je suis plus calme, et Claudius est plus affûté 😊

Moins tenté d'aller voir si l'herbe est plus verte chez Codex.

Sources