rtk vs tokensave : deux binaires Rust, deux canaux

Fait partie du pilier réduire l'usage des tokens dans Claude Code. Cette page oppose les deux outils compilés de la catégorie.

rtk ou tokensave : lequel choisir ?

Celui qui est sur votre plus gros canal — et c'est une question sur vos sessions, pas sur les outils. rtk réduit ce que renvoient vos commandes shell. tokensave donne à l'agent un index de symboles pour qu'il cesse d'ouvrir des fichiers afin de trouver quelque chose. Ils partagent un langage d'implémentation et un mode de distribution, et rien d'autre. Les deux sont gratuits, compilés en Rust sans runtime à installer, et comptent parmi les installations les plus rapides d'ici. Sur mon benchmark ouvert de sessions longues, rtk termine à peu près à l'équilibre ; tokensave n'a pas été mesuré et ne publie aucun benchmark. Je maintiens ce benchmark et je vends un outil concurrent : lisez le mécanisme.

Que fait rtk exactement ?

Il filtre les sorties de commandes en limite de shell. Plus de cent filtres spécifiques par commande — git, cargo, npm, pytest, docker, aws — derrière un hook transparent : vous tapez vos commandes sans changement et rtk compacte ce qui revient. Moins de 10 ms de surcoût au démarrage, aucun coût en tokens pour l'intégration, et un DSL TOML pour vos propres règles. rtk gain rapporte les économies par commande depuis un stockage SQLite. Sur les outils bavards, la réduction est forte et immédiatement visible : environ 90 % sur cargo test, environ 80 % sur les opérations git. Ses limites sont structurelles, pas négligentes. Le hook ne couvre que bash — les outils intégrés Read, Grep et Glob le contournent entièrement, et sur la plupart des agents ce sont eux qui portent l'essentiel des tokens. Pas de recherche, pas de compression structurelle, pas de report MCP, et pas de PowerShell natif sous Windows.

Que fait tokensave exactement ?

Il construit un index de symboles et le sert en MCP. Un graphe de connaissances sémantique en libSQL avec FTS5, bâti par extraction tree-sitter sur 34 langages, exposant 48 outils MCP. Quatre choses le distinguent :

L'indexation multi-branches. Comparer et chercher entre branches sans changer de checkout. Rien d'autre dans la catégorie ne le fait, et cela supprime toute une classe d'allers-retours git checkout coûteux en contexte.
L'isolation par sous-processus. Un parseur qui plante sur un fichier malformé n'emporte pas le service, ce qui compte avec 34 grammaires en jeu.
Les 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.
La distribution. Homebrew sur macOS, Scoop sur Windows, binaires précompilés ailleurs — y compris le support Windows qui manque à rtk.

Ses manques : pas de filtrage de sorties, donc les sorties de commandes arrivent en taille réelle ; navigation seule, sans recherche vectorielle sémantique ni compression structurelle ; détection de frameworks limitée à quatorze frameworks codés en dur ; et aucun chiffre d'économies publié.

Que coûte chacun à faire tourner ?

rtk ne coûte pratiquement rien. Le hook n'ajoute aucun token et le binaire aucune latence mesurable. Son seul coût continu est le risque de sur-filtrage : un filtre qui retire une ligne dont vous aviez besoin renvoie l'agent la chercher. tokensave coûte un manifeste à chaque tour. Les définitions d'outils MCP sont envoyées en tokens d'entrée avant votre premier message, utilisées ou non, et 48 outils font une grosse surface. C'est une charge permanente que son propre reporting ne montre pas, et c'est une raison de le déconnecter sur les sessions de pur travail terminal. Cette asymétrie ne tranche pas la comparaison, mais elle signifie que les deux ne sont pas également gratuits. rtk est gratuit à laisser installé. tokensave est gratuit à utiliser et coûte quelque chose à laisser connecté.

Se composent-ils ?

Oui, proprement. rtk travaille en limite de shell, tokensave répond à des requêtes MCP. Aucun ne réécrit ce que l'autre a produit, il n'y a aucun état partagé, et les deux sont des binaires uniques au surcoût d'exploitation négligeable. Si votre travail mélange réellement des boucles terminal lourdes et de la navigation de code lourde, faire tourner les deux est cohérent. Le coût, c'est deux installations, un index à garder frais, et le manifeste de 48 outils à chaque tour.

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

Les lectures de fichiers entiers pour éditer. L'agent ouvre toujours le fichier pour le modifier. Un index dit lequel ; un filtre shell ne le voit jamais.
Les relectures. Le même fichier entrant quatre fois en contexte dans une session coûte quatre fois. Aucun ne déduplique.
Les manifestes MCP. Aucun ne les diffère ; tokensave en ajoute un gros.
L'historique de conversation. Aucun ne compresse la fenêtre, qui sur une session longue est la plus grosse accumulation.

Cette liste explique la divergence entre économies par canal et économies par session, et pourquoi deux outils bien construits peuvent laisser votre facture à peu près où elle était.

Lequel choisir ?

Prenez rtk si votre journée est faite de builds, tests, conteneurs et commandes d'infrastructure, sous Linux ou macOS. L'économie est réelle, immédiate, et vous pouvez en mesurer la taille vous-même avec rtk gain en une semaine. Prenez tokensave si vous travaillez sur de nombreux langages, relisez souvent des branches, ou voulez le chemin d'édition plus sûr qu'offre la réécriture AST. C'est aussi celui des deux qui fonctionne sous Windows. Ne prenez ni l'un ni l'autre pour l'instant si vous n'avez pas réparti votre dépense entre sorties shell et opérations sur fichiers. Une semaine avec ccusage tranche cette page mieux que tout tableau de fonctionnalités.

Comment appliquer ça aujourd'hui

Répartissez une semaine de dépense entre sorties shell et opérations sur fichiers. Ce rapport tranche la comparaison à votre place.
Si vous installez rtk, comparez rtk gain à votre total, pas à lui-même. Un gros pourcentage d'un petit canal reste petit.
Si vous installez tokensave, comptez les appels d'outils avant et après — c'est la métrique qu'un index déplace réellement.
Déconnectez ce que vous n'interrogez pas. Un manifeste de 48 outils sur une session purement terminal est une perte sèche.

Ce qui tourne mal (anti-patterns)

Attendre de rtk qu'il couvre les outils de fichiers de l'agent. Le hook est sur bash, par conception. Attendre de tokensave qu'il aide une boucle de build bavarde. Il n'est pas du tout sur ce chemin. Laisser une grosse surface MCP connectée par habitude. Elle est facturée à chaque tour, y compris ceux où vous n'y touchez pas. Prendre « non benchmarké » pour « ne marche pas ». tokensave ne publie aucun chiffre ; c'est une preuve manquante, pas la preuve d'un échec.

À lire aussi :

Réduire l'usage des tokens dans Claude Code — le pilier, indépendant de l'outil
tokensave vs codegraph — tokensave face à l'autre index de code
codegraph vs rtk — la même question avec l'autre index
Benchmark des optimiseurs de tokens — la mesure ouverte derrière le résultat de rtk
Recherche sémantique vs grep — pourquoi indexer bat grepper, et où ça s'arrête