Headroom : le compresseur de tokens qui n'utilise pas l'IA pour compresser l'IA
Il y a un paradoxe silencieux au cœur de nombreux systèmes d'intelligence artificielle modernes. Les ingénieurs construisent des agents sophistiqués, capables de raisonner, de planifier et de coordonner des séquences complexes d'actions. Puis ils regardent la facture mensuelle de l'API et se rendent compte que la dépense la plus importante n'est pas le raisonnement, ni la créativité, ni même la précision. C'est le trafic. Le volume pur et banal de texte que les composants s'échangent entre eux.
Tejas Chopra, ingénieur chez Netflix, s'est retrouvé exactement dans cette situation. Son agent IA brûlait deux cents dollars par jour non pas pour faire des choses extraordinaires, mais simplement pour transporter du contexte : sorties d'outils, logs système, fichiers de debug. Des données instrumentales, souvent redondantes, qui occupaient des fenêtres de contexte précieuses et étaient facturées token par token. Sa réponse est Headroom, un projet open-source qui, en quelques mois, a rassemblé plus de 45 000 étoiles sur GitHub et qui propose une solution aussi simple dans sa prémisse qu'intéressante dans ses détails : compresser ce qui entre dans l'LLM avant qu'il n'y entre vraiment.
La prémisse est que les agents IA modernes souffrent d'un problème structurel. À chaque étape de leur cycle de travail, ils lisent des fichiers, interrogent des bases de données, exécutent des commandes shell, reçoivent des réponses d'API externes. Tout ce matériel conflue dans le contexte qui est envoyé au modèle, et le modèle paie pour chaque token. Un log système de mille lignes, même s'il ne contient qu'une seule ligne critique, coûte comme mille lignes. Un tableau JSON de cinq cents résultats de recherche, même si vingt suffiraient pour répondre à la question, pèse comme cinq cents résultats.
Le marché des solutions a répondu de manière prévisible : des services hébergés qui compressent le texte en l'envoyant à leur tour à un autre LLM, lequel produit une version résumée à envoyer au modèle principal. L'élégance de cette solution est inversement proportionnelle à son efficacité économique, car elle introduit un coût supplémentaire dans le but d'en réduire un. Headroom fait un choix radicalement différent.
L'astuce : des algorithmes, pas des modèles
La décision de conception qui distingue Headroom de la plupart de ses concurrents est tellement à contre-courant qu'elle mérite d'être soulignée : pour compresser le contexte des LLM, Headroom n'utilise aucun LLM. Il utilise des algorithmes déterministes. Un logiciel classique, qui lit la structure des données et les réduit en suivant des règles précises, sans ambiguïté, sans variance, sans le coût d'une inférence supplémentaire.
Cette approche a des conséquences importantes sur trois dimensions : la vitesse, la prévisibilité et le coût. La compression d'un tableau JSON de 500 éléments nécessite environ 940 millisecondes sur CPU ; la même opération avec un modèle de langage nécessiterait des secondes, avec un coût non négligeable. La compression algorithmique produit toujours la même sortie pour une entrée donnée, ce qui la rend testable, auditable, prévisible en production. Et elle n'ajoute pas de dépendance envers un fournisseur externe au moment même où l'on cherche à réduire le budget API.
Le cœur de l'architecture est le ContentRouter, qui analyse le contenu entrant et l'oriente vers le compresseur approprié. Ce n'est pas une classification grossière : le routeur reconnaît les JSON structurés, les tableaux de chaînes, les tableaux numériques, les logs système, le code source, le texte en prose, les images. À chacun correspond une stratégie différente.
Le SmartCrusher s'occupe du JSON, qui représente la catégorie la plus fréquente dans les sorties des agents. Sa logique n'est pas simplement "garder les N premiers éléments" : il utilise l'algorithme Kneedle pour trouver le point sur la courbe de couverture des bigrammes où l'ajout d'éléments supplémentaires cesse d'apporter de nouvelles informations. Ensuite, il divise le budget ainsi obtenu : trente pour cent des premiers éléments du tableau (pour capturer le schéma), quinze pour cent des derniers (biais de récence), cinquante-cinq pour cent des éléments qu'un scoring par importance identifie comme des anomalies. Les erreurs, les exceptions, les valeurs aberrantes statistiques sont toujours préservées, même si elles dépassent le budget global. C'est un choix de conception qui révèle une compréhension claire du contexte d'utilisation : dans un agent qui fait du debug, perdre la seule ligne avec "FATAL" serait catastrophique.
Le CodeCompressor est techniquement le plus sophistiqué, et aussi le plus conservateur dans son comportement réel. Il utilise tree-sitter pour construire l'Abstract Syntax Tree (AST) du code source et pourrait théoriquement le réduire en éliminant les détails d'implémentation inutiles à la compréhension structurelle. En pratique, dans la configuration par défaut, le code source passe presque toujours sans modifications. Les raisons sont documentées honnêtement : les messages courts sont ignorés, le code dans les quatre dernières conversations est toujours protégé, et si l'utilisateur a utilisé des mots comme "analyse", "explique" ou "corrige" dans le message le plus récent, tout le code de la session est considéré comme intouchable. C'est une approche conservatrice qui reflète une priorité claire : mieux vaut gaspiller quelques tokens que risquer de briser le raisonnement du modèle.
Kompress-base est le seul composant qui introduit un modèle de machine learning, mais c'est un modèle local, qui tourne sur le matériel de l'utilisateur et ne nécessite pas d'appels externes. Entraîné sur des traces agentiques, il s'occupe du texte en prose (documentation, logs non structurés) et produit des réductions de l'ordre de quarante-cinq pour cent. Il est disponible sur HuggingFace sous le nom de kompress-v2-base.
Six compresseurs, un seul objectif
La galaxie de composants qui compose Headroom converge vers une seule garantie fondamentale : la compression est toujours réversible. C'est le cœur du système CCR, acronyme de Compress-Cache-Retrieve, qui résout le problème le plus épineux de la compression agressive : que se passe-t-il si le modèle a besoin des données originales ?
La réponse de Headroom est pragmatique et bien conçue. Lorsqu'un contenu est compressé, l'original est conservé dans un cache local (avec un TTL configurable, une heure par défaut). Le contenu compressé inclut un marqueur que le modèle peut voir, du type "1000 éléments compressés à 20. Récupérer avec hash=abc123". Parallèlement, Headroom injecte dans le schéma des outils disponibles un outil nommé headroom_retrieve, que le modèle peut invoquer en toute autonomie s'il juge insuffisants les vingt éléments reçus.
L'architecture est élégante car elle déplace la décision vers celui qui a le plus d'informations pour la prendre. Le modèle, qui connaît son propre raisonnement et ses propres besoins, décide de manière autonome si les données compressées suffisent ou s'il vaut la peine de récupérer l'original. La récupération est locale, avec une latence de l'ordre de la milliseconde. Le modèle peut également effectuer des recherches sémantiques à l'intérieur du cache à l'aide de BM25, recevant un sous-ensemble pertinent au lieu de l'intégralité de la charge utile.
En pratique, cette caractéristique est davantage un filet de sécurité qu'un mécanisme fréquemment activé : si la compression fonctionne bien, le modèle a rarement besoin de récupérer l'original. Mais savoir que le filet de sécurité existe est suffisant pour utiliser Headroom dans des contextes où la perte d'informations serait inacceptable.
Les autres composants complètent le tableau. Le CacheAligner stabilise les préfixes des messages afin de maximiser les cache hits sur les KV caches des fournisseurs, en particulier Anthropic et OpenAI, avec des économies supplémentaires qui s'ajoutent à la compression des contenus. L'IntelligentContext gère la fenêtre conversationnelle sur des sessions très longues, en éliminant les messages à faible pertinence (eux aussi mis en cache via CCR). La fonction headroom learn analyse les sessions échouées et écrit des corrections dans les fichiers de configuration des agents comme CLAUDE.md ou AGENTS.md, transformant les erreurs passées en instructions futures.
L'intégration avec les stacks existants se fait de trois manières distinctes. Sous forme de bibliothèque Python ou TypeScript, avec un simple appel compress(messages) avant d'envoyer au fournisseur. Sous forme de proxy local (headroom proxy --port 8787), qui intercepte les requêtes directes vers l'API sans modifier le code applicatif. Sous forme de serveur MCP, compatible avec Claude Code, Cursor, Codex et n'importe quel client MCP. Il existe également headroom wrap, une commande qui enveloppe directement les agents en ligne de commande. Le support déclaré couvre LangChain, LiteLLM, Vercel AI SDK, Agno et Strands.
Les chiffres : réels ou marketing ?
Les chiffres que présente Headroom méritent une lecture attentive, car ils mêlent des résultats convaincants à quelques points qui nécessitent une mise en contexte.
Les benchmarks sur les workloads réels sont les plus significatifs. Une recherche sur code avec cent résultats passe de 17 765 à 1 408 tokens, soit une économie de quatre-vingt-douze pour cent. Une session de debug SRE de 65 694 à 5 118 tokens, du même ordre de grandeur. Le triage de issues sur GitHub de 54 174 à 14 761, soit soixante-treize pour cent. Ce sont des scénarios plausibles pour un agent qui utilise intensivement des outils, et les chiffres internes de la pipeline de compression montrent des latences d'une milliseconde pour la plupart des opérations.
Les benchmarks sur la précision sont rassurants mais nécessitent une note méthodologique. Sur GSM8K (mathématiques élémentaires) et SQuAD v2 (question answering extractif), les résultats avec et sans Headroom sont pratiquement identiques ou légèrement meilleurs avec la compression, car l'élimination du bruit aide parfois le modèle à se focaliser. Mais ce sont des benchmarks standards, mesurés sur des contenus génériques. Il n'existe pas, du moins dans la documentation publique, de tests équivalents sur des domaines où la précision terminologique est critique : textes juridiques, fiches techniques médicales, contrats financiers. La documentation des limites est honnête sur ce point : Headroom est optimal pour les sessions avec de nombreux tool calls, pas pour les textes courts ou conversationnels, où la compression médiane relevée sur 50 000 sessions réelles n'est que de 4,8 %.
Il vaut la peine de s'attarder sur cette dernière donnée, car elle redimensionne certaines attentes. Les 4,8 % médians signifient que la moitié des sessions réelles bénéficient très peu de Headroom, car ce sont des conversations courtes, des questions uniques, des échanges sans accumulation de contexte. La valeur de l'outil émerge dans les workloads lourds, ceux avec accumulation de sorties d'outils, logs, fichiers : là, la compression grimpe à quarante-quatre-vingts pour cent. C'est un outil pour des cas d'usage spécifiques, pas une baguette magique universelle, et la documentation le dit explicitement dans la section des limitations.
Les données de télémétrie agrégée sont présentées avec une transparence méthodologique : 50 000 sessions proxy, 250 instances uniques entre mars et avril 2026, 1,4 milliard de tokens économisés, environ 4 000 dollars d'économies globales sur la flotte surveillée. Ces chiffres permettent de faire quelques calculs : 4 000 dollars sur 250 instances en deux mois signifient environ 8 dollars par mois et par instance. C'est une économie réelle, mais modeste pour la plupart des utilisateurs, ce qui ramène au point précédent sur l'hétérogénéité des workloads.
La latence supplémentaire introduite par le proxy est de 52 millisecondes en médiane, négligeable par rapport aux 2-10 secondes typiques d'une inférence LLM. Le P99 est de 4 secondes, ce qui pourrait être problématique pour des applications particulièrement sensibles à la latence. Dans des scénarios en temps réel ou de streaming haute fréquence, l'overhead doit être évalué au cas par cas.
Qui gagne, qui perd, que reste-t-il en suspens ?
Headroom est un projet jeune, né publiquement il y a trois mois et qui a grandi rapidement. La vitesse du développement, 157 releases en autant de jours, reflète un cycle d'itération très agressif. La licence Apache 2.0 est plus permissive que la MIT dans des contextes commerciaux, permettant l'utilisation dans des produits propriétaires avec moins de contraintes. La base de code est écrite principalement en Python (79 %) avec une couche critique en Rust (17 %) pour les opérations à faible latence.
Le point de concentration du projet est son auteur principal, Tejas Chopra. Les contributeurs sont plus de trente, et la communauté sur Discord est active, mais la vision architecturale et les décisions clés passent encore par une seule personne. Ce n'est pas inhabituel pour un projet à ce stade, mais c'est un facteur à considérer pour ceux qui envisagent une adoption en production à long terme. Il n'existe pas encore de livre blanc sur la sécurité, ni de certifications de conformité (RGPD, SOC2, HIPAA). La documentation sur la sécurité existe, le SECURITY.md dans le dépôt décrit la gestion des vulnérabilités, mais ne couvre pas des aspects comme le modèle d'isolation du cache local ou la gestion des identifiants et des PII qui peuvent transiter dans les logs compressés.
Pour ceux qui construisent des agents IA avec une utilisation intensive d'outils, Headroom représente une option concrète et bien documentée, avec une proposition de valeur claire et mesurable. Le choix de ne pas utiliser d'LLM pour la compression n'est pas seulement une distinction technique : c'est une garantie de comportement déterministe, d'absence de dérives, de coûts de compression prévisibles. Le système CCR résout élégamment le problème de la compression lossy avec une architecture de récupération à la demande qui préserve l'intégrité des informations.
Pour ceux qui, en revanche, utilisent les LLM principalement pour la conversation, l'écriture ou l'analyse textuelle sans accumulation de contexte provenant d'outils, l'impact sera marginal et l'overhead d'adoption ne vaut probablement pas l'investissement. L'outil est explicite à ce sujet dans ses propres limites documentées, ce qui est un signe de maturité de conception non négligeable.
La question ouverte la plus intéressante n'est pas technique : c'est de savoir si le problème que Headroom résout deviendra moins pertinent avec l'évolution des fournisseurs. OpenAI et Anthropic travaillent sur des fenêtres de contexte de plus en plus grandes et sur des mécanismes natifs de compression et de caching. Si le coût par token baisse de manière significative, ou si les fournisseurs proposent la compression as-a-service à des prix compétitifs, la niche de Headroom se réduit. Pour l'instant, dans ce moment de prix encore élevés et de contextes encore limités, le projet répond à un besoin réel avec des outils solides.
Le dépôt est public, la documentation est bien structurée, les benchmarks sont reproductibles avec python -m headroom.evals suite --tier 1. Pour ceux qui veulent l'évaluer sur leur propre workload spécifique, le point de départ le plus rapide est headroom perf, une commande qui analyse les sessions existantes et estime les économies potentielles avant de toucher à toute configuration de production.