tokensave vs token-optimizer : trouver ou réduire ?

Fait partie du pilier réduire l'usage des tokens dans Claude Code. Ces deux-là résolvent des étapes consécutives du même problème, ce qui rend la comparaison inhabituellement nette.

tokensave ou token-optimizer : lequel choisir ?

Ils répondent à deux moitiés différentes : tokensave trouve le fichier, token-optimizer le réduit — et la licence décide si vous pouvez avoir les deux. tokensave est un serveur MCP en Rust au-dessus d'un index de symboles sur 34 langages. token-optimizer remplace un gros fichier par une carte de structure AST : 180K tokens deviennent environ 250. token-optimizer est en PolyForm Noncommercial — gratuit pour un usage personnel ou en petite équipe, licence payante pour l'usage commercial. tokensave est gratuit et ouvert. Si vous êtes en entreprise, réglez cela avant toute autre comparaison. Aucun des deux n'a été mesuré sur mon benchmark ouvert de sessions longues, et tokensave ne publie aucun benchmark. Je maintiens ce benchmark et je vends un outil concurrent : ce qui suit est un mécanisme, pas un classement.

Que fait tokensave exactement ?

Un index de symboles compilé, servi en MCP. Un graphe de connaissances sémantique en libSQL avec FTS5, bâti par extraction tree-sitter sur 34 langages, avec 48 outils MCP.

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 plantage de parseur sur un fichier malformé n'emporte pas le service.
Primitives d'édition atomiques avec réécriture AST, qui évitent les pièges de regex et d'échappement shell faisant échouer les éditions agentiques en silence.

Son manifeste de 48 outils est un coût d'entrée permanent par tour, facturé que l'agent interroge l'index ou non. Autres manques : aucun filtrage de sorties, pas de recherche vectorielle sémantique, quatorze frameworks codés en dur, aucune économie publiée.

Que fait token-optimizer exactement ?

Quatre couches, la carte de structure faisant le gros du travail :

Les cartes de structure AST — 180K tokens vers environ 250, soit 95–99 % de compression sur exactement la charge qui fait le plus mal. Ça marche parce que l'agent a en général besoin de savoir ce qu'il y a dans un fichier plutôt que de le lire.
La compaction intelligente à checkpoints progressifs, qui condense l'état de session à mesure qu'il grossit.
Un score de qualité à 7 signaux, qui guette la dégradation du contexte en cours de session. Presque rien d'autre dans la catégorie ne modélise cela.
Un tableau de bord HTML complet : coûts par tour, mix de modèles, analyse du cache, répartition par sous-agent, détection de dérive.

Il tourne sur Claude Code, OpenCode, OpenClaw et Codex, avec une installation plus lourde hors de Claude Code, une forte dépendance Python locale, et aucune API transparente pour des intégrations tierces.

Deux usages de l'AST, opposés

Les deux parsent votre code en arbre. Puis ils divergent complètement, et il vaut la peine d'être précis sur le comment. tokensave se sert de l'AST pour construire un index — un stockage persistant et interrogeable de symboles et de relations, plus un chemin sûr pour les éditions. L'arbre est une infrastructure : il existe entre les sessions et répond à des questions sur tout le dépôt. token-optimizer se sert de l'AST pour construire une vue — une représentation compressée d'un fichier, produite à la demande et remise au modèle à la place du contenu brut. L'arbre est une transformation, pas un stockage. C'est pourquoi les deux s'enchaînent au lieu de se concurrencer. tokensave ramène douze fichiers candidats à un ; token-optimizer fait que lire celui-là coûte 250 tokens au lieu de 180 000. Aucun ne réalise l'étape de l'autre. C'est aussi pourquoi faire tourner deux index est du gaspillage tandis qu'un index plus une carte de structure ne l'est pas : un seul des deux essaie d'être un stockage.

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

Les sorties de commandes en limite d'outil. tokensave ne les voit jamais ; la compaction de token-optimizer est au niveau session, pas un filtre par commande.
Les manifestes MCP. Aucun ne les diffère, et tokensave en ajoute un gros.
La recherche sémantique. tokensave fait de la recherche par mots-clés FTS5 ; token-optimizer ne cherche pas du tout.
Les relectures. Une carte de structure rend chaque lecture plus petite ; rien ici ne remarque la répétition.

Ce que coûte le manifeste, sous la forme où il arrive vraiment

Une grosse surface MCP est le seul coût de cette comparaison qui se facture quand il ne se passe rien. Les 48 définitions d'outils de tokensave sont envoyées en tokens d'entrée avant votre premier message, à chaque tour, que l'agent interroge l'index ou non. Sur une semaine dominée par le terminal — boucle de build, tâche d'infrastructure, montée de dépendances — c'est une facture pour une capacité que vous n'avez pas utilisée. token-optimizer n'a pas d'équivalent. Sa carte de structure coûte quelque chose quand un fichier est lu, et rien quand il ne l'est pas : c'est le meilleur défaut pour quiconque a des sessions de formes variées. Le correctif côté tokensave n'est pas de l'éviter mais de le déconnecter délibérément sur les sessions qui n'ont manifestement pas besoin de navigation. C'est une habitude plutôt qu'une configuration, et elle est invisible si on ne la cherche pas : la charge apparaît dans vos tokens d'entrée les jours où vous n'avez fait aucune navigation de code, et nulle part ailleurs. Un compteur d'usage est ce qui vous le fait remarquer.

Lequel choisir ?

Réglez la licence en premier s'il s'agit de travail commercial. PolyForm Noncommercial implique une licence payante pour l'usage commercial, et le découvrir après un déploiement d'équipe est l'ordre coûteux. Cela n'a rien à voir avec les tokens et c'est la seule décision irréversible ici. Prenez tokensave si votre stack couvre de nombreux langages, que vous relisez souvent des branches, ou que vous voulez un binaire compilé sans runtime et un chemin d'édition plus sûr. Prenez token-optimizer si vous êtes un individu ou une petite équipe sous Claude Code et que les gros fichiers dominent vos lectures. La carte de structure est le mécanisme unique le plus fort de cette comparaison, et le tableau de bord montre si ça a marché. Prenez les deux si la licence le permet et que vos sessions cherchent autant qu'elles lisent. Cette combinaison s'enchaîne proprement.

Comment appliquer ça aujourd'hui

Réglez la question de licence. Deux minutes.
Trouvez vos plus grosses lectures de fichiers. Si une poignée de gros fichiers domine, la carte de structure est le changement le plus rentable à votre portée.
Comptez les appels d'outils avant et après si vous installez l'index. C'est la métrique qu'il déplace.
Surveillez les tokens d'entrée les jours purement terminal. Un manifeste de 48 outils se voit là et nulle part ailleurs.

Ce qui tourne mal (anti-patterns)

Déployer en entreprise un outil sous licence non commerciale. L'erreur la plus coûteuse de cette page. Laisser un manifeste de 48 outils connecté sur des sessions qui ne l'interrogent jamais. Facturé à chaque tour quand même. Lire 180K vers 250 comme une réduction de facture. Compression honnête sur une charge, à un périmètre plus petit que votre facture. Juger un outil non benchmarké sur sa liste de fonctionnalités. 34 langages est un fait de capacité, pas une économie.

À lire aussi :