L’illusion de la compression de tokens : pourquoi je reste sceptique face à RTK

• RTK promet de compresser la sortie terminal des agents de code pour réduire les coûts, mais une réduction de la sortie brute ne signifie pas automatiquement une ingénierie logicielle moins chère, plus sûre et plus précise
• Les « 60 à 90 % de réduction » ne veulent pas dire que la facturation LLM a baissé d’autant, mais correspondent plutôt à la part de sortie en ligne de commande supprimée par RTK
• Si des silent failures surviennent, avec une sortie terminal discrètement corrompue ou manquante, l’agent peut prendre de mauvaises décisions sans stack trace importante ni contexte compilateur
• Les graphiques d’économies de tokens ne suffisent pas ; il faut aussi un taux de réussite des tâches montrant si l’agent autonome a réellement terminé le travail, ainsi qu’une évaluation de précision de type SWE-bench
• RTK ressemble davantage à une fonctionnalité d’outillage de développement qu’à un produit autonome, et il est vulnérable aux changements dans les sorties CLI comme git, cargo, npm ou grep, ce qui en fait un risque opérationnel trop élevé pour le placer sur le chemin critique d’agents en production

---

La structure réelle des coûts masquée par les chiffres d’économie

• RTK met en avant la réduction de l’usage des tokens et la baisse des coûts grâce à la compression de sortie terminal pour les agents de code
  • Le projet a obtenu plus de 60k étoiles sur GitHub, et l’industrie réagit fortement à cette communication
  • Mais les promesses d’outils de développement qui paraissent « trop belles pour être vraies » doivent être examinées dans leur structure réelle
• Le chiffre viral de « 60 à 90 % de réduction » n’est pas équivalent à une baisse réelle de la facture API
  • Ce que RTK réduit, c’est une partie de la sortie Bash
  • Des postes de coût plus importants demeurent, comme la lecture approfondie de fichiers, le contexte du dépôt, les prompts système ou les tokens de raisonnement internes du modèle
  • Des commandes comme rtk gain semblent davantage calibrées pour produire des captures d’écran convaincantes sur les réseaux sociaux ou pour des managers non techniques que pour une véritable optimisation architecturale
  • De récentes issues GitHub commencent aussi à pointer le problème de métriques exagérées

La précision et la stabilité opérationnelle sont des variables plus importantes

• Une optimisation n’a aucun sens si la précision ne suit pas, et les issues publiques du dépôt montrent déjà des cas où la sortie terminal est silencieusement cassée ou incomplète
  • Le risque central est que l’agent IA ne sache pas que le texte a été compressé
  • Si RTK supprime des lignes importantes d’une stack trace ou du contexte compilateur pour économiser quelques tokens, l’utilisateur comme le LLM travaillent alors avec des informations incomplètes
  • Adopter RTK revient à dépendre d’une couche externe qui doit parser, interpréter et résumer la sortie d’innombrables outils CLI sans perte de sens
• RTK montre des graphiques d’économie de tokens, mais il manque la métrique vraiment importante : le taux de réussite des tâches
  • La vraie question est de savoir si l’agent autonome résout effectivement le problème d’ingénierie logicielle à la fin de sa boucle d’exécution
  • Même en réduisant le coût du prompt de 80 %, si la dégradation du contexte pousse l’agent à halluciner, à échouer à la compilation ou à tourner en boucle, il peut au final consommer encore plus de tokens
  • Tant qu’il n’y aura pas, en plus des graphiques de coût, une évaluation rigoureuse de précision de type SWE-bench, le récit autour de RTK restera incomplet
• D’un point de vue architectural, RTK ajoute une dépendance externe vulnérable sur le chemin critique synchrone entre l’agent et le shell
  • L’optimisation de sortie ressemble davantage à une fonctionnalité qu’à un produit autonome ou une plateforme
  • Si les principaux CLI et outils de développement proposent des drapeaux natifs --compact ou --json-stream adaptés à la consommation par les LLM, l’avantage principal de RTK pourrait disparaître
• RTK dépend fortement d’un parsing spécifique de formats stdout/stderr conçus pour des humains, ce qui complique la maintenance
  • Si git, cargo, npm ou grep changent quelques espaces dans leur format terminal ou la disposition de leurs erreurs, les regex et filtres de parsing de RTK peuvent casser
  • Dans ce cas, l’échec peut rester silencieux plutôt que de produire une erreur explicite, et fournir à l’agent un texte corrompu ou partiel
