rtk : un proxy Rust en binaire unique qui retire 60 à 90 % de la sortie de commandes lue par votre agent

Depuis un an, la manière dont les agents de codage dépensent leur budget a changé sans bruit. Le modèle lit désormais beaucoup plus de tokens qu'il n'en écrit. À chaque commande shell lancée par l'agent, qu'il s'agisse d'une suite de tests, d'un état git, d'une liste de répertoires ou de la compilation d'un projet de taille moyenne, la sortie complète entre telle quelle dans la fenêtre de contexte. Un journal de compilation peut atteindre plusieurs milliers de lignes, dont seule une poignée influence la décision suivante. Le reste est facturé au token, dilue l'attention du modèle et rapproche la session de sa limite de contexte, ce qui force un résumé ou une troncature plus tôt. rtk, projet open source de l'équipe rtk-ai, vise précisément ce gaspillage négligé. Son slogan est franc : un proxy CLI haute performance qui retire jusqu'à 90 % de la sortie bash lue par votre agent.

Sur le plan du positionnement, rtk n'est ni un nouveau framework d'agents ni une nouvelle passerelle de modèles. C'est une couche mince entre l'agent et le shell. Sans lui, l'agent appelle une commande et lit directement la sortie standard. Avec lui, la même commande passe par le proxy, qui l'exécute, filtre et compresse le résultat, puis transmet au modèle une version plus courte. Le chiffre mis en avant est une réduction de 60 % à 90 % des tokens, et le README formule la borne haute comme « jusqu'à environ 90 % ». Il s'agit d'affirmations des mainteneurs, et le ratio dépend fortement de la commande. Une sortie bruyante et répétitive, comme les journaux d'installation de dépendances ou la progression détaillée de tests, offre une grande marge de compression. Une sortie déjà courte n'en offre presque aucune. Il faut donc voir le haut de la fourchette comme un meilleur cas, pas comme une moyenne.

Les choix d'ingénierie méritent l'attention, car ils ne sont pas accidentels. Une boucle d'agent émet des commandes à cadence élevée, et une seule tâche peut en déclencher des dizaines, voire des centaines. Si le proxy dépend d'un interpréteur ou d'un environnement d'exécution lourd, la latence de démarrage se paie à chaque appel et finit par se sentir, tout en ajoutant des dépendances d'environnement à maintenir. Un exécutable natif sans dépendance externe garde le surcoût par appel très bas, s'installe en le plaçant dans le chemin de recherche et se comporte de manière identique dans les conteneurs, les machines d'intégration continue et les portables des développeurs. Le dépôt propose une formule Homebrew, adopte la licence permissive Apache-2.0, affiche un badge de contrôle de sécurité de l'intégration continue et fournit son README en sept langues : anglais, français, chinois, japonais, coréen, espagnol et portugais. Rien de spectaculaire, mais l'ensemble indique un projet qui vise une adoption réelle plutôt qu'une démonstration de week-end.

Toute compression est une décision sur ce qu'on jette, et il faut l'affronter directement. Un lecteur humain qui rate une ligne d'avertissement dans un long journal perd souvent peu. Un agent qui rate une erreur critique peut poursuivre sur une hypothèse fausse, consommer plusieurs tours de plus et finir par coûter davantage que sans compression. Évaluer un outil comme rtk uniquement sur les tokens économisés est donc une erreur. La bonne mesure est le coût par tâche menée à bien. Une procédure raisonnable consiste à prendre un échantillon représentatif des tâches réelles de l'équipe, à exécuter chacune plusieurs fois avec et sans proxy, et à relever le taux d'achèvement, le nombre de tours et le total de tokens. Les chemins d'échec méritent un examen particulier : erreurs de compilation, assertions en échec, traces de pile et codes de sortie doivent être conservés en entier, pas traités comme du bruit. Prévoyez aussi une issue de secours qui permette à l'agent de lire la sortie brute quand il semble perdu.

L'observabilité est une question voisine, facile à négliger. Dès qu'un proxy se trouve dans le chemin, l'équipe doit savoir ce qu'il a supprimé, faute de quoi l'analyse après incident relève de la conjecture. Une bonne conception laisse une trace pour chaque compression : longueur d'origine, longueur compressée, nombre de segments repliés et, si possible, un moyen de retrouver le texte brut pour comparaison. Les économies de tokens cessent alors d'être un chiffre mystérieux et deviennent un indicateur d'ingénierie que l'on peut auditer et ajuster. Dans les environnements réglementés, une dernière question se pose avant l'adoption : la sortie brute complète reste-t-elle conservée localement pour la conformité et le débogage ? En prenant du recul, rtk illustre un mouvement plus large : l'ingénierie du contexte descend de la couche du prompt vers la couche des outils. Pendant deux ans, l'attention de l'industrie s'est portée sur la compression de prompts, la réutilisation de caches et le filtrage par recherche. À mesure que les agents sont devenus des boucles de longue durée, les résultats d'outils sont devenus la principale source de contexte, et tailler à la frontière de l'outil est souvent moins cher et plus prévisible que résumer après coup. L'approche complète d'ailleurs le cache de prompts au lieu de le concurrencer : le cache baisse le prix unitaire d'un préfixe répété, tandis que le proxy réduit la quantité de matière qui entre dans ce préfixe, si bien que les deux effets s'additionnent. Le projet rappelle aussi qu'économiser ne passe pas toujours par un modèle plus petit. Il suffit parfois de demander au modèle de lire moins de ce dont il n'a pas besoin.

Un peu de retenue reste de mise. À la date de rédaction, les règles de filtrage exactes, l'éventail des commandes bien prises en charge et le banc d'essai derrière la fourchette de 60 % à 90 % doivent être vérifiés dans la documentation du dépôt et par vos propres mesures. Nous n'avons pas reproduit ces chiffres de façon indépendante, et il ne faut donc pas les inscrire comme un fait dans un budget. Pour les équipes qui s'appuient beaucoup sur des agents de codage, la voie pragmatique est de piloter l'outil sur un projet non critique, de collecter une semaine de dépenses en tokens et de taux de réussite, puis de décider du déploiement. Si les données le confirment, rtk offre une réduction visible des coûts pour un effort modeste. Sinon, l'exercice aura au moins montré où vos agents dépensent leur argent.