Alternatives à rtk : 6 outils comparés

Par quoi remplacer rtk ?

Si vous voulez que la facture bouge, prenez Tokenade : c'est le seul des douze outils du benchmark ouvert THOL qui a réduit de façon mesurable le coût d'une session, et rtk lui-même n'y a montré aucune économie mesurable. Si vous aimez le mécanisme de rtk et voulez simplement plus de portée, squeez est le remplaçant le plus proche.

rtk fait bien ce qu'il fait. Il embarque plus de 100 filtres de commandes dans un binaire Rust, prend en charge 18 outils de code IA et offre l'installation la plus simple de la catégorie. Les raisons d'aller voir ailleurs sont plus étroites que « ça ne marche pas ».

• Il ne voit que les commandes shell, pas les lectures de fichiers, recherches ou résultats MCP de l'agent.
• Son compteur d'économies mesure la sortie bash, pas la facture. Son propre README dit que la réduction « se dilue à chaque étape ».
• Le téléchargement par défaut livre désormais son moteur de compression sous BUSL-1.1, à côté d'une édition rtk-oss uniquement en Apache-2.0.

Divulgation avant le classement : je maintiens le benchmark THOL et je développe Tokenade. Le benchmark est public et reproductible, et il contient des résultats qui ne flattent pas mon outil, mais ce n'est pas un tiers indépendant.

Fonctionnalités et prix relevés sur la page de chaque projet le 14 octobre 2026. Les verdicts de coût de session viennent de la campagne THOL publiée (Claude Code 2.1.206), la seule que ce site cite.

Si vous avez déjà un concurrent précis en tête plutôt qu'une liste, chaque duel a sa page :

• headroom vs rtk pour la compression de messages entiers face au filtrage du shell ;
• rtk vs caveman pour le côté entrée face au côté sortie ;
• rtk vs token-optimizer pour un mécanisme face à quatre ;
• rtk vs tokensave et codegraph vs rtk pour filtrer le shell face à indexer le code ;
• rtk vs graphify quand la connaissance du projet vit dans des documents ;
• rtk vs ccusage si ce qu'il vous faut d'abord est un compteur.

La liste courte

Comment ces outils ont été choisis

Cinq critères, appliqués à l'identique à chaque entrée, y compris la mienne :

• Coût de session mesuré. De bout en bout, face à un contrôle sans outil, d'après THOL. Les six outils de cette liste et rtk figuraient dans la même campagne publiée, ce qui rend la liste inhabituellement comparable. Les chiffres des éditeurs restent dans le texte, attribués, avec le périmètre sur lequel ils ont été mesurés.
• Portée au-delà de bash. rtk voit les commandes shell. Les lectures de fichiers via les outils propres de l'agent, les résultats MCP et l'historique de conversation lui échappent.
• Poids d'installation. Un binaire unique, un runtime Node, un compte et une passerelle hébergée sont quatre engagements différents.
• Agents couverts. Un seul agent, ou toute votre stack.
• Licence, et chemin de votre trafic. Un outil purement local et un outil routé par passerelle n'exposent pas la même surface de confidentialité.

Deux familles sont exclues volontairement. headroom a fini dernier de THOL, mesurablement plus cher que l'absence d'outil. Les indexeurs de code comme codegraph règlent un autre problème ; ils ont leur page Alternatives à CodeGraph.

1. Tokenade — celui dont la baisse de coût est mesurée

Tokenade est l'alternative à rtk la plus solide sur le critère qui compte le plus : c'est le seul des douze outils du benchmark ouvert qui a réellement réduit le coût d'une session.

