tokensave vs codegraph : quel index fait vraiment gagner ?

Fait partie du pilier réduire l'usage des tokens dans Claude Code. Cette page est le face-à-face : deux serveurs MCP qui résolvent le même problème presque de la même façon, et qui divergent sur ce qui compte vraiment.

tokensave ou codegraph : quel est le meilleur index de code ?

codegraph si vous voulez un chiffre vérifiable ; tokensave si vous voulez le filet linguistique le plus large et un binaire compilé. Ce sont les deux outils les plus proches de toute cette catégorie — tous deux construisent un index de symboles avec tree-sitter, tous deux le servent en MCP, aucun ne touche à votre shell. Le choix se joue donc sur deux points qu'aucun des deux READMEs ne met en avant : ce que chacun a réellement publié sur ses économies, et la part de votre contexte qu'ils n'allaient de toute façon jamais toucher. Je maintiens un benchmark ouvert des optimiseurs de tokens et je vends un outil concurrent : prenez le classement pour un avis, et le mécanisme pour la chose à vérifier. C'est le mécanisme qui tranche cette comparaison.

Que fait codegraph exactement ?

Il construit un graphe de connaissances de votre code et laisse l'agent l'interroger au lieu de lire des fichiers. tree-sitter parse les sources, les symboles atterrissent dans un index SQLite FTS5, et le serveur MCP expose l'analyse d'impact, le graphe d'appels et la recherche de symboles. Plus de vingt langages, quatorze frameworks, et un file watcher qui garde l'index à jour. Trois choses le distinguent en pratique :

Il embarque son propre runtime Node.js. Pas de version à gérer, pas de virtualenv, multi-plateforme d'emblée. L'installeur détecte huit agents — Claude Code, Cursor, Codex, opencode, Hermes, Gemini, Antigravity, Kiro — et écrit lui-même la configuration MCP.
Le routage par framework couvre un terrain rare, Drupal et Vapor compris, et pas seulement le trio React-Django habituel.
Le watcher est débouncé et honnête sur l'obsolescence. Quand des fichiers attendent d'être réindexés, il l'affiche dans une bannière : l'agent sait que sa réponse peut être en retard sur l'arbre de travail. Petite décision de conception, effet disproportionné — un index périmé silencieux est pire que pas d'index du tout, parce que l'agent lui fait confiance.

Et il publie un benchmark : −35 % de coût et −71 % d'appels d'outils, en médiane sur sept dépôts. C'est la revendication chiffrée la plus forte de toute la catégorie, et c'est le chiffre des appels d'outils qui en est la moitié intéressante.

Que fait tokensave exactement ?

Le même travail, en Rust, sur un éventail de langages plus large. Extraction tree-sitter vers un graphe libSQL avec FTS5, 34 langages, et 48 outils MCP — une surface bien plus grande que celle de codegraph. Là où il prend l'avantage :

Compilé, donc rapide à démarrer et léger. Pas de Python, pas de Node, aucun runtime à installer. Homebrew sur macOS, Scoop sur Windows, binaires précompilés ailleurs.
Indexation multi-branches. Il peut comparer et chercher entre branches sans changer votre checkout. Rien d'autre dans la catégorie ne le fait, et si vous relisez les branches des autres, cela supprime toute une classe d'allers-retours git checkout coûteux en contexte.
Isolation par sous-processus. Un parseur qui plante sur un fichier malformé n'emporte pas le service avec lui — ce qui pèse plus qu'il n'y paraît quand 34 grammaires sont en jeu.
Primitives d'édition atomiques avec réécriture AST. L'agent renomme un symbole via l'arbre plutôt que via une regex, ce qui évite les pièges d'échappement shell et de correspondance partielle qui font échouer les éditions agentiques en silence.

Ce qui lui manque, c'est un chiffre. Aucun benchmark publié, donc des économies non quantifiées. Ce n'est pas un reproche — la plupart des outils de la catégorie n'en ont pas non plus — mais c'est un vrai écart quand l'outil concurrent, lui, en a un.

D'où vient réellement l'économie de tokens ?