• RTK échange une métrique spectaculaire de réduction brute des tokens terminal contre la fiabilité déterministe, l’exhaustivité sémantique et la simplicité architecturale
  • Tant que les silent degradations ne sont pas résolues et que des benchmarks transparents de précision sur les tâches ne sont pas fournis, le placer sur le chemin critique d’un workflow d’agents en production présente un risque opérationnel disproportionné par rapport à la remise annoncée

[GN⁺]

Commentaires Hacker News

• Je suis content de voir que ce genre d’articles commence enfin à prendre de l’ampleur au sujet de toute l’industrie de la boîte magique des LLM
  Du caveman mode à RTK en passant par la recherche sémantique, on a l’impression que les développeurs sont devenus moins des ingénieurs que des sorciers qui récitent des incantations, et au travail c’est particulièrement épuisant parce que chacun est persuadé que son propre sort est la méthode ultime pour économiser des tokens
  Mon critère est simple : toute idée qui n’entre pas dans un harnais d’évaluation est en général mauvaise, et les bonnes idées finissent de toute façon par remonter dans Codex/Claude. Même les annonces sur GitHub qui promettent d’économiser quelques pourcents de tokens me paraissent difficiles à croire
  Il est difficile d’éviter les outils trompeurs dans ce domaine, et j’aimerais que les gens commencent à les regarder avec plus d’esprit critique

  • C’est complètement faux, et tu sous-estimes à quel point les acteurs de pointe sont incompétents dans tout ce qui n’est pas la fabrication de modèles LLM
    Pendant un an, on a aussi vu des cas comme des TUI clignotantes « écrites comme des moteurs de jeu », et pour avoir moi-même exécuté plusieurs benchmarks, il existe des méthodes validées qui réduisent les tokens tout en produisant le même résultat. Par exemple, trouver la même CVE ou repérer le même bug lors d’une revue de code
    Tu peux regarder ma petite démonstration sur https://maki.sh
  • C’est pour ça que je fais des tests A/B en aveugle sur tout
    Ça brûle beaucoup de tokens, mais il faut prouver que ça apporte une vraie valeur, et la plupart des choses sont très loin d’atteindre ce niveau
    Mon agent IA intègre aussi plusieurs fonctionnalités, mais je ne considère pas qu’un résultat de test A/B en aveugle obtenu il y a 4 mois soit encore forcément pertinent aujourd’hui. Le simple choix des mots que j’emploie peut déjà faire fortement varier les résultats
    Malgré tout, je teste pour vérifier moi-même la valeur et la voir de mes propres yeux. Je ne publie pas spécialement les résultats détaillés de mes tests A/B en aveugle
    J’ai aussi vu d’autres personnes très mal faire les tests A/B en aveugle, et si la mesure est mauvaise, le test lui-même n’a plus aucun sens
    On essaie tous de résoudre ce problème ensemble, et il y a beaucoup de magie noire, donc je m’appuie fortement sur des hooks. Mon petit agent IA est sûrement lui aussi rempli de magie noire
    La seule chose dont je sois sûr, c’est que ça fonctionne pour moi. Sans ça, je ne sais honnêtement pas comment les gens travaillent aujourd’hui avec l’IA
    Je laisse le lien, mais ça ne veut pas dire que je le recommande, quoi que tu fasses. La plupart du temps, seuls d’autres ingénieurs logiciel l’utilisent, et c’est très spécialisé pour ce que j’ai besoin de faire. Au mieux, ça peut te donner des idées à implémenter toi-même
    https://github.com/notque/vexjoy-agent
  • Dire que « les bonnes idées remontent dans Codex/Claude » n’est vrai que si quelqu’un crée d’abord des outils comme RTK et que d’autres les essaient
    On peut très bien se contenter d’observer cette vague, mais des outils comme RTK, Headroom ou caveman mode peuvent réduire les tokens d’entrée et de sortie à traiter, et sur des LLM locaux cela peut produire des gains de vitesse mesurables
    On n’a pas encore assez de données pour dire si cela dégrade la qualité du résultat final, mais c’est amusant de mettre les mains dedans pour le découvrir
  • L’idée en elle-même est valable. Si l’on peut réduire le rapport signal/bruit de la fenêtre de contexte, c’est une bonne chose
    En revanche, rien ne prouve encore que RTK y parvienne réellement. J’aimerais voir des benchmarks sérieux sur la différence réelle produite par cet outil, plutôt que des formules sans intérêt comme « jusqu’à 90 % »
  • Plus largement, certaines optimisations que j’ai vues dans rtk pour des commandes comme git status semblent déjà être remontées dans la couche modèle
    Codex appelle désormais souvent des outils comme git status --short au lieu de git status