• Ce que c'est : un binaire entre votre agent IA et ses outils, qui combine filtrage des sorties, lectures de fichiers par la structure d'abord, recherche sémantique de code sur la machine, exécution en sandbox et repli des résultats MCP, avec un tableau de bord des économies.
• Forces : sur le benchmark ouvert des optimiseurs de tokens, il réduit de 39 % le coût des longues sessions par rapport à l'absence d'outil. Le filtrage s'applique à la sortie de chaque outil, pas seulement de bash, donc les lectures et recherches propres de l'agent sont couvertes aussi.
• Installation : un seul tokenade install détecte vos agents et enregistre les hooks. Ce que chaque agent prend en charge figure dans la matrice de compatibilité. La compaction tourne sur votre machine, et tokenade uninstall --dry-run montre la désinstallation avant que vous en ayez besoin.
• Limites : c'est mon produit, pondérez en conséquence. Il est freemium et n'est pas open source, là où tout le reste de la liste est gratuit ou a un cœur gratuit. Comme tout compacteur, il peut replier une sortie dont vous aviez besoin ; tokenade raw <cmd> relance une commande sans compaction.
• Idéal pour : quiconque veut que la facture bouge, sur plus d'un agent IA. La vue attribut par attribut est sur Tokenade vs rtk.

2. squeez — le mécanisme de rtk, avec plus de portée

squeez est l'alternative à rtk la plus directe : un binaire Rust qui compresse les sorties shell avant qu'elles n'entrent en contexte, et les lectures de fichiers quand l'hôte les expose.

• Ce que c'est : un compresseur à hooks avec filtrage intelligent, déduplication entre appels, compactage des gabarits de logs et troncature selon la pertinence. Apache-2.0, sans dépendance d'exécution.
• Forces : la compression est réversible, car les octets d'origine sont gardés en local et l'agent peut les récupérer. Un garde-fou conserve l'original quand une coupe forte ferait disparaître chemins de fichiers, marqueurs d'erreur ou verdicts de tests. Installation par curl, npm ou cargo ; squeez setup détecte vos CLI.
• Limites : au benchmark THOL, il n'a montré aucune économie mesurable, le même verdict que rtk. D'après sa propre documentation, il ne peut compresser ni les retours de sous-agents, ni les prompts de premier niveau, ni les fichiers de skills chargés au démarrage, et le support varie selon l'hôte.
• Idéal pour : les utilisateurs de rtk qui veulent la même couche, traitée avec plus de soin. Le face-à-face avec le nôtre est Tokenade vs squeez.

Deux outils indépendants sur la même couche, l'un étroit et l'autre large, qui aboutissent tous deux à aucun changement mesurable : c'est l'indice le plus net de cette liste que le filtrage des sorties seul n'est pas là où vit une facture agentique.

3. lean-ctx — la boîte à outils open source la plus large

lean-ctx est le bon choix si vous voulez la compression shell de rtk plus du cache, de la récupération et un proxy dans un seul binaire open source, et que vous acceptez de le configurer.

• Ce que c'est : un binaire Rust qui travaille sur deux plans. Côté lecture, un serveur MCP expose des outils ctx_* (modes de lecture, cache, deltas, recherche, mémoire) à côté d'un hook shell. Côté réseau, un proxy local optionnel peut alléger prompts, historique et résultats d'outils.
• Forces : le cache de lecture rend les relectures peu coûteuses, et le proxy atteint l'historique de conversation, une surface que les outils à hooks comme rtk ne touchent jamais. Installation par curl, brew, npm ou cargo. Son rapport d'économies est franc : il présente sa référence comme simulée, pas comme une seconde exécution mesurée.
• Limites : aucune économie mesurable au benchmark THOL ; il s'est mesuré légèrement plus cher que l'absence d'outil, sans que l'écart soit significatif. Un grand nombre d'outils MCP porte un coût fixe à chaque session. La licence est mixte, avec des contrôles entreprise sous conditions séparées.
• Idéal pour : les bricoleurs qui veulent un seul outil pour le cache, la compression et la récupération, et qui le régleront. Voir Tokenade vs lean-ctx.

4. caveman — les deux côtés de la session, en un npx

caveman est l'alternative à rtk à la couverture la plus large : une installation qui raccourcit ce que l'agent dit et, depuis la 4.0, ce qu'il lit, sur plus de 30 agents.

