100K de contexte suffisent : compresser la mémoire plutôt qu'élargir la fenêtre

La fenêtre n'est pas le problème

Tous les quelques mois, un labo sort un modèle avec une fenêtre de contexte plus grande et la conversation repart de zéro : deux cent mille tokens, puis un million, puis deux millions. La promesse implicite, c'est que la mémoire est un problème de matériel et que quelqu'un continuera à l'agrandir.

billion-context, un projet TypeScript de ranxianglei qui grimpe depuis fin septembre, prend le contrepied dans son slogan : 100K de contexte, c'est suffisant. Pas "suffisant pour l'instant". Suffisant, si vous arrêtez de traiter la conversation comme un journal en ajout seul.

C'est un proxy qui se place entre votre agent de code et l'API du modèle. Les requêtes passent par lui, sont compressées, puis transmises. Les réponses sont réécrites au retour. Rien ne change côté modèle. L'argument : la partie chère n'a jamais été la taille de la fenêtre, mais ce qu'on s'acharnait à y mettre.

Comment marche la compression

Le proxy analyse chaque requête au format Anthropic ou OpenAI, fait tourner son noyau de compression sur la conversation, puis injecte quatre outils que le modèle peut appeler lui-même : compresser une plage de messages en un résumé, décompresser une plage quand les détails exacts redeviennent nécessaires, chercher par mot-clé dans les résumés compressés et les messages visibles, et vérifier l'occupation du contexte.

Le choix de conception important, c'est que c'est le modèle qui décide quand compresser, pas un seuil fixe. Le résumeur intégré d'un hôte se déclenche en général quand la fenêtre est pleine et remplace tout ce qui précède un point de coupe par un seul résumé impossible à annuler. billion-context compresse par petites plages, les garde réversibles et laisse intact le cache de préfixe.

C'est ce dernier point, le détail d'ingénierie qui compte. Le cache de préfixe, c'est ce qui rend les longues sessions d'agent abordables ; si chaque compression réécrit le début de la conversation, le cache rate et vous repayez plein tarif pour tout l'historique. Le projet annonce un taux de succès du cache de préfixe de 95-97% sur une session saine et un surcoût de la compression inférieur à 2%. Ce sont ses propres chiffres, et il fournit des commandes pour attribuer une baisse du taux à une cause, en général l'expiration du TTL du cache en amont ou un changement de modèle.

Le chiffre qui rend la promesse crédible

Les éditeurs claironnent des économies de tokens en permanence. Ce qui est inhabituel ici, c'est une étude longitudinale livrée avec le code : quatre mois et demi, trois hôtes, 174,327 appels de modèle, 18.76 milliards de tokens d'entrée cumulés sur un seul hôte et environ 24.7 milliards sur l'ensemble. Le rapport indique que les sessions les plus longues ont tenu de 8,584 à 12,049 appels, sans aucun dépassement de fenêtre sur des modèles à 204,800 tokens.

Zéro dépassement, c'est la phrase qui compte. Aucune session n'est morte parce que la conversation avait dépassé le modèle. Tout le reste de l'étude découle de là.

Cela redéfinit aussi ce que veut dire "session longue". La plupart des gens vivent les limites de contexte comme une dégradation lente : l'agent devient plus vague, oublie une contrainte d'il y a deux heures, se remet à relire des fichiers déjà lus. Quand la fenêtre est vraiment pleine, la session est généralement mauvaise depuis un moment. Une compression qui tourne en continu s'attaque à la dégradation, pas seulement à l'arrêt brutal.

Savoir si ça marche comme annoncé sur votre charge de travail est une autre question. Les chiffres sont auto-déclarés, le banc d'essai est l'usage de l'auteur, et "5 fois moins de tokens" dépend entièrement du degré de répétition de vos sessions. Une session qui lit quarante fichiers et en modifie trois se compressera à merveille. Une session qui lit un seul fichier énorme et raisonne ligne par ligne a bien moins de redondance à replier.

Ce que ça change dans la boucle quotidienne

