tokensave : ce que couvrent vraiment leurs 88 %

Qu'est-ce que tokensave, et lequel avez-vous trouvé ?

tokensave est un serveur MCP en Rust qui indexe votre code dans un graphe de connaissances sémantique local, pour qu'un agent interroge des symboles au lieu de lire des fichiers entiers. Au moins trois projets sans lien portent ce nom, et un seul est celui-ci. Commençons par là, parce que les résultats de recherche ne les séparent pas et qu'installer le mauvais coûte un après-midi :

aovestdipaperino/tokensave — celui dont parle cette page. Rust, MIT, 618 étoiles, 62 forks, créé le 26 février 2026, dernier push le 3 septembre 2026, version courante v7.11.0 (30 août 2026). Son site est tokensave.dev.
choosenobody/TokenSave — un outil complètement différent : « un auditeur local des tâches d'agent récurrentes », qui cherche le gaspillage dans les crons et les boucles d'agents. 0 étoile. Son site est tokensave.cloud.
Snowy-Girl-Labs/tokensave-public — un miroir reprenant la même description en une ligne que le premier. 0 étoile.

Il existe aussi token-saver.ai, un produit distinct au nom quasi identique, qui filtre les sorties de commandes au lieu d'indexer du code. Si vous arrivez d'un résultat de recherche et que la chose installée audite des crons, vous avez trouvé le deuxième. Dans la suite de cette page, tokensave désigne le serveur MCP Rust à 618 étoiles.

Que fait réellement tokensave ?

Il analyse votre dépôt avec tree-sitter vers un graphe libSQL doté d'une recherche FTS5, puis expose ce graphe à votre agent sous forme d'outils MCP : une question sur le code reçoit une réponse par requête plutôt que par lecture de fichiers. L'argument derrière tous les outils de cette catégorie est le même, et il est bon : un agent à qui l'on demande « où est gérée l'authentification » va sinon grepper, ouvrir six fichiers, et vous facturer les six en tokens d'entrée. Un index répond avec les trois fonctions qui comptent. Là où tokensave se distingue, c'est l'étendue. Le README annonce 80+ outils MCP, 50+ langages répartis en trois niveaux (lite / medium / full, choisis à la compilation pour contrôler la taille du binaire) et 12+ intégrations d'agents, en citant Claude Code, Codex CLI, Gemini CLI, Cursor, OpenCode, Cline, Zed, Kilo et une douzaine d'autres. L'installation passe par brew, scoop, cargo ou cargo binstall. Deux capacités sont réellement rares et méritent d'être nommées :

L'indexation multi-branches. Suivez une branche et il copie la base de l'ancêtre le plus proche, en ne synchronisant que les fichiers différents : vous pouvez donc diff et chercher entre branches sans changer de checkout. Rien d'autre dans cette catégorie ne le fait.
Les primitives d'édition atomique avec réécriture AST. Les modifications passent par l'arbre syntaxique plutôt que par regex et échappement shell, ce qui supprime toute une classe de pannes.

Que couvrent vraiment les 88 % annoncés par tokensave ?

C'est leur chiffre, portant sur la récupération face à une lecture de fichiers entiers, mesuré par eux sur leur propre dépôt. À lire comme une affirmation sur une étape, pas comme une économie sur votre facture. Un mot sur la façon dont cette page traite tout chiffre d'éditeur, celui de tokensave compris. Dans cette catégorie, le pourcentage annoncé est presque toujours arithmétiquement vrai et rhétoriquement surdimensionné : il est mesuré sur la tranche étroite que l'outil touche, puis présenté comme s'il s'appliquait à l'ensemble du travail. L'outil intercepte 12 % de votre trafic, économise 80 % de cette tranche, et le titre annonce 80 %. Personne n'a menti. La conclusion que le lecteur en tire est fausse d'un ordre de grandeur. Aucun chiffre auto-déclaré n'est donc repris ici comme un fait, et aucun n'est jamais placé dans la même colonne qu'une mesure contrôlée. Ceci posé, voici ce que tokensave rapporte. tokensave bench passe un jeu fixe de 10 requêtes par l'outil tokensave_context et compare les tokens retournés à ce qu'aurait coûté la lecture intégrale des fichiers. Sur leur propre dépôt, avec le jeu de requêtes générique fourni, ils annoncent 88 % de gains moyens de récupération — 142,8k tokens ramenés à 5,5k sur 10 requêtes, avec des estimations en dollars au tarif d'entrée Sonnet, et décrivent une méthodologie reprenant celle de CCE. Fournir tokensave bench sous forme de commande vaut mieux que publier un pourcentage nu, et il faut le dire : vous pouvez rejouer leur jeu de requêtes au lieu de les croire sur parole. C'est un point sur la reproductibilité, pas sur la taille du nombre. Parce que le titre, lui, généralise toujours. Trois choses qu'il ne couvre pas, et chacune le déplace :

