Fait partie du pilier réduire l'usage des tokens dans Claude Code. Cette page est le face-à-face précis : deux optimiseurs open source souvent comparés, mesurés sur le même benchmark.

headroom ou rtk : lequel est le meilleur optimiseur de tokens ?

Sur le coût de session mesuré, aucun des deux ne tient ce que son README laisse espérer — mais rtk est le plus sûr des deux. Sur le benchmark ouvert des optimiseurs de tokens que je maintiens, rtk termine à peu près à l'équilibre : les sessions coûtent autant que sans aucun outil. headroom termine 53 % plus cher que sans rien, dernier des douze outils testés — le seul dont le benchmark montre qu'il est mesurablement pire que ne rien faire. Ce n'est pas le résultat auquel on s'attend, et il mérite une explication plutôt qu'un tableau de scores. Les deux projets sont bien construits et traitent tous les deux un vrai problème. L'écart entre ce qu'ils font et ce qui apparaît sur la facture tient à l'endroit du pipeline où ils interviennent — et, pour headroom, à un arbitrage réel qui joue contre vous dans une boucle d'agent. Autant être franc sur l'évidence : je maintiens le benchmark et je vends un outil concurrent. Ce que je peux apporter d'utile, ce n'est donc pas le classement, c'est le mécanisme. Une fois compris pourquoi chaque outil atterrit là où il atterrit, vous pouvez confronter le raisonnement à votre propre usage au lieu de me croire sur parole.

Que fait rtk, concrètement ?

rtk est un proxy CLI en Rust qui filtre les sorties de commandes shell avant qu'elles n'atteignent le modèle. Vous lancez git status, cargo build ou pytest, rtk intercepte la sortie, retire ce dont un modèle de langage ne tire rien, et transmet une version compactée. Il embarque plus de 100 filtres spécifiques — git, cargo, npm, pytest, docker, aws — et s'intègre par un hook transparent : vous ne changez pas votre façon de taper les commandes. L'ingénierie est bonne. Binaire unique, moins de 10 ms de surcoût au démarrage, aucun coût en tokens pour l'intégration elle-même, et rtk gain rapporte ce qui a été économisé. Si vous passez la journée dans une boucle très orientée terminal avec des outils de build verbeux, ces blobs-là rétrécissent visiblement. Ses limites sont structurelles, pas le fruit d'une négligence :

Le hook ne couvre que bash. Il ne touche pas aux outils intégrés de l'agent — Read, Grep, Glob. Dans une session Claude Code typique, c'est de là que vient l'essentiel des tokens, ce qui explique à soi seul que l'économie mesurée soit proche de zéro.
Filtrage de sortie uniquement. Pas de recherche sémantique, pas de compression structurelle des fichiers source, pas de chargement paresseux des manifestes MCP.
Pas de support natif sur Windows PowerShell.

rtk optimise donc bien un canal et laisse les canaux plus gros intacts. Faire jeu égal sur une mesure à l'échelle de la session en est la conséquence honnête, pas un bug.

Que fait headroom, concrètement ?

headroom est bien plus ambitieux : il compresse l'intégralité du tableau de messages avant chaque appel API. C'est un SDK Python doublé d'un proxy CLI et d'un serveur MCP, sous Apache 2.0, avec une vraie communauté. Le pipeline aligne les frontières de cache, route chaque contenu vers un compresseur spécifique à son format (JSON, code, texte, logs, diffs, HTML) via un détecteur ML, note la pertinence du contexte, et expose un outil retrieve pour que le modèle récupère un original quand la version compressée ne suffit pas. Sur le papier, c'est l'idée la plus complète. Elle opère sur toute la fenêtre de conversation plutôt que sur la sortie d'un seul outil, et ses compresseurs par format affichent des taux de réduction élevés pris isolément. Le hic, c'est ce qui se passe une fois mis en boucle :

Réécrire le tableau de messages à chaque appel se bat contre le cache de prompt. Les fournisseurs mettent en cache sur une correspondance exacte de préfixe. Si les décisions de compression changent d'un tour à l'autre — et elles changent, puisque le contenu change — le préfixe change et le cache rate. Vous repayez alors plein tarif un contexte déjà acheté au rabais. Cet effet seul peut engloutir les gains de la compression.
Empreinte lourde. Python 3.10+, un modèle ModernBERT de 150M paramètres, Magika pour la détection de contenu, 16 à 50 ms par appel.
L'aller-retour retrieve a un coût. Quand la compression retire quelque chose dont le modèle avait besoin, aller le rechercher est un tour supplémentaire — qui retransporte toute la conversation.

