Réduire ses tokens Claude Code : ce que valent vraiment les plugins

Réduire sa facture de tokens sous Claude Code, on sait à peu près le faire : trimmer son CLAUDE.md, charger les skills en progressive disclosure, désactiver les MCP inutiles, /clear et /compact entre deux tâches. Ces leviers natifs sont documentés partout. Ce qu'on nomme moins, c'est la couche au-dessus : un écosystème de plugins communautaires dédiés aux tokens, dont les README affichent "−98 % de contexte" ou "−90 % combiné", presque toujours mesurés par leurs propres auteurs. Cet article les classe par mécanisme et passe leurs promesses au banc d'essai : j'ai vérifié pour vous, chiffre par chiffre, si ces pourcentages tiennent une fois rejoués à l'API count_tokens plutôt que recopiés du README. La conclusion d'abord, et elle surprend : la plupart de ces chiffres sont justes. Ce sont des pics, mesurés sur le cas le plus favorable (une sortie bien verbeuse, une requête bien ciblée), et rejoués dans ces mêmes conditions, ils tombent juste. Le piège n'est donc pas le mensonge, c'est l'extrapolation : prendre un gain de pointe pour une moyenne de session, et empiler quatre outils en croyant additionner leurs pourcentages. Le bon réflexe reste de mesurer son propre usage.

Une précision sur le périmètre. On reste ici sous Claude Code : ces plugins s'y branchent via ses output styles, ses hooks PreToolUse, son proxy MCP, ses skills. Les mécanismes derrière (compresser une sortie, réécrire une commande verbeuse) ne lui sont pas propres et s'adaptent à d'autres outils, mais on les teste tels qu'ils s'installent dans Claude Code, pas comme des principes génériques façon context engineering portable.

⚠️

Chiffres et prix datés de juin 2026. Prenez les ordres de grandeur, pas les valeurs absolues.

Où partent vraiment les tokens

Trois mécaniques expliquent l'essentiel de la facture, et déterminent quelle zone chaque plugin attaque.

L'output coûte 5× l'input. Sur toute la gamme, le token de sortie est facturé cinq fois l'entrée.

Modèle	Input $/MTok	Output $/MTok	Cache read
Opus 4.8	5	25	0,50
Sonnet 4.6	3	15	0,30
Haiku 4.5	1	5	0,10

Toute optimisation de l'output vaut donc cinq fois la même sur l'input.

Le contexte est ré-envoyé en entier à chaque tour. Claude Code n'a pas de mémoire entre les messages : votre 50ᵉ message paie pour les 49 précédents. Un CLAUDE.md de 5000 tokens coûte 5000 tokens par tour.

Le cache divise l'input réutilisé par 10. Stabiliser le début du contexte (system prompt, CLAUDE.md, définitions d'outils) plutôt que de le faire varier paie. À noter : le tokenizer d'Opus 4.8 compte jusqu'à 35 % de tokens en plus pour un même texte, donc un chiffre relevé sur un modèle plus ancien sous-estime la facture réelle.

Output, sorties d'outils, exploration du code : voilà les zones que les plugins attaquent. Plus une quatrième, les définitions d'outils, que Claude gère désormais lui-même.

Vérifier soi-même

Avant d'ouvrir le banc d'essai, l'outil. Tous les chiffres qui suivent, je les ai rejoués avec l'endpoint count_tokens de l'API Anthropic : il compte les tokens d'un texte sans lancer de génération, et c'est gratuit (il suffit d'une clé API valide, l'appel n'est jamais facturé).