• C’est l’auteur de l’article. Pour être honnête, je l’ai écrit parce qu’en tant qu’ingénieur logiciel, rtk ai me paraissait très bizarre
  L’absence de nombre d’étoiles, l’absence de toute mention de la précision, et la façon dont la direction pousse ce genre de choses au nom de l’optimisation des coûts m’ont interpellé. Maintenant, les gens essaient d’envelopper toutes les commandes possibles avec rtk, de faire traiter toutes les commandes importantes, et même de décider quel type de sortie il faut recevoir

  • J’aimerais sincèrement avoir votre avis sur https://www.github.com/jahala/tilth
    C’est une approche différente de RTK, et elle a été benchmarkée avec une réduction d’environ 40 % du coût par bonne réponse
  • Je ne comprends pas pourquoi il n’a fourni absolument aucune métrique d’usage réel pour étayer ses affirmations. Ce n’était pas très utile

• La sortie des outils représente une grande part de ma propre sortie. Si je peux économiser 3,7 millions de tokens sur 3,9 millions de tokens d’entrée, je prends. Un token économisé reste un token économisé
  En tant qu’utilisateur de RTK, j’aimerais bien voir des benchmarks de précision, mais je n’ai encore vu aucune preuve que le modèle ait raté quelque chose d’important à cause de la compression
  Par philosophie de conception, la préservation de l’exactitude est traitée de manière très stricte, au point de revenir à la sortie d’origine si le filtre échoue. J’ai aussi regardé moi-même le code source de certaines commandes fréquentes, ça m’a plu, et j’estime que jusqu’ici RTK a gagné ma confiance
  Il y a aussi l’inquiétude que si git, cargo, npm ou grep changent un peu le formatage du terminal ou la mise en page des erreurs, les regex et les parseurs de RTK puissent casser, mais si le filtre échoue, il revient à la sortie d’origine. RTK est conçu pour éviter d’envoyer à l’agent un texte corrompu ou partiel
  Les inquiétudes sont légitimes, mais j’aimerais que les critiques soient étayées par des preuves. Je me demande si vous avez utilisé RTK et si vous avez trouvé des preuves qu’il ne préserve pas l’exactitude

  • En examinant les issues, j’en ai vu quelques-unes qui ont l’air franchement mauvaises
    https://github.com/rtk-ai/rtk/issues/2494
    https://github.com/rtk-ai/rtk/issues/2462
    https://github.com/rtk-ai/rtk/issues/2395
  • Il arrive que un token économisé ne soit pas vraiment un token économisé
    RTK retire des flags et d’autres informations. Parfois, cela pousse ensuite à dépenser plus de tokens pour les récupérer. Même si vous économisez 70 % des tokens sur cet appel d’outil, la métrique ne montre pas si vous avez dû faire 3 appels d’outil au lieu d’un seul
    Il faut aussi regarder si la sortie supprimée vous fait dépenser davantage de tokens de raisonnement
  • Je ne pense pas qu’affirmer une préservation très stricte de l’exactitude suffise
    Quand on considère l’écart de coût entre les modèles les plus récents et les modèles open weights en retard, ou entre le plus gros modèle et celui juste en dessous, il faut mesurer les performances avec énormément de prudence
    Ce n’est pas tant aux critiques d’apporter la preuve, c’est plutôt à RTK de démontrer qu’il ne dégrade pas les performances

• Le fond du problème, c’est qu’il existe d’innombrables outils qui prétendent améliorer l’IA, mais aucun moyen de mesurer si l’IA fonctionne réellement mieux
  Les grandes entreprises avec des produits populaires ont des méthodes. Quelque part entre l’analytics produit classique et l’évaluation de chatbot, elles déterminent si l’utilisateur réussit sa session. C’est leur métier
  Mais pour un développeur individuel qui lance 3 à 50 sessions par jour, il n’y a quasiment aucun moyen de savoir ce qui améliore réellement un LLM. Tout repose sur l’intuition
  Dans notre entreprise, nous avons toute une stack : notre harness préféré, nos modèles, nos skills, jusqu’à la structure du code. Il devrait exister un moyen de mesurer si cette configuration fonctionne pour nous, même à une échelle un millionième de Claude Code

  • Dans mon produit, je demande explicitement de poser la question à l’agent. Il y a de vrais exemples et de vrais dépôts que vous pouvez essayer vous-même
    https://gitsense.com
    https://github.com/gitsense/smart-ripgrep
    https://github.com/gitsense/smart-codex
    Je me soucie assez peu des économies moyennes de tokens. Ce qui m’intéresse davantage, c’est de savoir si l’IA évite de faire remonter des fichiers inutiles dans le contexte, ce qui peut affecter le raisonnement
    Après une tâche, il suffit de demander à l’agent : « Si tu avais connu le rôle des fichiers dès le départ, sur combien de fichiers penses-tu que tu n’aurais pas eu besoin de lire ? »
  • Les efforts nécessaires pour créer un benchmark valable sont énormes. C’est probablement vrai, et c’est justement ce qui énerve encore plus
    Il y avait déjà beaucoup de débats rien qu’avec les frameworks, et là c’est bien pire. On finit dans un affrontement entre ton intuition et la mienne. Qui aurait cru que des sorties non déterministes nous mèneraient jusque-là
  • Il y a pourtant une réponse. Ces outils devraient être benchmarkés non pas sur les simples économies de tokens, mais sur le coût par bonne réponse