Voilà pourquoi headroom atterrit là. Ce n'est pas que la compression ne marche pas : mesurée sur une charge unique, elle marche bien. C'est que réécrire agressivement à chaque appel, dans une boucle d'agent cachée et à état, peut coûter plus que ça ne rapporte.

Pourquoi compresser davantage coûte-t-il parfois plus cher ?

Parce que dans une session d'agent, vous êtes facturé sur toute la conversation, rejouée à chaque tour — et c'est le cache de prompt qui rend ça soutenable. Le modèle est sans état. Le tour 20 renvoie tout des tours 1 à 19. Les fournisseurs facturent l'entrée mise en cache avec une forte remise précisément parce que ce rejeu est très prévisible. Tout ce qui perturbe le préfixe caché transforme un rejeu remisé en rejeu plein tarif. Un compresseur qui réécrit l'historique à chaque appel est, structurellement, une machine à invalider le cache — aussi bon que soit son taux de compression pris isolément. La leçon dépasse ces deux outils : un chiffre de réduction de tokens mesuré sur une charge unique ne dit presque rien du coût de session. Le seul chiffre qui compte, c'est ce que coûte une session complète de bout en bout, comportement de cache inclus. C'est toute la raison pour laquelle j'ai construit le benchmark pour mesurer des sessions et non des taux de compression.

Lequel installer ?

Prenez rtk pour un gain sûr et peu coûteux sur les sorties de commandes verbeuses, et laissez headroom de côté sauf usage hors boucle d'agent.

Choisissez rtk si votre workflow est très orienté terminal, que vous êtes sur macOS ou Linux, et que vous voulez quelque chose qui n'aggravera pas la situation. Faire jeu égal sur le benchmark veut quand même dire que le problème des sorties verbeuses est réellement traité ; simplement, vous ne le verrez pas sur la facture.
Choisissez headroom si vous compressez des charges dans votre propre code applicatif — un pipeline batch, un service de résumé one-shot — là où aucune longue conversation cachée ne subit la réécriture. C'est le cadre auquel sa conception convient vraiment.
Ne choisissez ni l'un ni l'autre si votre problème de tokens, ce sont les lectures de fichiers entiers et les appels d'outils non filtrés : aucun des deux ne traite ça.

Et vérifiez mes chiffres plutôt que de leur faire confiance. Lancez une session que vous reconnaissez vraiment, avec et sans l'outil, et comparez le coût total — pas les tokens économisés sur un blob.

Qu'est-ce qui fait vraiment bouger le chiffre ?

Les leviers qui apparaissent sur une facture sont ceux qui empêchent le contexte inutile d'entrer dans la conversation, plutôt que de le compresser une fois arrivé : récupération ciblée au lieu de lectures de fichiers entiers, filtrage des sorties verbeuses sur tous les outils et pas seulement bash, lecture de la structure avant les implémentations complètes, et chargement des manifestes MCP à la demande plutôt qu'au démarrage. C'est la conception sur laquelle Tokenade est bâti — il se place entre l'agent et ses outils et applique ces leviers automatiquement, y compris le repliement des résultats MCP tiers à la frontière, sans réécrire l'historique de conversation derrière le cache du fournisseur. Sur le même benchmark ouvert, il réduit le coût de session de 39 % sur les longues sessions par rapport à l'absence d'outil. Je préfère que vous le vérifiiez sur la page du benchmark, où la méthode et le tableau complet des douze outils sont publics, plutôt que de le prendre d'une page de comparaison que j'ai écrite.

À lire aussi :

Alternatives à headroom — le champ complet, si headroom ne convient pas
Meilleurs optimiseurs de tokens pour Claude Code — le comparatif classé
Benchmark des optimiseurs de tokens — méthode, campagne et résultats complets
Comment réduire l'usage des tokens dans Claude Code — les leviers, indépendamment de l'outil

headroom vs rtk : lequel réduit vraiment la facture ?