rtk vs caveman : côté entrée ou côté sortie ?

Fait partie du pilier réduire l'usage des tokens dans Claude Code. Cette page est le face-à-face, et c'est la comparaison entrée-contre-sortie la plus nette de la catégorie.

rtk ou caveman : quel est le meilleur optimiseur de tokens ?

Ce ne sont pas des substituts. rtk agit sur ce qui entre dans le modèle, caveman sur ce qui en sort — et pour du travail agentique, ce qui entre est le plus gros chiffre. Dans une session de code typique, le flux entrant domine le sortant d'environ un ordre de grandeur : contenus de fichiers, sorties de commandes, manifestes d'outils et historique de conversation entrent tous, tandis que le modèle émet comparativement peu. Cette asymétrie est la chose la plus utile à connaître avant de choisir entre les deux. Elle ne rend pas caveman inutile — les tokens de sortie sont facturés plus cher au token, et caveman a aussi une astuce côté entrée — mais elle signifie que les deux outils ne jouent pas la même mise. Je maintiens un benchmark ouvert des optimiseurs de tokens et je vends un outil concurrent. Aucun des deux n'y montre d'économie de coût de session mesurable, et les raisons diffèrent assez pour compter.

Que fait rtk exactement ?

Il filtre les sorties de commandes en limite de shell. Un proxy CLI en Rust avec plus de cent filtres spécifiques par commande — git, cargo, npm, pytest, docker, aws — et un hook transparent : vous tapez vos commandes exactement comme avant. Il retire ce dont un modèle de langage ne tire rien et transmet une version compactée. Un binaire, moins de 10 ms de surcoût au démarrage, aucun coût en tokens pour l'intégration. rtk gain rapporte les économies par commande depuis un stockage SQLite, et un DSL TOML permet d'écrire vos propres règles. Sur les outils bavards, la réduction est forte et visible : environ 90 % sur cargo test, environ 80 % sur les opérations git. Ses limites structurelles : le hook ne couvre que bash, donc les outils intégrés Read, Grep et Glob passent à côté — 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. Pas de PowerShell natif sous Windows.

Que fait caveman exactement ?

Il change la façon dont le modèle parle. Un skill ou plugin JavaScript pour plus de 30 agents de code, qui bascule la sortie en « caveman talk » télégraphique, avec quatre niveaux — lite, full, ultra, wenyan — choisis par une commande /caveman. Le benchmark qu'il publie est inhabituellement honnête pour la catégorie : 65 % de réduction de sortie en moyenne, fourchette 22–87 %, mesuré sur les reçus bruts de l'API Claude contre une base déjà concise. Pas une simulation, pas un compteur de tokens — des reçus. Il embarque deux choses au-delà du style, et ce sont celles qu'on rate :

caveman-shrink, un middleware MCP qui enveloppe n'importe quel serveur MCP et compresse ses descriptions d'outils. C'est une économie côté entrée, et elle vise exactement le coût permanent par tour que la plupart des outils ignorent.
caveman-compress, qui réécrit CLAUDE.md et les fichiers de mémoire en forme télégraphique — environ 46 % d'économie d'entrée sur un fichier renvoyé à chaque tour.

L'installation est un curl ou irm de 30 secondes, avec détection automatique sur Claude Code, Codex, Gemini, Cursor, Windsurf, Cline et Copilot. Un badge de statusline affiche les économies cumulées, ce qui a l'air d'un gadget et se révèle être ce qui fait durer l'usage. Le coût honnête figure dans son propre readme : l'application du style peut dégrader la qualité de raisonnement sur les explications nuancées. Vous échangez de la fluidité contre des tokens, et sur un travail où l'explication est le livrable, c'est un mauvais échange.

Quelle moitié de la facture est la plus grosse ?

