codegraph vs ccusage : l'outil et l'instrument

Fait partie du pilier réduire l'usage des tokens dans Claude Code. Cette page associe un outil qui agit et l'outil qui dit si l'action a marché.

codegraph ou ccusage : de quoi ai-je besoin ?

Des deux, dans cet ordre d'importance et dans l'ordre inverse d'installation. ccusage mesure et ne change rien. codegraph indexe votre code et change la façon dont l'agent travaille. On installe le compteur d'abord parce que codegraph fait une affirmation précise et vérifiable, et que la vérifier vaut mieux que la croire. Cette affirmation, c'est −35 % de coût et −71 % d'appels d'outils, en médiane sur sept dépôts. C'est le chiffre publié le plus fort de la catégorie. C'est aussi une médiane d'éditeur sur un échantillon, avec une variance visible d'un run à l'autre — le rapport de codegraph lui-même montre un écart sur quatre exécutions sur Tokio. Sur mon benchmark ouvert de sessions longues, codegraph termine à peu près à l'équilibre côté coût. Je maintiens ce benchmark et je vends un outil concurrent : l'utile ici n'est ni mon chiffre ni le leur. C'est le vôtre.

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, et 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 : les limites d'Anthropic roulent sur une fenêtre de cinq heures, et ccusage montre où vous en êtes dedans plutôt qu'après. Ses limites sont annoncées sans détour. Il est en lecture seule et ne réduit rien, et il n'a aucun contrefactuel — pas de vue « ce que j'aurais dépensé sans l'outil X ». Le schéma JSONL qu'il lit est implicite plutôt que spécifié : il rapporte ce que les agents écrivent, tel qu'ils l'écrivent.

Que fait codegraph exactement ?

Il remplace la chasse aux fichiers par une requête. tree-sitter parse vos sources vers un graphe de connaissances SQLite FTS5 servi en MCP, sur plus de vingt langages et quatorze frameworks : analyse d'impact, graphe d'appels, recherche de symboles. L'agent demande où une fonction est utilisée au lieu d'ouvrir quatre fichiers pour le découvrir. C'est l'installation la plus simple de la catégorie. Un runtime Node.js embarqué supprime la gestion de versions, et un installeur interactif détecte huit agents et écrit lui-même leur configuration MCP. Le file watcher débouncé affiche une bannière d'obsolescence quand des fichiers attendent d'être réindexés, pour que l'agent sache quand sa réponse peut être en retard sur l'arbre de travail. Ses manques : pas de filtrage de sorties, donc les sorties shell bavardes arrivent en taille réelle ; recherche par mots-clés FTS5 seulement, sans recherche sémantique ; aucun report des manifestes MCP — et codegraph en ajoute un ; aucune compression des fichiers que l'agent ouvre pour éditer.

Comment vérifier réellement le −71 % ?

Comptez les appels d'outils, pas les tokens, sur du travail comparable. Les appels d'outils sont la bonne métrique parce que c'est ce qu'un index change mécaniquement. Le coût est en aval : il dépend de ce que l'agent fait de la navigation dont il n'a plus besoin, d'où la forte variance d'un run à l'autre sur un même dépôt. Une procédure qui marche :

Une semaine sans codegraph. Notez la dépense quotidienne et, si votre agent l'expose, le nombre d'appels d'outils.
Installez codegraph et indexez le dépôt. Ne changez rien d'autre cette semaine-là — ni de modèle, ni vos autres serveurs MCP, ni vos habitudes de prompt.
Une semaine avec. Comparez à charge comparable.
Lisez la répartition, pas seulement le total. Si les appels d'outils ont baissé et pas le coût, l'index fonctionne et votre dépense est ailleurs.

Ce dernier cas est le plus fréquent, et il est informatif plutôt que décevant. Il vous dit que vos tokens sont dans les sorties de commandes, dans les fichiers que l'agent ouvre pour éditer, ou dans l'historique de conversation — trois canaux qu'un index ne touche pas.

Que voit le compteur qu'aucun optimiseur ne rapporte ?

Les tokens de cache, et la répartition par modèle. Les deux sont dans ccusage et n'apparaissent dans le reporting d'aucun optimiseur, codegraph compris. Les tokens de cache comptent parce que l'entrée en cache est facturée une fraction de l'entrée fraîche chez tous les grands fournisseurs, ce qui fait du taux de hit le plus gros levier d'une session longue. Un outil qui le fait baisser en silence peut vous coûter plus qu'il n'économise en volume brut, et vous ne le verriez jamais dans un compteur de « tokens économisés ». Un index comme codegraph ne touche pas au préfixe du prompt, il est donc sûr sur cet axe — mais c'est une propriété à confirmer plutôt qu'à supposer, et la confirmer demande le compteur. La répartition par modèle compte pour une autre raison. Si un modèle se vide bien plus vite que les autres, le correctif le moins cher est le routage, pas l'optimisation : envoyez le travail bon marché au modèle bon marché. Cette décision ne coûte rien à mettre en œuvre et reste invisible sans répartition. Il y a une troisième chose que le compteur donne et qu'aucun benchmark ne peut fournir : votre propre variance de référence. Deux semaines de travail ordinaire coûtent rarement pareil. Savoir de combien votre dépense bouge toute seule vous dit à partir de quelle taille un effet peut être revendiqué — et c'est en général plus grand qu'on ne le croit, ce qui explique pourquoi les comparaisons sur une seule session produisent des absurdités assurées.

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. 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, et c'est de loin la façon la plus courante de gâcher une semaine de mesure.

Lequel choisir ?

Installez ccusage dans tous les cas. Gratuit, sans installation, en lecture seule. Il n'existe aucun scénario où connaître le chiffre vous dessert, et toute autre décision de cette page en dépend. Installez codegraph si l'agent passe son temps à chercher des choses dans un gros dépôt, ou si vous voulez l'installation la moins friction à mettre devant une équipe. Puis vérifiez-le, plutôt que de faire confiance à la médiane. N'installez pas codegraph en espérant qu'il aide une boucle build-et-tests. Il n'est pas du tout sur ce chemin, et aucune indexation n'y changera rien.

Comment appliquer ça aujourd'hui

Lancez npx ccusage@latest maintenant. Quelques secondes, rien à installer, il lit des transcriptions que vous avez déjà.
Notez votre base de référence : ratio entrée/sortie, taux de hit de cache, répartition par modèle, total quotidien.
Changez une seule chose. Puis relisez le compteur une semaine plus tard, pas une tâche plus tard.
Jugez l'index sur les appels d'outils. C'est ce qu'il déplace ; le coût est un effet en aval, avec plus de variance qu'on ne le croit.

Ce qui tourne mal (anti-patterns)

Installer l'optimiseur avant le compteur. Vous obtenez alors une opinion au lieu d'un résultat. Lire une médiane d'éditeur comme votre résultat. −35 % est un chiffre de bonne foi sur sept dépôts. Le vôtre en fait un. Changer deux choses la même semaine. La méthode la plus fiable pour ne rien apprendre. Prendre ccusage pour un optimiseur. Il n'économise rien du tout. Toute sa valeur est dans ce que vous faites du chiffre.

À lire aussi :