headroom vs codegraph : compresser ou naviguer ?

L'un compresse la conversation avant chaque appel API, l'autre évite à l'agent d'avoir à tant lire. Une seule de ces stratégies survit à une session longue.

Profile photo of Paul Irolla

Par Paul Irolla

Founder · AI & developer tools · Tokenade

Docteur en IA · conçoit des outils d'optimisation de tokens pour agents de code

Voir la page de l'auteur
7 min de lecture
Résumer avec l'IA
Citer cette page
Fait partie du pilier réduire l'usage des tokens dans Claude Code. Cette page oppose les deux stratégies les plus discutées de la catégorie, et elles ne se mesurent pas pareil.

headroom ou codegraph : lequel est le meilleur ?

codegraph, au vu des preuves disponibles — mais l'intéressant, c'est pourquoi la compression perd contre la navigation ici. codegraph publie −35 % de coût et −71 % d'appels d'outils sur sept dépôts, et termine à peu près à l'équilibre sur mon benchmark de sessions longues. headroom termine 53 % plus cher que sans aucun outil, dernier des douze outils testés. C'est un résultat frappant pour un projet bien construit et très suivi : il mérite un mécanisme plutôt qu'un tableau de scores. Je maintiens le benchmark ouvert et je vends un outil concurrent. Confrontez le raisonnement à vos propres sessions plutôt que de me croire sur parole.

Que fait headroom exactement ?

Il compresse l'ensemble du tableau de messages avant chaque appel API. SDK Python, proxy CLI et serveur MCP, Apache 2.0, environ 18,7k étoiles. Le pipeline tourne en trois étapes : CacheAligner stabilise le préfixe statique du prompt en déplaçant timestamps et UUID en queue non cachée, ContentRouter envoie chaque contenu vers un compresseur spécifique à son format via un détecteur ML — JSON, code, texte, logs, diffs, HTML — et IntelligentContext note ce qui reste sur six dimensions de pertinence. C'est réversible, et ça compte : les originaux restent dans un cache LRU local et le modèle reçoit un outil headroom_retrieve injecté pour en récupérer un, avec sous-recherche BM25 optionnelle. Les chiffres par charge de travail sont forts — 92 % sur les résultats de recherche de code et les logs d'incidents SRE, 73 % sur le triage d'issues. Alors pourquoi le coût de session monte-t-il ? Parce qu'il réécrit la fenêtre à chaque appel, et que la fenêtre est ce que les fournisseurs mettent en cache. Le cache de prompts ne paie que si le préfixe est identique octet pour octet d'un tour à l'autre. Quand les décisions de compression changent entre les tours — et elles changent, puisque le contenu change — le préfixe change, le cache rate, et vous repayez plein tarif un contexte déjà acheté. CacheAligner existe précisément pour combattre cela, ce qui montre que le projet a identifié le risque. Sur une longue boucle d'agent, ça ne suffit pas. Il y a un second coût. Quand la version compressée ne suffit pas, le modèle appelle headroom_retrieve et rapatrie l'original : vous avez donc payé la copie compressée et l'original, plus l'aller-retour. Sur une tâche courte c'est rare. Sur une session longue, ça s'accumule. L'empreinte est lourde aussi : Python 3.10+, un modèle ModernBERT de 150M de paramètres, Magika pour la détection de contenu, et 16 à 50 ms de surcoût par appel.

Que fait codegraph exactement ?

Il supprime le besoin de lire, au lieu de réduire ce qui a été lu. tree-sitter parse vos sources vers un graphe de connaissances SQLite FTS5, servi en MCP : analyse d'impact, graphe d'appels, recherche de symboles, sur plus de vingt langages et quatorze frameworks. L'agent demande où une fonction est utilisée au lieu d'ouvrir quatre fichiers pour le découvrir. Ses forces pratiques :
  • Un runtime Node.js embarqué. Aucune version à gérer, multi-plateforme, et un installeur interactif qui détecte huit agents et écrit lui-même la configuration MCP.
  • Un routage par framework sur quatorze frameworks, y compris des rares comme Drupal et Vapor.
  • Un file watcher débouncé avec bannières d'obsolescence, pour que l'agent sache quand son index est en retard sur l'arbre de travail au lieu de répondre avec assurance à partir de données périmées.
