Fait partie du pilier réduire l'usage des tokens dans Claude Code. L'un de ces outils n'a aucun chiffre publié, et l'autre est le moyen d'en obtenir.
À lire aussi :
ccusage ou tokensave : de quoi ai-je besoin ?
ccusage d'abord, et dans le cas de tokensave ce n'est pas le conseil habituel — c'est la seule façon de l'évaluer. tokensave ne publie aucun benchmark. Ni faible, ni flatteur : aucun. Son README décrit 34 langages, 48 outils MCP et l'indexation multi-branches, et ne dit rien de ce que tout cela économise. Ce n'est pas rare dans cette catégorie et ce n'est pas un reproche. Mais cela signifie que le seul chiffre qui existera jamais pour tokensave sur votre dépôt est celui que vous produirez, et ccusage est l'instrument pour le produire. Je maintiens un benchmark ouvert de sessions longues et je vends un outil concurrent. tokensave n'y est pas passé non plus : je n'ai donc aucun chiffre à vous offrir ici — seulement une méthode.Que fait ccusage exactement ?
Il lit les transcriptions JSONL locales de votre agent et rapporte ce que vous avez dépensé. Environ 15k étoiles, 15 sources d'agents supportées, zéro installation —bunx ccusage ou npx ccusage@latest. Rapports quotidiens, hebdomadaires, mensuels et par session, répartition par modèle, suivi des tokens de cache, sortie JSON composable avec d'autres tableaux de bord.
Pour les abonnés Claude Pro et Max, le point fort est la vue par bloc de facturation de 5 heures, calée sur la fenêtre glissante d'Anthropic.
Il est en lecture seule et ne réduit rien, et n'offre aucun contrefactuel — dépense observée seulement. Le schéma JSONL qu'il lit est implicite plutôt que spécifié.
Que fait tokensave exactement ?
Il construit un index de symboles et le sert en MCP. Un serveur Rust avec un graphe de connaissances sémantique en libSQL et FTS5, bâti par extraction tree-sitter sur 34 langages, exposant 48 outils MCP. Ses parties distinctives :- Compilé. Démarrage rapide, mémoire faible, aucun runtime. Homebrew sur macOS, Scoop sur Windows, binaires précompilés ailleurs.
- Indexation multi-branches — comparer et chercher entre branches sans changer de checkout, ce que rien d'autre ici ne fait.
- Isolation par sous-processus, pour qu'un parseur qui plante sur un fichier malformé n'emporte pas le service.
- Primitives d'édition atomiques avec réécriture AST, pour que l'agent renomme via l'arbre plutôt que via une regex.
Comment produire le chiffre manquant ?
Faites un A/B sur deux semaines de travail comparable, et lisez les appels d'outils avant le coût.- Semaine un, sans tokensave. Notez la dépense quotidienne dans ccusage, et le nombre d'appels d'outils si votre agent l'expose.
- Semaine deux, tokensave installé et le dépôt indexé. Ne changez rien d'autre — ni de modèle, ni vos autres serveurs MCP, ni vos habitudes de prompt.
- Comparez d'abord les appels d'outils. C'est ce qu'un index change mécaniquement, et cela bouge avant le coût.
- Puis comparez le coût, en connaissant votre variance. Deux semaines ordinaires coûtent rarement pareil. Si votre écart d'une semaine à l'autre est de 20 %, une différence de 15 % n'est pas un résultat.
Le coût que tokensave ajoute, et que ccusage vous montrera
48 outils MCP font un gros manifeste, facturé à chaque tour. Les définitions d'outils sont envoyées en tokens d'entrée avant votre premier message, utilisées ou non. Sur une session qui n'interroge jamais l'index, c'est une perte sèche — et c'est exactement le genre de charge fixe et discrète qu'un compteur d'économies par outil ne ferait jamais apparaître. ccusage, si. Si vos tokens d'entrée montent les jours où vous n'avez fait que du terminal, c'est le manifeste, et le correctif est de déconnecter le serveur sur ces sessions plutôt que d'accuser l'index. C'est la raison concrète d'associer ces deux-là plutôt que de traiter le compteur comme optionnel.Que le compteur ne peut-il pas dire ?
Le pourquoi. ccusage rapporte qu'une session a coûté plus que d'habitude. Il ne dira pas que onze de vos vingt derniers appels d'outils ont relu les quatre mêmes fichiers, ni qu'un index périmé a envoyé l'agent sur une fausse piste, ni lequel de vos serveurs connectés porte le poids du manifeste. Il ne peut pas non plus isoler une variable que vous n'avez pas isolée. Deux changements la même semaine produisent un résultat ininterprétable.Lequel choisir ?
Installez ccusage dans tous les cas. Gratuit, sans installation, en lecture seule, et avec tokensave en particulier ce n'est pas optionnel : c'est la seule source de preuve. Installez tokensave si vous travaillez sur de nombreux langages, relisez souvent des branches, ou voulez le chemin d'édition plus sûr qu'offre la réécriture AST. Puis mesurez-le, parce que personne ne l'a fait. N'installez pas tokensave en espérant qu'il aide une boucle build-et-tests. Il n'est pas sur ce chemin, et son manifeste vous coûtera précisément sur ces sessions-là.Comment appliquer ça aujourd'hui
- Lancez
npx ccusage@latestmaintenant et notez quatre semaines de totaux avant de changer quoi que ce soit. C'est votre base de variance. - Comptez les appels d'outils, pas les tokens, pour juger l'index.
- Surveillez les tokens d'entrée les jours purement terminal. Un gros manifeste se voit là et nulle part ailleurs.
- Déconnectez ce que vous n'interrogez pas. De l'argent gratuit, et le compteur est ce qui vous fait remarquer qu'il était disponible.
Ce qui tourne mal (anti-patterns)
Juger un outil non benchmarké sur sa liste de fonctionnalités. 34 langages et 48 outils sont des faits sur les capacités, pas sur les économies. Comparer une session à une session. Votre variance d'une semaine à l'autre est en général plus grande que l'effet recherché. Laisser un manifeste de 48 outils connecté par habitude. Facturé à chaque tour, y compris ceux qui n'y touchent jamais. Prendre ccusage pour un optimiseur. Il n'économise rien. Toute sa valeur est dans ce que vous faites du chiffre.À lire aussi :
- Réduire l'usage des tokens dans Claude Code — le pilier, indépendant de l'outil
- tokensave vs codegraph — tokensave face à un index benchmarké
- rtk vs ccusage — ccusage face à un outil qui a son propre compteur
- Heures de reset des limites Claude — le bloc de cinq heures que rapporte ccusage
- Benchmark des optimiseurs de tokens — comment la mesure ouverte est conduite
Classé n°1 au Token-Harness Optimizer Leaderboard.
Tokenade est classé n°1 au Token-Harness Optimizer Leaderboard — un benchmark de bout en bout des optimiseurs de tokens, mesuré sur de vraies sessions de code. Installez-le une fois, il agit sur chaque prompt. Compatible avec Claude Code, Cursor, Codex, Copilot et plus.























