Économiser des tokens : le compteur dit 45 %, la facture 2 %

Une phrase résume tout le problème, et elle vient du benchmark de l’outil lui-même : « rtk’s scoreboard said 96 million tokens saved while the invoice went up. » Le compteur de rtk annonçait 96 millions de tokens économisés ; la facture, elle, montait. C’est écrit dans le billet JetBrains qui compare les outils d’économie de tokens.

Mon déclencheur, à moi : un post LinkedIn vendait une « méthode d’économie de tokens » derrière un paywall, sommaire flouté, lien en commentaire. Je n’ai jamais acheté, jamais lu. C’est le point : on peut démonter le claim avec sa propre facture, sans payer pour la méthode. Attaquer la mesure, pas la personne.

Le chiffre que personne ne regarde

ccusage monthly, fenêtre juillet 2026 + 1→4 août : 2,18 milliards de tokens, $1 703,64.

Ce que ça coûte

Prix relevés le 4 août 2026

Cache read 2 118 939 430 tokens

96,99 %

Cache write 58 188 826 tokens

2,66 %

Output 7 409 081 tokens

0,34 %

Input frais 123 360 tokens

0,006 %

Total $1 703,64 (35 jours)

cache_read / cache_write = 36,4. Chaque token écrit en contexte est relu ~36 fois. C’est le seul chiffre à retenir, et il transforme la question « comment envoyer moins de texte » en « comment arrêter d’écrire dans un contexte que je vais relire 36 fois ».

Corollaire qui tue le marketing : l’output brut pèse 0,34 % des tokens. Tout outil qui fait « écrire moins » à l’agent joue sur une part minuscule. Relevé refait le 12/08 : ratio ~36×, cache read ~97 %, stable.

Annoncé vs mesuré

Série de tests appairés JetBrains (harness Harbor / SkillsBench, protocole et budget publiés), la seule source qui compare les deux côtés :

Outil	Annoncé	Mesuré indépendamment
rtk	−60 à −90 %	+7,6 % de coût (p=0,004, effort bas)
caveman	−65 %	−8,5 %
ponytail	−54 % code / −20 % coût	−15,4 % code / −10,3 % coût (p=0,004)
headroom	−60 à −95 %	compression réelle, facture en hausse

Fourchette à retenir : toutes les économies réellement reproduites par des tiers tombent entre 0 et 15 %. Jamais 60-90 %.

Le cas rtk, mesuré chez moi

Le compteur, relevé le 12/08 : 4,4 M de tokens « économisés », 45,3 %, sur 9 892 commandes cumulées. Hook posé début avril 2026, environ quatre mois. Au prorata de la fenêtre de 35 jours de la facture : ~1,17 M de tokens, contre 58,19 M de cache write. Réduction réelle du contexte écrit : ~2 %, pas les 45 % affichés.

$ rtk gain
Total commands:    9892
Tokens saved:      4.4M (45.3%)

Les trois causes, qui sont le vrai contenu technique :

1. Le hook ne se déclenche que sur les commandes shell. Read, Grep, Glob, une bonne part des résultats d’outils, passent à côté.
2. Claude Code tronque déjà les gros fichiers. L’outil compte comme économisé ce qui n’aurait jamais transité.
3. Les retries. Un rewrite cassé ajoute un tour, et un tour relit tout le contexte au facteur 36×.

Bonus : la dégradation est silencieuse. L’agent ignore qu’on a compressé ; j’ai déjà eu une sortie Playwright tronquée qui a produit un échec E2E indébuggable.

Le levier que personne ne vend

Mon contexte permanent, les fichiers d’instructions chargés à chaque requête : 7 381 tokens (mesuré le 04/08). Sur une session de 36 tours : ~266 000 tokens de cache read, soit ~12 % de mon volume mensuel, pour des fichiers qui décrivent des règles.

Et le plus gros poste (2 784 tokens) était un MEMORY.md rempli de tables d’inventaire d’agents, de skills et de hooks : de la documentation d’état, dérivable du disque, déjà périmée (il annonçait 151 skills et en listait 16). Payée 36 fois par session.

L’anecdote qui porte l’article : j’ai trouvé plus d’économies en supprimant ma propre documentation qu’en installant quatre outils de compression.

Classement des leviers par ROI :

1. Contexte permanent (CLAUDE.md, rules, mémoire) : payé à chaque tour
2. Définitions d’outils MCP : injectées dans chaque requête ; le chargement différé natif fait le job, inutile d’empiler une couche tierce
3. Discipline de session : /clear entre tâches sans rapport, scope étroit, subagents pour l’exploration jetable ; c’est là que le 36× se joue, et aucun outil ne le fera à ta place
4. Output : 0,34 % des tokens, le terrain de ponytail
5. Sortie shell : le terrain de rtk, ~2 %

Le protocole, si tu veux mesurer le tien

1. Baseline ccusage monthly --json sur deux semaines : note totalCost et le ratio cacheRead/cacheCreation.
2. Un seul changement à la fois. Deux couches en même temps = résultat ininterprétable.
3. Mesure la facture, pas les tokens. Et le taux de réussite : −80 % de tokens avec +50 % d’erreurs est une perte nette.
4. Fenêtres appairées, même type de travail. Les effets réels sont de l’ordre de 10 %, la variance de charge les noie sinon.

L’intuition de l’écosystème est juste : le facteur 36× prouve que compresser le contexte est le levier à plus fort effet de levier qui existe. C’est leur mesure qui est fausse, et aucun des quatre ne touche la partie du contexte qui compte. La bonne nouvelle, c’est que le levier n’a pas besoin d’un outil : il s’appelle supprimer sa propre documentation, et fermer ses sessions. Le reste, mon guide sur les coûts le détaille.