rtk vs token-optimizer : un mécanisme ou quatre ?

Fait partie du pilier réduire l'usage des tokens dans Claude Code. Cette page oppose l'outil le plus étroit de la catégorie à l'un des plus larges.

rtk ou token-optimizer : lequel choisir ?

token-optimizer couvre une plus grande part de la facture — et si vous êtes une entreprise, sa licence tranche avant toute fonctionnalité. rtk filtre les sorties de commandes shell, et rien d'autre. token-optimizer empile quatre mécanismes, dont le plus fort transforme un fichier de 180K tokens en environ 250 tokens de structure. rtk est gratuit sous un modèle open source permissif. token-optimizer est en PolyForm Noncommercial : gratuit pour un usage personnel ou en petite équipe, licence payante requise pour l'usage commercial. C'est la première chose à vérifier, pas la dernière. Je maintiens un benchmark ouvert de sessions longues et je vends un outil concurrent. rtk y termine à peu près à l'équilibre ; token-optimizer n'y a pas été mesuré.

Que fait rtk exactement ?

Une seule chose, bien. Un proxy CLI en Rust avec 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 ; rtk compacte ce qui revient. Binaire unique, moins de 10 ms de surcoût au démarrage, aucun coût en tokens pour l'intégration, et un DSL TOML pour ajouter vos règles. rtk gain rapporte les économies par commande depuis un stockage SQLite. Les réductions sont fortes sur les outils bavards : environ 90 % sur cargo test, environ 80 % sur les opérations git. Ses limites découlent de sa portée. Le hook ne couvre que bash, donc les outils intégrés Read, Grep et Glob le contournent — et sur la plupart des agents ce sont eux qui portent l'essentiel des tokens. Pas de recherche, pas de compression structurelle des sources, pas de report MCP, pas de PowerShell natif sous Windows.

Que fait token-optimizer exactement ?

Quatre couches, qui s'attaquent à des choses réellement différentes :

Les cartes de structure AST. Un fichier de 180K tokens devient environ 250 tokens de structure — signatures, symboles, forme. Soit 95–99 % de compression sur exactement la charge qui fait le plus mal, et ç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. L'état de session est condensé à mesure qu'il grossit au lieu d'être jeté et redémarré.
Un score de qualité à 7 signaux. Il guette la dégradation du contexte en cours de session — cette dérive lente où les réponses de l'agent empirent parce que sa fenêtre s'est remplie de bruit. 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, adoption des skills, détection de dérive.

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

Ce que chacun rapporte, et pourquoi ça compte

Ces deux-là ont des philosophies de reporting opposées, et les deux sont instructives. rtk gain rapporte un chiffre honnête : parmi les octets filtrés par rtk, combien ont été retirés ? Le dénominateur est le canal propre de rtk, donc un gros pourcentage là-dessus peut cohabiter avec une facture plate. Ce n'est pas malhonnête — c'est précis sur un périmètre plus petit que votre facture. Le tableau de bord de token-optimizer rapporte à l'échelle de la session : coût par tour, analyse du cache, mix de modèles. C'est plus proche de ce que vous payez vraiment, et c'est le seul outil de cette comparaison qui vous montrera un signal de qualité à côté d'un signal de coût. Si vous installez rtk, associez-le à un compteur au niveau session, sinon vous lirez un pourcentage de canal comme un pourcentage de facture. Si vous installez token-optimizer, vous avez les deux périmètres au même endroit.

Où chacun laisse-t-il des tokens ?

rtk laisse tout ce qui n'est pas une commande shell. Lectures de fichiers par les outils propres de l'agent, manifestes MCP envoyés avant votre premier message, historique de conversation rejoué à chaque tour. token-optimizer laisse la limite d'outil. Sa compaction est une opération au niveau session, pas un filtre par commande : un cargo test bavard arrive toujours en taille réelle avant que quoi que ce soit ne le condense. Il ne diffère pas non plus les manifestes MCP, et n'offre aucune recherche sémantique de code. À eux deux la couverture est large sans être complète, et ils ne se recoupent sur rien — ce qui est l'argument pour faire tourner les deux, si la licence le permet.

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

Les manifestes MCP. Chaque serveur connecté envoie ses définitions d'outils avant votre premier message, utilisées ou non. Aucun des deux ne les diffère, et sur une installation à plusieurs serveurs c'est l'un des plus gros coûts permanents que vous puissiez supprimer sans changer votre façon de travailler.
Les relectures. Le même fichier entrant quatre fois en contexte dans une session coûte quatre fois. Une carte de structure rend chaque lecture plus petite ; rien ici ne remarque la répétition.
La recherche sémantique. Aucun ne remplace une recherche dans le dépôt par une réponse ciblée. La carte de structure de token-optimizer dit à l'agent ce qu'il y a dans un fichier qu'il a déjà décidé d'ouvrir ; elle ne l'aide pas à décider lequel ouvrir.
L'écart entre « plus petit » et « moins nombreux ». Les deux réduisent la taille des charges. Aucun ne réduit le nombre de choses dont l'agent décide avoir besoin, là où un index de code gagne sa place et où ces deux-là s'arrêtent.

Ce dernier point est le plafond honnête de cette comparaison. Compression et filtrage rendent chaque élément moins cher ; ils ne changent pas le comportement de l'agent. Sur une session longue, le comportement est le terme le plus grand.

Lequel choisir ?

Réglez d'abord la question de licence si vous travaillez en entreprise. PolyForm Noncommercial implique une licence payante pour l'usage commercial. Décider après un déploiement d'équipe est l'ordre coûteux, et ça n'a rien à voir avec les tokens. Prenez rtk si votre journée est faite de builds, tests, conteneurs et travail d'infrastructure sous Linux ou macOS, ou s'il vous faut quelque chose sans aucune question de licence. C'est le plus simple, le moins cher et le plus auditable d'ici. 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 AST est le mécanisme unique le plus fort de cette comparaison, et le tableau de bord vous permet de voir si ça a marché. Prenez les deux si votre travail a les deux formes et que la licence le permet. Ils n'entrent pas en conflit.

Comment appliquer ça aujourd'hui

Réglez la question de licence avant tout le reste. Deux minutes, et c'est la seule décision irréversible de cette page.
Trouvez vos plus grosses lectures de fichiers. Si une poignée de gros fichiers domine, une carte de structure est le changement le plus rentable à votre portée.
Si vous installez rtk, comparez rtk gain à un total au niveau session, jamais à lui-même.
Changez une chose à la fois et mesurez sur une semaine, pas sur une tâche.

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. Lire rtk gain comme une réduction de facture. Chiffre précis, dénominateur plus petit qu'on ne croit. Attendre de rtk qu'il couvre les outils de fichiers intégrés de l'agent. Le hook est sur bash, par conception. Supposer qu'un outil non mesuré est sans risque. L'absence de token-optimizer du benchmark ouvert est une preuve manquante, pas un résultat propre.

À lire aussi :