Son −71 % d'appels d'outils est la moitié la plus fiable de son benchmark. Moins d'appels découle mécaniquement du fait d'avoir un index, et cela se vérifie en une session. Le −35 % de coût est en aval et montre une vraie variance d'une exécution à l'autre — un écart sur quatre runs sur Tokio, d'après codegraph lui-même. Ce qu'il ne fait pas : aucun filtrage de sorties, donc les sorties shell bavardes arrivent en taille réelle ; recherche par mots-clés FTS5 seulement, pas de recherche sémantique ; aucun report des manifestes MCP ; aucune compression structurelle des fichiers que l'agent ouvre quand même.

Compression contre navigation : laquelle généralise ?

La navigation, parce qu'elle ne se bat pas contre le cache du fournisseur. Toute la différence tient dans cette ligne. Un index change ce que l'agent demande. Un compresseur de fenêtre change ce que voit le fournisseur, et le fournisseur a bâti un modèle économique sur la stabilité de ce texte. Tout outil qui réécrit le préfixe dépense des hits de cache pour acheter du volume de tokens, or l'entrée en cache est facturée une fraction de l'entrée fraîche chez tous les grands fournisseurs. Échanger l'un contre l'autre est un mauvais taux de change. Cela explique aussi comment les chiffres par charge de headroom peuvent être honnêtes et son résultat de session mauvais quand même. 92 % sur un résultat de recherche de code, c'est réel. C'est mesuré sur une charge isolée, sans l'invalidation de cache que cette même réécriture provoque au tour suivant. Rien de tout cela ne condamne la compression de fenêtre. Cela en fait une stratégie dont le gain dépend entièrement de la stabilité entre les tours — condition bien plus facile à remplir dans un pipeline batch que dans une boucle d'agent interactive.

Que ratent-ils tous les deux ?

  • Les sorties de commandes. codegraph n'y touche pas. headroom les compresse dans la fenêtre, mais seulement après qu'elles ont été produites et payées une fois en limite d'outil.
  • Les lectures de fichiers entiers pour éditer. Un index dit quel fichier ; il ne le réduit pas. Un compresseur le réduit et met le cache en danger.
  • 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.
  • Les relectures. Le même fichier entrant quatre fois en contexte coûte quatre fois. Un index en réduit la probabilité ; aucun des deux ne déduplique.

Lequel choisir ?

Prenez codegraph si vous voulez le pari le plus sûr et l'installation la plus simple. C'est celui qui a un chiffre publié, un installeur sans friction, et un mode de défaillance — un index périmé — qui se signale. Prenez headroom si votre charge est batch plutôt qu'interactive : des payloads longs et stables traités une fois, où l'alignement de cache n'est pas invalidé à chaque tour, et où 92 % sur un gros blob JSON est toute l'histoire. C'est un vrai cas d'usage ; ce n'est simplement pas une boucle de code agentique. Ne prenez ni l'un ni l'autre si l'essentiel de votre dépense est en sorties de commandes. Aucun des deux n'est positionné sur ce canal d'une façon qui survive à une session.

Comment appliquer ça aujourd'hui

  1. Regardez votre taux de hit de cache avant d'installer quoi que ce soit qui réécrit la fenêtre. S'il est élevé, un compresseur dépense votre meilleur actif.
  2. Comptez les appels d'outils sur une session. C'est la métrique qu'un index déplace, et celle que vous pouvez vérifier vous-même.
  3. Répartissez la dépense par canal — sorties shell, lectures de fichiers, historique de conversation — avant d'attribuer un résultat à un outil.
  4. Remesurez après une semaine, pas après une tâche. Ces deux outils n'ont pas la même allure aux deux échelles, et c'est la semaine que vous payez.

Ce qui tourne mal (anti-patterns)

Lire un taux de compression par charge comme une économie de session. 92 % sur un blob et 53 % plus cher sur une session sont tous deux vrais de headroom, et ne se contredisent pas. Ignorer le cache de prompts. C'est le plus gros levier des tarifs actuels, et c'est celui qu'un réécriveur de fenêtre dépense en silence. Prendre −35 % pour une garantie. Médiane publiée par l'éditeur sur sept dépôts, avec une variance visible. De bonne foi, et un échantillon quand même. Empiler un compresseur au-dessus d'un index. L'index réduit ce qui entre dans la fenêtre ; le compresseur déstabilise ensuite le préfixe que l'index venait de rendre petit. Vous cumulez les inconvénients des deux.
À lire aussi :

Classé n°1 au Token-Harness Optimizer Leaderboard.

Tokenade est classé n°1 au Token-Harness Optimizer Leaderboard — un benchmark de bout en bout des optimiseurs de tokens, mesuré sur de vraies sessions de code. Installez-le une fois, il agit sur chaque prompt. Compatible avec Claude Code, Cursor, Codex, Copilot et plus.