ccusage vs tokensave : mesurer ou indexer ?

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.

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 publie bien un chiffre, et ce n'est pas celui qui répond à cette question. tokensave bench annonce 88 % de gains moyens de récupération face à la lecture de fichiers entiers, mesurés sur le dépôt de tokensave lui-même avec un jeu de requêtes générique. C'est reproductible, et c'est plus que ce qu'offrent la plupart des outils ici. Ce n'est pas non plus ce que coûte une session sur votre dépôt.

Cet écart n'est pas un reproche, c'est une différence sur ce qui a été mesuré. Mais cela signifie que le chiffre qui décide si tokensave se rentabilise sur votre travail 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 50+ langages, exposant 80+ 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.

Manques : pas de filtrage de sorties, navigation seule sans recherche vectorielle sémantique, détection de frameworks limitée à quatorze frameworks codés en dur — et aucune économie publiée.

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.

1. Semaine un, sans tokensave. Notez la dépense quotidienne dans ccusage, et le nombre d'appels d'outils si votre agent l'expose.
2. 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.
3. Comparez d'abord les appels d'outils. C'est ce qu'un index change mécaniquement, et cela bouge avant le coût.
4. 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.

C'est l'étape quatre qu'on saute, et c'est pourquoi les comparaisons sur une seule session produisent des absurdités assurées dans cette catégorie. ccusage vous donne la variance gratuitement : regardez quatre semaines normales avant d'attribuer quoi que ce soit à un outil.

Le coût que tokensave ajoute, et que ccusage vous montrera

80+ 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

1. Lancez npx ccusage@latest maintenant et notez quatre semaines de totaux avant de changer quoi que ce soit. C'est votre base de variance.
2. Comptez les appels d'outils, pas les tokens, pour juger l'index.
3. Surveillez les tokens d'entrée les jours purement terminal. Un gros manifeste se voit là et nulle part ailleurs.
4. 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 sur sa liste de fonctionnalités. 50+ langages et 80+ 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 80+ 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