• Ce que c'est : une CLI Node (npx @caveman-ai/cli@latest, Node 22.13+) qui regroupe un style de réponse télégraphique, une compression côté lecture des logs, du JSON, du CSV et des sorties de tests, un sélecteur de modèle et des correctifs plus petits. Apache-2.0.
• Forces : caveman annonce 33,2 % de tokens d'entrée en moins par session pour sa compression côté lecture. Ce chiffre a été mesuré sur six fichiers de test qui cachent chacun un enregistrement dans 61 à 72 Ko de bruit, sur trois exécutions, et son README signale que le HTML a empiré. Les originaux restent sur le disque.
• Limites : la campagne THOL publiée ne montre aucune économie mesurable pour caveman. Je n'ai pas remesuré la 4.0, donc ce verdict vaut pour la version testée. Il faut un runtime Node, le sélecteur de modèle optionnel demande un compte gratuit, et le style télégraphique ne plaît pas à tout le monde.
• Idéal pour : les stacks multi-agents qui veulent une expérience peu coûteuse. Le partage des mécanismes est sur rtk vs caveman et Tokenade vs caveman.

5. claude-token-efficient — le test le plus léger possible

claude-token-efficient est l'alternative à rtk sans rien à installer : un seul fichier CLAUDE.md, classé deuxième sur douze au benchmark THOL.

• Ce que c'est : un fichier prêt à déposer, fait de règles de comportement compactes contre le remplissage, la reformulation des questions et la sur-ingénierie. MIT.
• Forces : ni binaire, ni hook, rien à désinstaller. Le projet est d'une honnêteté rare sur le périmètre : il annonce des réductions de tokens de sortie d'environ 4 % sur Haiku, 12 % sur Sonnet et 7 % sur Opus pour son fichier minimal actuel, et prévient que le fichier ajoute des tokens d'entrée à chaque tour.
• Limites : la deuxième place signifiait quand même aucune économie mesurable face au contrôle. Il agit sur une tout autre couche que rtk et ne touche jamais aux sorties de commandes, aux lectures de fichiers ni aux manifestes MCP.
• Idéal pour : un premier pas sans risque, ou une couche de base sous un outil qui réduit l'entrée. Voir Tokenade vs claude-token-efficient.

6. edgee — l'idée de rtk, déplacée sur une passerelle

edgee est l'alternative à rtk pour les équipes qui tiennent plus au routage et au contrôle des dépenses qu'à un filtre local : d'après son propre README, son moteur d'allègement dérive de rtk.

• Ce que c'est : une passerelle IA. edgee launch claude fait passer votre agent par une passerelle hébergée qui allège les sorties d'outils avant qu'elles n'atteignent le modèle. La CLI est sous Apache-2.0.
• Forces : des fonctions de passerelle qu'un outil local ne peut pas offrir — modèles de repli, reroutage, suivi d'usage par équipe et plafonds de dépense sur l'offre payante. Il s'installe sous Windows comme sous macOS et Linux, et edgee stats affiche les économies par session.
• Limites : aucune économie mesurable au benchmark THOL. Le trafic de votre agent transite par une passerelle tierce, vous vous connectez avec edgee auth login, et la compression s'arrête si le service est injoignable. Les contrôles d'équipe sont payants par développeur.
• Idéal pour : les équipes qui ont besoin de routage et de budgets. Le README d'edgee renvoie lui-même vers rtk les développeurs qui veulent seulement une compression locale, ce qui est honnête. Voir Tokenade vs edgee.

Vue d'ensemble

Pourquoi le compteur de rtk ne colle pas à votre facture ?

Parce que rtk gain mesure la sortie bash qu'il a réduite, et que c'est une part d'une part. Le README de rtk le dit clairement : la sortie bash n'est qu'une des sources de tokens d'entrée, à côté de votre prompt, du prompt système et de l'historique, et l'entrée n'est qu'une partie de la facture.