• Je l’ai essayé moi-même, et comme les messages qui occupent 90 % de mon contexte ne sont pas compressés, seule une petite partie de l’usage total des tokens a été compressée
  C’est d’ailleurs écrit noir sur blanc si on lit l’article attentivement. Avec /context, on voit probablement que ce ne sont pas les appels d’outil qui consomment les tokens. Donc un proxy qui ne compresse que les appels d’outil n’a pas un gros impact, même s’il est vrai qu’il compresse ces appels par 8
  Dans les longues sessions de code, ce n’était pas très important pour moi
  “native/built-in Read or cat tools, the data is not intercepted by RTK's shell hook”

• Cet article apporte très peu de données à l’appui de sa réfutation, et il se lit en grande partie comme un texte généré par un LLM

• Chez Semble aussi, nous avons déjà reçu ce genre de plainte. Je pense qu’elle est légitime, mais construire ce type de benchmark est très difficile et coûteux à cause de la combinaison harness × modèle × MCP/CLI
  Dans le machine learning traditionnel ou les outils classiques, ne pas montrer de benchmark était généralement un signal d’alerte. Mais pour les outils LLM, je ne sais pas trop

• Il existe un moyen de faire en sorte que l’agent détecte la troncature si on le rend conscient de la compression RTK et qu’on lui donne une option de contournement. Moi, j’utilise RTK_DISABLE=1 de façon à restaurer tout le texte d’origine
  Ça marche bien, et oui. Comme seules les sorties de commandes sont compressées, du point de vue de la « compression », seuls les tokens d’entrée sont affectés

• Il est vrai que les CLI grand public et les outils développeur pourraient proposer des flags natifs --compact ou --json-stream adaptés à la consommation par les LLM, mais ils ne vont probablement pas le faire de sitôt
  C’est pour cela que des outils comme rtk, caveman et ponytail cherchent à réduire des coûts qui continuent de grimper. Dans une organisation de 2 000 personnes, on parle actuellement d’environ 2,5 millions de dollars, et tout le monde connaît et ajuste ce compromis
  Contrairement à ce qu’affirme l’auteur, nous sommes parfaitement conscients du compromis, et nous utilisons ces outils en forkant, benchmarkant et vérifiant que la qualité de sortie correspond à nos besoins. Ce n’est pas un usage aveugle
  Pour un développeur individuel, ce n’est peut-être pas indispensable, et il peut être plus judicieux d’auto-héberger un autre modèle pour réduire les coûts. Mais à l’échelle des organisations, c’est un point assez sensible
  C’est bien que ce genre d’article mette le sujet en lumière, mais comme pour les outils, il faut aussi lire ce type d’article avec un certain filtre

• J’ai essayé rtk gain sur Mac. Je n’ai pas pu tout vérifier sur ma machine de développement principale, que j’ai dû réimager à cause de problèmes de mémoire et où quelques éléments se sont emmêlés, mais sur Mac, cela a réduit d’environ 51 000 tokens en entrée et 23 000 tokens en sortie, avec un gain moyen de 3 secondes par commande
  Je ne comprends pas vraiment pourquoi ça suscite autant de colère, ni pourquoi il a absolument fallu en faire tout un billet
  Je ne sais pas qui envoie des stack traces vers RTK via un pipe. Moi, je ne l’utilise que pour un programme très spécifique, et y injecter la sortie du compilateur me semble idiot. Il suffit d’indiquer à l’agent d’utiliser RTK uniquement pour un ensemble précis de commandes