Il mesure la récupération, pas une session. La comparaison est « interroger l'index » contre « lire les fichiers entiers ». Une vraie session d'agent renvoie aussi l'historique de conversation, lance des commandes, lit leurs sorties et relit des fichiers qu'elle possède déjà. La récupération est une ligne de cette facture.
Il est auto-mesuré sur son propre dépôt. Un code Rust, avec un jeu de requêtes calibré sur « des motifs présents dans la plupart des codebases applicatives ». Le README le dit nettement et vous invite à le lancer chez vous, ce qui est la formulation honnête. Mais un auto-benchmark n'est pas un benchmark indépendant.
Il n'a pas de bras de contrôle. Il se compare à un pire cas hypothétique (lire chaque fichier en entier), pas au même agent faisant la même tâche sans l'outil. C'est la différence entre « un index renvoie moins de texte qu'un fichier » — de l'arithmétique, et c'est vrai — et « l'installer a rendu mes sessions moins chères », qui est une expérience.

Que vous coûtent 80+ outils ?

Chaque définition d'outil MCP occupe la fenêtre de contexte à chaque tour, y compris les tours qui ne touchent jamais l'index. C'est la partie qu'un décompte de fonctionnalités inverse. Une liste d'outils se lit comme de la capacité, et chaque entrée est aussi un coût d'entrée fixe payé à chaque tour, pour toute la durée de la session. Quatre-vingts définitions, c'est un abonnement plus lourd que quarante, et il est facturé que l'agent interroge le graphe ou non. Que l'échange soit gagnant dépend de la forme de vos sessions. Sur des sessions longues et dominées par la navigation de code, les gains de récupération écrasent le manifeste. Sur des sessions courtes, ou passées à lancer des tests et lire des logs, vous payez le manifeste d'un graphe que vous n'interrogez jamais. Il n'y a pas de réponse universelle, et c'est précisément pourquoi ce calcul mérite d'être visible plutôt que caché derrière un plus grand nombre. En pratique : gardez le serveur connecté pour le travail d'exploration et déconnecté pour le reste, plutôt que de le laisser actif par défaut parce qu'il l'était hier.

Pour qui est-il fait, et pour qui ne l'est-il pas ?

Prenez-le si votre agent dépense ses tokens à naviguer dans une grande codebase multi-langage. Passez votre chemin si vos tokens partent en sorties de commandes et en relectures. Allez-y quand : le dépôt est gros, plusieurs langages cohabitent, vous travaillez entre branches, et vos sessions sont assez longues pour amortir le manifeste d'outils. L'étendue des langages et l'indexation multi-branches sont de vrais avantages, et rien d'autre dans la catégorie n'offre les deux. Cherchez ailleurs quand : votre facture est dominée par des sorties de commandes non filtrées, par les mêmes fichiers relus dans une même session, ou par un contexte jamais élagué. Un index ne touche à rien de tout cela. tokensave ne fait ni filtrage de sorties, ni déduplication de relectures, ni compression skeleton — et ne prétend pas le faire. C'est le partage honnête, et c'est pourquoi ces outils ne sont pas substituables. Pour voir la catégorie côte à côte, alternatives à tokensave en compare cinq, et tokensave contre codegraph prend le duel le plus proche isolément.

Comment appliquer ça dès aujourd'hui

Vérifiez que vous avez le bon projet. github.com/aovestdipaperino/tokensave, 618 étoiles, Rust. S'il audite des crons, c'est un autre outil.
Lancez tokensave bench sur votre dépôt, pas sur le leur. Le jeu fourni est générique ; --queries my.toml le rend vôtre.
Lisez le chiffre comme de la récupération, pas comme de la dépense. Il dit ce que gagne une requête face à une lecture. Il ne dit pas ce que coûte votre mois.
Mesurez le manifeste. Notez vos tokens d'entrée par tour, serveur connecté puis déconnecté. Cet écart, c'est ce que coûtent les 80+ outils.
Décidez par session, pas par machine. Connecté pour la navigation, déconnecté pour les boucles tests-et-logs.

Ce qui cloche en pratique (anti-patterns)

Lire les 88 % annoncés comme une baisse de facture. C'est leur chiffre de récupération face à des lectures de fichiers entiers. C'est la façon la plus courante de transformer un outil correct en promesse trahie, et ça vaut pour tous les pourcentages d'éditeurs de cette catégorie, pas seulement celui-ci : demandez quelle part de votre trafic l'outil touche seulement, avant d'appliquer son pourcentage à quoi que ce soit. Compter les outils comme des fonctionnalités. Quatre-vingts définitions, ce sont quatre-vingts entrées de contexte à chaque tour. Le décompte est autant un coût qu'une capacité, et la convention marketing qui le met en avant masque exactement cela. Laisser le serveur connecté par habitude. Le manifeste est facturé sur les sessions qui n'interrogent jamais l'index, et ce sont généralement les plus nombreuses. Croire qu'un index règle les relectures. Non. Si les mêmes quatre fichiers entrent onze fois dans votre contexte au cours d'une session, c'est un autre problème avec un autre remède — voir comment mesurer l'usage des tokens d'un agent pour l'attraper.

À lire aussi :

Alternatives à tokensave — cinq outils comparés sur l'effet de coût mesuré
tokensave contre codegraph — le duel le plus proche de la catégorie
Meilleurs optimiseurs de tokens pour Claude Code — le champ complet