Ses comptes de tokens sont aussi estimés en divisant les octets par quatre, faute de tokenizer embarqué. Un gros pourcentage sur cargo test est donc réel pour cette commande et dit peu de choses de la session. La lecture complète des deux chiffres est sur rtk vs ccusage.

THOL rend visible un second effet. Quand une compression avec perte fait disparaître les octets dont le modèle avait besoin, l'agent relance la commande, souvent en contournant l'outil. Cela coûte des tours, et ce sont les tours que vous payez. Chaque alternative ci-dessus doit être jugée sur la même question à l'échelle de la session, la mienne comprise.

Lequel choisir ?

• Vous voulez que la facture baisse, sur plus d'un agent IA : Tokenade. La méthode et le tableau complet, y compris les entrées qui ne l'avantagent pas, sont sur le leaderboard THOL.
• Vous aimez rtk et voulez la même couche, réversible : squeez.
• Vous voulez cache, compression et récupération dans un binaire open source : lean-ctx, avec du temps pour le configurer.
• Vous utilisez beaucoup d'agents et voulez une expérience peu coûteuse : caveman.
• Vous ne voulez changer qu'un fichier : claude-token-efficient.
• Vous avez besoin de routage, de modèles de repli et de plafonds de dépense pour une équipe : edgee.
• Vous restez sur rtk : c'est défendable si des builds et des tests bavards dominent vos sessions. Lisez rtk gain comme des économies sur la sortie bash, pas comme votre facture.

L'offre gratuite de Tokenade couvre largement le travail en solo ; les tarifs en vigueur sont sur la page de tarifs.

FAQ

Existe-t-il une alternative gratuite à rtk ?

Oui. squeez, caveman et claude-token-efficient sont gratuits et open source, et lean-ctx est gratuit en usage local. edgee et Tokenade ont tous deux une offre gratuite. Gratuit ne veut pas dire moins cher pour autant : dans la campagne THOL publiée, aucun des outils gratuits n'a montré de baisse mesurable du coût de session.

Quelle différence entre rtk et rtk-oss ?

D'après le README de rtk, le téléchargement rtk par défaut combine du code Apache-2.0 et BUSL-1.1 et inclut le moteur de compression. rtk-oss est uniquement en Apache-2.0, avec les hooks et les filtres mais sans moteur. Les deux installent un binaire nommé rtk : il faut désinstaller l'un avant d'installer l'autre. L'usage en production est gratuit dans les deux cas.

rtk casse-t-il le cache de prompt ?

Non, d'après son README : il filtre la sortie de chaque commande une seule fois, et le résultat est mis en cache normalement aux appels suivants. Ce sont les outils qui réécrivent l'historique de conversation à chaque tour qui cassent le préfixe en cache, ce qui explique en partie la dernière place de headroom au benchmark THOL.

Peut-on utiliser une alternative à rtk en même temps que rtk ?

Oui, mais deux outils qui compressent la même sortie de commande ajoutent du surcoût et rendent les deux compteurs d'économies illisibles. Prenez un outil par couche. Associer un filtre shell à un outil qui gère les lectures de fichiers ou la récupération a plus de sens qu'empiler deux filtres.

edgee est-il construit sur rtk ?

En partie. Le README d'edgee indique que le moteur d'allègement de tokens de sa passerelle dérive de rtk, avec le copyright d'origine conservé. La différence tient à l'endroit où il tourne : rtk compresse en local, edgee compresse sur une passerelle hébergée par laquelle passe le trafic de votre agent.

---

À voir aussi :

• Tokenade vs rtk — les deux côte à côte, attribut par attribut
• Benchmark des optimiseurs de tokens — les cinq chiffres derrière ce classement, et comment ils ont été mesurés
• Meilleurs optimiseurs de tokens pour Claude Code — tout le terrain, même méthodologie
• Alternatives à Headroom — la même question pour la compression de messages
• Alternatives à tokensave — la même question pour les index de code compilés
• Alternatives à ccusage — la même question par le côté mesure
• Réduire les coûts de Claude Code — les leviers classés par ce qu'ils rapportent