Des appels d'outils, pas de la compression. Aucun de ces deux outils ne compresse quoi que ce soit. Ils remplacent un comportement : au lieu de lire quatre fichiers pour trouver où une fonction est utilisée, l'agent interroge l'index et obtient une liste. C'est pourquoi le −71 % d'appels d'outils de codegraph est le chiffre à lire, et son −35 % de coût celui à manier avec précaution. Moins d'appels d'outils est la conséquence mécanique et directe d'avoir un index — vérifiable en une seule session. Le coût est en aval, et dépend de ce que l'agent fait du temps gagné : d'où la variance importante d'un run à l'autre. Les propres chiffres de codegraph montrent un écart sur quatre exécutions sur Tokio. Sur mon benchmark de sessions longues, codegraph n'affiche aucune économie de coût mesurable — les sessions coûtent à peu près ce qu'elles coûtent sans aucun outil. tokensave n'y est pas passé. Ces deux résultats ne disent pas la même chose, et je préfère écrire « non mesuré » plutôt que de laisser entendre un verdict que je n'ai pas gagné. La réconciliation entre −35 % et l'équilibre n'est pas que l'un de nous se trompe. C'est qu'un index de symboles supprime de façon fiable les lectures de navigation, et ne fait de façon tout aussi fiable rien sur les autres canaux — or sur une session longue, les autres canaux, c'est l'essentiel de la facture.

Que ratent-ils tous les deux ?

Tout ce qui n'est pas une lecture de fichier. C'est la limite honnête de toute la catégorie des index de code, et elle est identique pour les deux :

Les sorties de commandes. cargo test, npm install, git diff, une stack trace — tout cela atteint encore le modèle en taille réelle. Ni l'un ni l'autre ne se trouve sur ce chemin.
Les lectures de fichiers entiers qui survivent à l'index. L'agent ouvre toujours les fichiers pour les modifier. Un index dit quel fichier ; il ne réduit pas le fichier.
Les manifestes MCP. Chaque serveur connecté envoie ses définitions d'outils avant votre premier message. Les 48 outils de tokensave sont eux-mêmes un coût d'entrée permanent à chaque tour, payé que vous en appeliez un ou non — c'est le prix de cette surface.
Les relectures. Le même fichier entrant quatre fois en contexte dans une session coûte quatre fois. Un index réduit la probabilité ; il ne déduplique pas.

Si vos sessions sont dominées par le terminal — boucle de build, boucle de tests, boucle d'infra — un index de code optimise le canal qui était déjà le plus petit chez vous. Bon à savoir avant d'attribuer une facture décevante au mauvais outil.

Lequel choisir ?

Prenez codegraph si vous voulez l'installation la moins friction possible, que vous travaillez dans un framework que son routage connaît bien, et que vous préférez un chiffre publié à discuter plutôt qu'une liste de fonctionnalités plus longue. Le runtime embarqué et l'installeur huit-agents en font l'outil le plus facile à mettre devant une équipe. Prenez tokensave si votre stack dépasse la vingtaine de langages, que vous voulez un binaire compilé unique sans runtime, ou que la recherche multi-branches correspond à votre façon réelle de relire du code. Les primitives d'édition atomiques sont un vrai gain de sûreté sur tout agent qui édite via des commandes shell. Ne prenez ni l'un ni l'autre, pour l'instant, si vous n'avez pas regardé où partent vos tokens. Faites tourner ccusage ou le panneau d'usage de votre agent pendant une semaine d'abord. Si l'essentiel de votre dépense est en sorties de commandes, un index n'y changera rien, et vous en aurez conclu quelque chose de faux sur un outil qui fonctionnait correctement. Ils se composent aussi. Rien n'empêche de faire tourner un index de code à côté d'un filtre en limite d'outil : ils interviennent à des endroits différents et aucun ne réécrit ce que l'autre a produit.

Comment appliquer ça aujourd'hui

Comptez vos appels d'outils, pas vos tokens, sur une session. C'est la métrique qu'un index de code déplace réellement, et celle que vous pouvez vérifier vous-même en un après-midi.
Confrontez la couverture langages et frameworks à votre dépôt réel, pas au chiffre d'affiche. Trente-quatre langages ne servent à rien si le vôtre n'est servi que par une grammaire sommaire.
Surveillez l'obsolescence. Les deux indexent ; un seul vous dit quand l'index est en retard. Quel que soit votre choix, sachez comment vous l'apprendriez.
Auditez les canaux que l'index ne couvre pas avant de décider que l'outil vous a déçu.

Ce qui tourne mal (anti-patterns)

Lire −35 % comme une promesse. C'est une médiane sur sept dépôts, avec une variance visible d'un run à l'autre, publiée par l'éditeur. Un chiffre de bonne foi, et un échantillon quand même. Prendre « non benchmarké » pour « ne marche pas ». tokensave n'a pas de chiffre publié. C'est une absence de preuve, pas la preuve d'une absence. Empiler les index. Deux index de symboles sur le même dépôt doublent le coût des manifestes MCP et répondent deux fois à la même question. Choisissez-en un. Laisser l'index connecté sur du travail qui ne l'interroge jamais. Une grande surface d'outils se paie à chaque tour. Si une session est du pur travail terminal, déconnecter est gratuit.

À lire aussi :