tokensave vs graphify : toujours actif, ou sur demande ?

Fait partie du pilier réduire l'usage des tokens dans Claude Code. Les deux construisent un graphe de votre projet ; ils diffèrent surtout par ce qu'ils coûtent quand il ne se passe rien.

tokensave ou graphify : lequel choisir ?

tokensave si l'agent doit aller à l'index sans qu'on le lui dise ; graphify si vous préférez ne rien payer sur les sessions qui n'en ont pas besoin. tokensave tourne comme serveur MCP exposant 48 outils. Ils sont dans la boîte à outils de l'agent dès le premier message, ce qui explique qu'il s'en serve spontanément — et que leurs définitions soient facturées en tokens d'entrée à chaque tour, y compris ceux qui n'interrogent jamais l'index. graphify s'invoque par /graphify. Coût permanent nul, et bénéfice nul tant que rien dans la session ne va le chercher. Aucun des deux n'affiche d'économie de coût de session mesurable sur mon benchmark ouvert de sessions longues — tokensave n'y a pas été mesuré du tout et ne publie aucun benchmark. Je maintiens ce benchmark et je vends un outil concurrent : lisez le mécanisme.

Que fait tokensave exactement ?

Un serveur MCP en Rust au-dessus d'un index de symboles. Un graphe de connaissances sémantique en libSQL avec FTS5, bâti par extraction tree-sitter sur 34 langages, avec 48 outils MCP. Ses forces sont des forces d'ingénierie :

Compilé, donc démarrage rapide, mémoire faible, aucun runtime à installer. 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 dans la catégorie n'offre et qui supprime une classe d'allers-retours git checkout coûteux en contexte.
Isolation par sous-processus, pour qu'un parseur qui plante sur un fichier malformé n'emporte pas le service. Avec 34 grammaires, ça compte.
Primitives d'édition atomiques avec réécriture AST, pour que l'agent renomme via l'arbre plutôt que via une regex.

Ses manques : les sources seulement, aucun filtrage de sorties, pas de recherche vectorielle sémantique, détection de frameworks limitée à quatorze frameworks codés en dur, et aucun chiffre d'économies publié.

Que fait graphify exactement ?

Un graphe de connaissances de tout le projet, derrière une commande slash. Python, licence MIT, depuis PyPI, invoqué par /graphify sur Claude Code, Codex, opencode, Cursor, Copilot, Aider, OpenClaw et d'autres. Son différenciateur est la couverture au-delà du code : documentation, PDF, images et vidéo. Dans les projets où la réponse à « pourquoi est-ce construit ainsi » vit dans un document de conception ou une passation enregistrée, rien d'autre dans la catégorie ne peut l'atteindre. Il produit aussi un artefact persistant et inspectable — graph.json, une vue HTML et un rapport Markdown — donc le graphe est interrogeable plus tard sans relire le dépôt, et un humain peut l'auditer au lieu de lui faire confiance à l'aveugle. Ses coûts : l'indexation est une étape explicite à relancer à mesure que le projet bouge, un graphe périmé induit en erreur en silence plutôt que d'échouer bruyamment, et il exige un runtime Python.

Le coût à vide, et pourquoi il tranche plus qu'il ne devrait

48 définitions d'outils à chaque tour, c'est la plus grosse charge permanente de cette comparaison, et elle est invisible. Les manifestes MCP sont envoyés en tokens d'entrée avant votre premier message. Sur une session de pur travail terminal — une boucle de build, une tâche d'infrastructure — tokensave n'apporte rien et vous facture quand même. Ce n'est pas un défaut : une grande surface d'outils est le produit. Mais c'est une raison de le déconnecter délibérément plutôt que de le laisser connecté par habitude. graphify a le profil inverse. À vide, il coûte zéro. Le risque est l'image miroir : un index que personne n'invoque, c'est la passe d'indexation gaspillée et rien de gagné — et de l'extérieur, cela ressemble exactement à un outil qui ne marche pas. Aucun profil n'est meilleur dans l'absolu. L'ambiant convient au travail où l'on ne peut pas prédire quelles sessions auront besoin de navigation. L'opt-in convient là où on le peut, et où une grande part des sessions n'en a manifestement pas besoin.

Que ne fait ni l'un ni l'autre ?

Les sorties de commandes. cargo test, npm install, une stack trace : les deux les laissent passer en taille réelle.
Les lectures de fichiers entiers pour éditer. Les deux disent quel fichier ; aucun ne réduit le fichier que l'agent ouvre ensuite.
Les relectures. Même fichier, quatre fois, quatre facturations. Les deux en réduisent la probabilité ; aucun ne déduplique.
L'historique de conversation. Aucun ne compresse la fenêtre à mesure qu'elle grossit.

Lequel choisir ?

Prenez tokensave si vous travaillez sur de nombreux langages, relisez souvent des branches, voulez un binaire compilé sans runtime, ou tenez au chemin d'édition plus sûr qu'offre la réécriture AST. Puis déconnectez-le sur les sessions purement terminal. Prenez graphify si documentation, PDF ou enregistrements détiennent des réponses absentes de vos sources, ou si vous voulez un index sans coût par tour. Puis écrivez l'invocation dans les instructions de votre projet pour qu'il serve vraiment. Ne prenez ni l'un ni l'autre pour l'instant si l'essentiel de votre dépense est en sorties de commandes. Aucun n'est sur ce canal, et en installer un ne vous apprendra rien sur votre facture.

Comment appliquer ça aujourd'hui

Regardez vos tokens d'entrée un jour purement terminal. C'est là qu'un gros manifeste se voit, et nulle part ailleurs.
Si vous prenez graphify, écrivez /graphify dans vos instructions d'agent, rattaché aux questions qu'il doit traiter.
Rattachez la réindexation à un événement — un changement de branche, un passage quotidien — plutôt qu'à votre mémoire.
Jugez l'un comme l'autre d'abord sur les appels d'outils. C'est la métrique qu'un index déplace ; le coût suit, avec plus de variance qu'on ne le croit.

Ce qui tourne mal (anti-patterns)

Laisser 48 outils connectés par habitude. Facturés à chaque tour, y compris les nombreux qui ne touchent jamais l'index. Installer un graphe opt-in et ne jamais l'invoquer. Indexation gaspillée, et cela ressemble en tout point à un outil cassé. Faire confiance à un index périmé. Une réponse fausse mais assurée coûte plus cher que pas de réponse, et aucun des deux n'a de bannière d'obsolescence. Juger un outil non benchmarké sur sa liste de fonctionnalités. 34 langages et 48 outils sont des faits de capacité, pas des économies.

À lire aussi :