La différence pratique apparaît au milieu, dans la partie ennuyeuse d'une longue tâche. Un agent qui mène un refactor a trois sortes de mémoire : ce qu'il a décidé, ce qu'il a lu, et ce qu'il a essayé puis abandonné. Une transcription brute garde les trois à la même résolution, et c'est pourquoi un refactor de quarante fichiers remplit une fenêtre de traces de pile qui ne servent plus à rien.

La compression permet à l'agent de garder les décisions en pleine fidélité, de replier les preuves en résumés, puis d'aller rechercher les lignes exactes seulement au besoin. C'est à peu près comme travaille un humain : vous vous souvenez d'avoir déplacé la validation dans le middleware, vous ne vous souvenez pas des six tentatives ratées avant.

Le mode de défaillance est tout aussi humain. Si un résumé laisse tomber la seule contrainte qui comptait, "cet endpoint doit rester rétrocompatible", l'agent la cassera allègrement quarante minutes plus tard, et la couche de compression vous aura fait économiser de l'argent tout en vous coûtant un bug. La réversibilité, c'est ce qui rend ça survivable : vous pouvez décompresser et vérifier ce que le résumé disait vraiment.

Pourquoi c'est devenu une catégorie

Au moins trois approches distinctes se disputent le même problème. La première est la réponse du labo : construire une fenêtre plus grande. La deuxième est celle du harnais : récupérer au lieu de se souvenir, et ne garder qu'un jeu de travail dans le contexte. La troisième, que représente billion-context : garder la conversation et la compresser sur place, de façon réversible.

Les compromis sont réels. Une fenêtre plus grande est la solution la plus simple et la moins contrôlable ; vous la payez à chaque appel, que l'historique soit pertinent ou non. La récupération est la moins chère mais perd la continuité, parce que l'agent ne sait pas ce qu'il a oublié. La compression sur place tente de tenir continuité et coût en même temps, au prix de s'installer dans le chemin de vos requêtes.

C'est ce dernier coût qu'il faut peser. Un proxy au milieu voit chaque prompt et chaque complétion. Pour un développeur solo, très bien. Pour une entreprise avec des règles sur les données, c'est une conversation de conformité, et "on a lu le code, c'est bon" n'est pas la même chose qu'un audit.

Il y a aussi la petite question de la licence. L'article technique est en MIT et vit dans le dépôt. La licence du dépôt lui-même est signalée comme "Other" plutôt qu'une licence OSI standard. Si vous déployez ça en entreprise, cette distinction finira par ressortir.

L'implication dérangeante

Si la compression marche assez bien pour que 100K suffisent, alors une bonne partie du marketing sur les fenêtres de contexte vise un problème moins cher à résoudre en logiciel. Ça ne rend pas les grandes fenêtres inutiles, un document de 400 pages doit bien tenir quelque part, mais ça veut dire que "on a un million de tokens" est un argument plus faible qu'il n'y paraît. C'est comme vanter un plus gros réservoir au lieu d'une meilleure consommation.

Ça change aussi la façon d'écrire un agent. Si la mémoire est compressible, il faut encourager l'agent à noter ce qu'il apprend sous forme structurée, parce que des notes structurées se compressent bien mieux que des logs bruts. Une phrase comme "le middleware d'auth lit le tenant dans le header, pas dans le cookie" vaut mille lignes de traces de pile. La couche de compression récompense une bonne tenue de compte, et c'est une chouette propriété pour un outil.

Le projet dépasse le millier d'étoiles et tourne autour de 400,000 téléchargements npm par mois, avec des badges pour plus de vingt clients. Ce n'est pas une base d'installation de hobby. Ça suggère que la douleur est réelle, largement partagée, et que la réponse vers laquelle les gens tendent n'est pas un zéro de plus dans la taille de la fenêtre.

C'est ça, la conclusion utile, quel que soit l'outil que vous finirez par utiliser. Le contexte est un budget, pas un récipient. Les équipes qui le traitent comme tel en feront toujours plus par dollar, et celles qui attendent une fenêtre plus grande continueront à payer le privilège de ne pas décider ce qui compte.