La moitié entrante, pour presque toute charge agentique. Le modèle lit bien plus qu'il n'écrit : des fichiers entiers ouverts pour changer quatre lignes, des lancements de tests renvoyés intégralement, des manifestes MCP chargés avant votre premier message, et toute la conversation rejouée à chaque tour. Les tokens de sortie coûtent plus cher au token, ce qui rend leur réduction gratifiante. Mais un gros pourcentage d'un petit nombre reste un petit nombre. Couper 65 % de la sortie sur une session où la sortie représente un dixième du trafic déplace le total de quelques points. C'est pourquoi les deux outils finissent à l'équilibre sur une mesure de session longue tout en publiant des économies réelles et vérifiables sur leur canal. Chacun dit la vérité sur une tranche. L'exception à signaler : si votre usage ressemble à du chat plutôt qu'à de l'agentique — longues explications générées, documents, gros volumes de texte produit et peu de lecture de fichiers — l'équilibre bascule et le terrain de caveman devient le plus grand.

Se composent-ils ?

Oui, et particulièrement bien, parce qu'ils se touchent à peine. rtk intervient avant que le contenu n'atteigne le modèle, caveman après. Aucun état partagé, aucune interférence. Si vous faites tourner les deux, les points à surveiller sont les extras côté entrée de caveman : caveman-shrink compresse les descriptions d'outils MCP, et caveman-compress réduit votre fichier de mémoire. Ce sont les deux seuls endroits où ses économies et celles de rtk vivent du même côté du tuyau — et aucun ne recouvre les filtres shell de rtk, ce qui rend l'association propre plutôt que redondante.

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

Les lectures de fichiers entiers. L'agent ouvre un fichier de 2 000 lignes pour changer quatre lignes. rtk ne le voit jamais (ce n'est pas une commande shell), caveman ne touche pas du tout aux résultats d'outils.
Les relectures. Même fichier, quatre fois, quatre facturations. Aucun ne déduplique.
L'historique de conversation. Aucun ne compresse la fenêtre qui s'accumule sur une session longue.
La recherche sémantique. Aucun ne remplace une recherche par une réponse ciblée.

Lequel choisir ?

Prenez rtk si votre journée est faite de builds, tests, conteneurs et commandes d'infrastructure, et que vous êtes sous Linux ou macOS. L'économie sur ces blocs est réelle et vérifiable vous-même avec rtk gain. Prenez caveman si votre agent génère beaucoup de prose, ou si vous voulez précisément caveman-shrink et caveman-compress — deux gains côté entrée que la plupart des optimiseurs de la catégorie n'offrent pas du tout. Prenez les niveaux de style au sérieux : restez en lite sur le travail dont vous lirez les explications. Prenez les deux si vous voulez couvrir les deux bouts à peu de frais. Ce sont parmi les installations les moins friction d'ici et elles n'entrent pas en conflit. Ne prenez ni l'un ni l'autre pour l'instant si vous n'avez pas regardé votre répartition entrée/sortie. C'est un seul chiffre, une semaine avec ccusage suffit, et il répond à cette page mieux que toute comparaison de fonctionnalités.

Comment appliquer ça aujourd'hui

Obtenez votre ratio tokens entrée/sortie sur une semaine. Si l'entrée domine d'un facteur 10 — et c'est probablement le cas — vous savez lequel des deux installer en premier.
Si vous essayez caveman, commencez en lite et lisez la sortie. Décidez si la qualité de raisonnement récupérée vaut ce que vous avez économisé.
Installez caveman-shrink même si vous sautez le style, si vous utilisez des serveurs MCP. Les descriptions d'outils sont un coût permanent que presque rien d'autre ne touche.
Si vous installez rtk, comparez rtk gain à votre total, pas à lui-même.

Ce qui tourne mal (anti-patterns)

Optimiser la sortie en premier. C'est le levier vers lequel on se tourne parce qu'il est visible, et celui qui rapporte le moins sur du trafic agentique. Passer en ultra sur du travail que vous devez comprendre. Le readme dit que l'application du style peut dégrader le raisonnement nuancé. Croyez-le avant de déboguer une réponse fausse. Attendre de rtk qu'il couvre les outils de fichiers de l'agent. Le hook est sur bash, par conception. Lire un pourcentage par canal comme une économie de session. 65 % sur la sortie et 90 % sur cargo test sont vrais tous les deux, et aucun n'est 65 % ou 90 % sur votre facture.

À lire aussi :