Fait partie du pilier réduire l'usage des tokens dans Claude Code. Cette page est le face-à-face : deux outils aux extrémités opposées de l'échelle d'effort, qui arrivent dans un ordre inattendu.

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

Aucun des deux ne vous fait économiser — mais caveman finit quatrième sur douze et headroom dernier, et la raison vaut mieux que le classement. Sur le benchmark ouvert des optimiseurs de tokens que je maintiens, caveman ressort statistiquement indiscernable de l'absence d'outil. headroom ressort 53 % plus cher que sans rien : le seul outil de la campagne dont la mesure montre qu'il est pire que ne rien faire. Le résumé honnête, donc : une blague fait match nul avec l'hypothèse nulle pendant qu'un vrai effort d'ingénierie perd contre elle. Je le dis d'emblée : je maintiens ce benchmark et je vends un outil concurrent. C'est précisément pour ça que l'intéressant ici n'est pas le tableau de scores, mais le mécanisme. Une fois qu'on voit pourquoi chacun atterrit là, on peut confronter le raisonnement à ses propres sessions au lieu de me croire sur parole.

Que fait réellement caveman ?

caveman est un skill JavaScript qui fait répondre le modèle en « caveman talk » télégraphique, plus un middleware qui compresse les descriptions d'outils. Il retire articles, remplissage et tissu conjonctif du registre de sortie du modèle, et rogne les schémas et descriptions livrés avec les définitions d'outils de l'agent. Il supporte plus de 30 coding agents, s'installe en drop-in et ne coûte rien à faire tourner : pas de runtime, pas de modèle, pas de proxy. C'est ouvertement une blague. Le nom le dit. Et il finit quand même quatrième. Ses limites sont le miroir de son empreinte :

Il optimise la sortie, et la sortie n'est pas là où vit la dépense agentique. Dans une session de coding agent, le contexte entrant domine la génération sortante d'environ un ordre de grandeur. Raccourcir les réponses du modèle compresse le petit côté du grand livre.
Le middleware sur les descriptions d'outils est réel mais borné. Les schémas d'outils sont payés une fois par prefix mis en cache, pas une fois par tour. Les rogner aide un peu, puis cesse d'aider.
Il dégrade le registre de sortie. Certains trouvent le style télégraphique inutilisable en pratique, surtout quand l'agent écrit des messages de commit, des commentaires ou de la doc qu'un humain relira.

La quatrième place signifie toujours aucune économie mesurable. Finir quatrième sur douze en dit long sur le champ, pas sur caveman.

Que fait réellement headroom ?

headroom compresse tout le message array avant chaque appel API. C'est un SDK Python plus un proxy CLI plus un serveur MCP, sous Apache 2.0, avec une communauté conséquente. Le pipeline aligne les frontières de cache, route chaque morceau de contenu vers un compresseur spécifique au format (JSON, code, texte, logs, diffs, HTML) choisi par un détecteur de contenu ML, score la pertinence du contexte, et expose un outil retrieve pour que le modèle puisse rappeler un original quand la version compressée ne suffit pas. Sur le papier, c'est de loin l'idée la plus complète, et à lecture normale des deux README, il devrait gagner cette comparaison haut la main. Le problème, c'est ce qui se passe dans une boucle :

Réécrire le message array à chaque appel combat le prompt caching. Les fournisseurs mettent en cache sur une correspondance exacte de prefix. Quand les décisions de compression changent d'un tour à l'autre — et elles changent, parce que le contenu change — le prefix change et le cache rate. Vous repayez alors le plein tarif en entrée pour du contexte déjà acheté à prix réduit. Cet effet seul peut engloutir tout ce que la compression a économisé.
Empreinte lourde. Python 3.10+, un modèle ModernBERT de 150M de paramètres, Magika pour la détection de contenu, 16 à 50 ms ajoutées par appel.
retrieve coûte un aller-retour. Quand la compression retire quelque chose dont le modèle avait besoin, le récupérer est un tour supplémentaire, et un tour supplémentaire réembarque toute la conversation.

Rien de tout cela ne veut dire que la compression ne marche pas. Mesurée sur une charge utile isolée, elle marche bien. Cela veut dire qu'une réécriture agressive à chaque appel, dans une boucle d'agent avec état et cache, peut coûter plus qu'elle ne rapporte.

Pourquoi l'astuce gratuite bat-elle l'outil coûteux ?

Parce qu'un effort placé au mauvais endroit est pire que pas d'effort du tout, et que l'empreinte de caveman est trop petite pour faire des dégâts. Tout le résultat tient dans cette phrase. caveman touche le petit côté de la facture avec un mécanisme qui ne peut pas se retourner contre vous : il atterrit sur zéro. headroom touche le grand côté avec un mécanisme qui perturbe le prefix mis en cache : il peut atterrir sous zéro. Dans une catégorie où la plupart des outils se massent autour de « aucune différence mesurable », la capacité à être activement négatif est le facteur distinctif — et elle appartient à la conception la plus ambitieuse. La leçon générale est inconfortable et utile : un ratio de compression mesuré sur une charge utile ne dit presque rien du coût de session. Le seul chiffre qui compte est ce que coûte une session complète de bout en bout, comportement de cache inclus. C'est pour ça que le benchmark mesure des sessions et non des ratios, et c'est pour ça que popularité et effet mesuré se révèlent décorrélés ici : les stars mesurent l'enthousiasme, pas les résultats.

Combien de mesure y a-t-il derrière ?

170 runs par outil, sur 17 tâches de code déterministes, résultats calculés sur les runs réussis uniquement. Ce volume existe à cause du bruit. La même tâche lancée deux fois peut coûter très différemment selon les fichiers que l'agent décide de lire. Une simple comparaison avant/après — la façon dont sont menés la plupart des benchmarks d'outils de ce domaine — ne peut pas séparer un effet réel de ce bruit. La plupart des verdicts « aucune économie mesurable » de la campagne, celui de caveman compris, auraient ressemblé à des victoires ou des défaites nettes dans un test à un seul run. Cela vaut dans les deux sens, et devrait vous rendre sceptique sur mes chiffres aussi. C'est la raison pour laquelle la méthode et le tableau complet des douze outils sont publics.

Lequel installer ?

Installez caveman si vous voulez une expérience gratuite de cinq minutes, et passez sur headroom sauf si vous compressez des charges utiles hors boucle d'agent.

Choisissez caveman pour prouver un point, ou si le registre de sortie télégraphique vous plaît vraiment. Il ne bougera pas votre facture, mais il ne l'abîmera pas non plus, et il ne coûte rien à essayer ni à retirer.
Choisissez headroom si vous compressez des charges utiles dans votre propre code applicatif — un pipeline batch, un service de résumé one-shot — là où aucune longue conversation en cache n'est perturbée par la réécriture. C'est le cadre auquel sa conception convient, et il y est bon.
Ne choisissez ni l'un ni l'autre si votre problème de tokens tient aux lectures de fichiers entiers et aux sorties d'outils non filtrées, parce qu'aucun des deux ne traite ça.

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 un canal, 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. Vérifiez-le sur la page du benchmark, où la méthode et les résultats complets sont publics, plutôt que de le prendre d'une page de comparaison que j'ai écrite.

À lire aussi :