$key  = [Environment]::GetEnvironmentVariable("ANTHROPIC_API_KEY","User")
$body = '{"model":"claude-opus-4-8","messages":[{"role":"user","content":"votre texte ici"}]}'
Invoke-RestMethod -Uri "https://api.anthropic.com/v1/messages/count_tokens" `
  -Method Post `
  -Headers @{"x-api-key"=$key; "anthropic-version"="2023-06-01"; "content-type"="application/json"} `
  -Body $body

C'est ce qui permet d'isoler le coût exact d'un prompt ou d'une sortie d'outil, avant et après plugin. On mesure ainsi, par exemple, le surcoût du français : +34 à +73 % de tokens contre l'anglais sur texte pur (en session réelle, l'écart se dilue à ~10 à 25 %).

Pour suivre non plus un prompt isolé mais sa consommation en continu, ccusage est la source de vérité :

npx ccusage@latest

Couplé à ccstatusline (% de contexte, $ dépensé) ou à cmonitor (vitesse de consommation en direct), vous avez une visibilité permanente. Effet documenté : la simple visibilité réduit la consommation de plusieurs dizaines de pourcents (effet Hawthorne). Tous les chiffres qui suivent sont passés par cet outillage, et vous pouvez les vérifier vous-même.

Caveman, compresser l'output

caveman force un output style "homme des cavernes" : pas d'articles, pas de préambule. Le levier est sain, l'output coûte 5×.

C'est sur les chiffres que ça se complique, alors je l'ai mesuré. Sur six prompts variés, en appels isolés et sur l'output seul, le skill complet fait passer la sortie de 970 à 290 tokens en moyenne, soit −70 % : l'ordre de grandeur du README (65 %) est, lui, honnête. Deux choses le nuancent quand même. D'abord, un micro-prompt d'une ligne ("sois bref, pas de préambule, pas de remplissage") obtient déjà −54 %, soit les trois quarts du gain du skill de 550 tokens : l'essentiel vient de l'instruction de concision, pas du déguisement. Ensuite, ce −70 % vaut sur l'output ; en session réelle, l'input domine (system prompt, outils, historique), si bien que l'économie totale retombe autour de 14 à 21 %, ce que confirment des mesures en session.

Verdict : levier réel, mais visez 10 à 20 % en session, pas 65 %. Et deux lignes de prompt en captent déjà l'essentiel, sans installer le skill. À laisser de côté pour l'onboarding, la formation, ou dès que vous tenez à garder une trace lisible de l'échange.

Context Mode, isoler le contexte

Context Mode attaque le contexte qui gonfle à cause des sorties d'outils. Au lieu de déverser 300 Ko de logs, il exécute l'outil dans un sous-processus sandboxé, indexe la sortie en SQLite, et ne ramène qu'un résumé interrogeable. Claude requête l'index si besoin, sans repayer les 300 Ko à chaque tour. L'auteur annonce −98 % (315 Ko ramenés à 5,4 Ko).

Place aux mesures. Deux sorties verbeuses, comptées à l'API count_tokens avant et après, hors plugin : une réponse d'API GitHub (20 issues) passe de 41 180 à 1 025 tokens (−97,5 %), un journal d'accès de 500 lignes de 40 176 à 168 tokens (−99,6 %). Et le résumé reste juste : le nombre d'erreurs 500 du log était exact. Le claim tient donc, sur ce qu'il vise vraiment : les sorties brutes volumineuses, pas la moyenne d'une session.

Il restait une objection à lever : Context Mode est lui-même un serveur MCP, avec une dizaine d'outils. On pourrait craindre que leurs définitions occupent le contexte en permanence. Je l'ai mesuré, en comparant le /context de deux sessions fraîches, avec et sans le plugin. Le surcoût est négligeable : environ 1 000 tokens de skills enregistrés, le reste dans le bruit de mesure. La raison est que Claude Code charge désormais les définitions d'outils MCP à la demande (le Tool Search natif) : elles ne coûtent quasiment rien au démarrage (juste les noms d'outils, une poignée de tokens), et leurs schémas complets ne se chargent qu'au moment où Claude va chercher l'outil pour s'en servir, c'est-à-dire au moment où il vous fait déjà économiser des dizaines de milliers de tokens.

Verdict : mécanisme solide, chiffre qui résiste à la vérification, coût de présence négligeable. La seule vraie question est l'usage. À installer si vos sessions sont longues, shell ou MCP-heavy, et meurent par accumulation de logs. Sur de l'édition de code légère qui ne produit jamais de grosse sortie, il ne vous coûtera presque rien, mais ne vous apportera rien non plus : sa machinerie reste inutilisée. (Réserve : ce coût quasi nul suppose le Tool Search actif, ce qui est le défaut sur une version à jour de Claude Code

RTK, réécrire les commandes verbeuses

RTK (token reducer kit) repose sur un hook PreToolUse qui, avant exécution, réécrit la commande plutôt que de filtrer sa sortie : un curl ... devient rtk curl ..., un gh issue list ... devient rtk gh issue list .... Le binaire rtk exécute alors une variante qui ne renvoie que l'essentiel. Claude reçoit la version condensée, jamais le brut.

J'ai mesuré trois cas, en comparant la sortie brute à celle de la commande réécrite. Une réponse d'API GitHub passe de 41 180 à 269 tokens, soit −99,3 %. Mais le gain suit la verbosité de la sortie : sur un gh issue list déjà compact, on tombe à −47 %, et sur un petit diff à −32 %. Autrement dit, le −99 % que vous verrez mis en avant vaut pour les sorties les plus bavardes, pas pour toutes. Les auteurs annoncent −60 % de moyenne sur 282 commandes : crédible au vu de mon échantillon, mais je n'ai pas rejoué les 282, donc je le donne pour ce qu'il est, leur chiffre. Ces ratios ont au moins une vertu : ils sont indépendants du modèle, puisqu'on mesure une réécriture de commande et un texte tronqué, pas une génération.

Verdict : le meilleur ratio gain/effort pour les workflows de debug et de CI où Claude lance beaucoup de shell, à condition que ce shell produise des sorties verbeuses. Reproductible à la main avec un hook PreToolUse, RTK vous épargne surtout l'écriture des règles de réécriture.

Codebase Memory, explorer sans tout lire

Les précédents s'attaquent à ce que Claude produit ou reçoit. Celui-ci s'attaque à ce qu'il va chercher. Pour comprendre une structure de code (qui appelle quoi, où une fonction est définie), un agent sans outil grep le projet puis ouvre les fichiers, et le contexte se remplit vite. Codebase Memory indexe votre code en graphe de connaissances (tree-sitter + SQLite) ; l'agent interroge le graphe au lieu de lire les fichiers.

C'est, fait notable, le seul de cette liste dont le chiffre n'est pas auto-reporté : il s'appuie sur une évaluation publiée, sur 31 dépôts. Je l'ai quand même mesuré sur le code d'Express. Une question de routing qui oblige à lire quatre fichiers du routeur, soit environ 15 000 tokens, est répondue par une requête de graphe en 432 tokens (−97 %). Tracer où la classe View d'Express est définie et utilisée tombe de 7 500 à 31 tokens (−99,6 %).

Deux réserves, mesurées elles aussi. Le gain suppose une requête ciblée : un motif de recherche trop large ramène autant de bruit qu'un grep (une requête search_graph trop vague, juste "View", m'a renvoyé 4 371 tokens de résultats parasites). Et le graphe répond aux questions de structure, pas au contenu : pour lire ou modifier le corps d'une fonction, il faut toujours ouvrir le fichier. Codebase Memory remplace l'exploration, pas la lecture.

Verdict : le mieux étayé du lot, sur une zone que les autres ignorent. Précieux sur les gros dépôts où l'agent cherche sans cesse avant d'agir ; superflu sur un petit projet qu'il tient déjà en tête. Compter aussi le coût d'indexation initial et la maintenance de l'index au fil des commits.

La troisième zone : déjà réglée nativement

Reste la dernière cible, les définitions d'outils. Chaque serveur MCP injecte normalement la description de tous ses outils en tête de contexte, ce qui peut représenter plusieurs milliers de tokens consommés avant votre première question. Il a existé des proxys communautaires pour n'exposer que quelques méta-outils à la place, en promettant des −97 % sur cette zone.

Sauf que Claude Code a depuis intégré la solution nativement : le Tool Search charge les définitions d'outils à la demande plutôt que toutes au démarrage. Je l'ai constaté en mesurant le /context du benchmark précédent : des serveurs MCP entiers y apparaissent à "0 token" : leurs schémas ne sont plus injectés au démarrage. Ne restent chargés que les noms d'outils, regroupés dans une ligne "MCP tools (deferred)" d'une centaine de tokens en tout, les schémas complets n'arrivant que lorsque Claude va chercher l'outil pour s'en servir. Autrement dit, le problème que ces proxys attaquaient est aujourd'hui résolu par défaut, sans rien installer. Vérifiez votre /context avant d'ajouter une couche en plus pour un gain que vous avez probablement déjà.

Récap : un plugin, une zone

Plugin	Zone	Mécanisme	Quand l'activer
caveman	Output	Output style concis	Tâches verbeuses, pas en onboarding
Context Mode	Contexte accumulé	Sandbox + index SQLite	Sessions longues avec grosses sorties (coût de présence négligeable)
RTK	Sorties CLI	Hook `PreToolUse` qui réécrit la commande	Beaucoup de `gh`/`curl`/`pytest` verbeux
Codebase Memory	Exploration du code	Graphe de connaissances (MCP)	Gros dépôts, questions structurelles
(défs d'outils)	Définitions d'outils	Tool Search natif	Déjà géré par Claude Code, sans plugin

Comme chacun attaque une zone différente, on peut en combiner plusieurs. Mais combiner n'est pas additionner : un plugin ne rapporte que si votre usage déclenche vraiment son mécanisme. Empiler quatre outils sur une session qui ne produit ni grosse sortie ni exploration de code, c'est de la configuration pour rien.

Ce qu'il faut retenir

Un chiffre de README est un pic, pas une moyenne. Il est souvent juste, mais mesuré dans les conditions les plus favorables. caveman annonce 65 % sur l'output isolé ; ramené à une session, il tourne à 14 à 21 %.
Activez un plugin pour le cas qu'il vise, pas par défaut. Context Mode brille sur les sessions longues et verbeuses, et ne sert à rien sur une session légère. La bonne nouvelle, mesurée : son coût de simple présence est négligeable, parce que Claude Code charge les définitions d'outils MCP à la demande (Tool Search natif) plutôt que toutes au démarrage. Le risque n'est donc pas l'overhead, c'est d'empiler dix plugins en croyant additionner dix gains, alors que la plupart ne se déclencheront jamais sur votre usage réel.
Choisissez selon votre profil. Solo Pro : un output style concis plus /clear et /compact (−40 à −60 %). Solo Max : ajoutez Context Mode et RTK si vos sessions sont longues et verbeuses (−60 à −75 %). Equipe MCP-heavy : la même stack, en laissant Tool Search natif gérer les définitions d'outils.
Mesurez votre baseline avant d'empiler. Le meilleur plugin de réduction de tokens, c'est souvent le compteur que vous gardez sous les yeux.