La nouvelle astuce la plus populaire sur GitHub consiste à parler moins

La nouvelle astuce la plus populaire sur GitHub consiste à parler moins

Le dépôt qui connaît la croissance la plus rapide sur GitHub cette semaine est un projet Go nommé caveman, avec plus de 112 000 étoiles, et tout son principe repose sur une blague qui se trouve être juste. Son slogan dit : pourquoi utiliser beaucoup de token quand peu de token suffisent. C'est un skill et un proxy pour agents de codage qui prétend réduire l'usage de tokens d'environ 65 pour cent en faisant parler le modèle comme un homme des cavernes.

Retirez la blague, il reste une véritable affirmation d'ingénierie. L'essentiel de ce qu'un agent de codage échange n'est pas de l'information. C'est de l'échafaudage, de la politesse, de la reformulation et les préambules polis que les modèles de langage produisent par défaut. Si vous pouvez jeter tout cela sans jeter le sens, la session coûte moins cher et la fenêtre de contexte va plus loin.

La blague est aussi le diagnostic. Quand le coup gagnant consiste à faire paraître l'assistant plus bête, le goulot d'étranglement n'est pas l'intelligence. C'est le surplus de traitement.

La facture, c'est le contexte, pas le modèle

Il faut du temps pour comprendre comment les charges de travail des agents deviennent réellement coûteuses. Le modèle intuitif veut qu'on paie par réponse, donc une réponse longue coûte plus cher. Le modèle réel est qu'on paie par token de contexte auquel le modèle doit prêter attention, et ce contexte grandit à chaque tour.

Le temps qu'un agent ait lu un dépôt, exécuté quelques commandes, vu les résultats, écrit du code et lu les messages d'erreur, la conversation est énorme. Chaque nouveau tour traîne tout l'historique avec lui. La dixième étape coûte bien plus que la première, non parce que le modèle a ralenti, mais parce qu'il porte plus.

C'est pourquoi un outil qui élimine 65 pour cent des tokens n'est pas une optimisation marginale. Appliqué à un agent qui tourne pendant des heures, c'est la différence entre une session qui tient dans un budget et une autre qu'il faut redémarrer à mi-parcours.

Trois façons d'attaquer le même problème

Les autres projets portés par la même vague attaquent le problème sous des angles différents, et les comparer est instructif.

Headroom, un projet Python qui a gagné environ 13 000 étoiles en une semaine pour atteindre près de 39 000, est une couche de compression de contexte qui tourne comme bibliothèque, proxy ou serveur MCP. Il propose six algorithmes de compression et revendique des réductions de 60 à 95 pour cent. Le choix de conception important est qu'il fonctionne en local d'abord et qu'il est réversible, ce qui compte parce qu'une compression qui détruit l'information est pire que pas de compression du tout. Pouvoir décompresser signifie que l'agent peut encore récupérer ce qu'il a enfoui.

Xerj s'attaque à une habitude précise et très coûteuse. C'est un outil Rust qui indexe le code, les documents, les journaux et les PDF avec une seule commande, pour qu'un agent puisse interroger un index structuré au lieu de brûler des tokens en exploration grep et sed, cette boucle chercher, lire, rechercher qui consomme énormément de contexte pour quelques lignes pertinentes. Le projet revendique environ 40 fois moins de tokens que grep et reste compatible Elasticsearch, donc les clients existants continuent de fonctionner.

Mettez les trois côte à côte et un schéma apparaît. Caveman change la façon dont le modèle parle. Headroom change ce qui est mémorisé. Xerj change où le modèle regarde. Les tokens économisés sont les mêmes tokens, mais le levier est différent, et une chaîne d'outils mature finit par avoir besoin des trois.

Pourquoi l'astuce de l'homme des cavernes fonctionne du tout

L'approche de l'homme des cavernes ne devrait pas aussi bien fonctionner qu'on le dit, et il vaut la peine de comprendre pourquoi elle fonctionne.

Les modèles ajustés par instructions sont entraînés à être utiles dans un style particulier. Ils reformulent votre question avant de répondre. Ils résument ce qu'ils viennent de faire. Ils expliquent leur raisonnement en phrases complètes, concluent par une note amicale et formatent tout avec des titres. Rien de tout cela n'est exigé par la tâche, et tout cela est facturé au token.

Si vous demandez au modèle d'abandonner la politesse et de ne garder que les mots porteurs de sens, vous obtenez une sortie qui paraît brute et transmet presque la même chose. La densité d'information monte parce que le cérémonial disparaît. C'est la même raison pour laquelle une note d'ingénieur concise peut dire plus en dix mots qu'un ordre du jour de réunion en cent.

Le compromis est réel, cependant. Une sortie concise est plus difficile à parcourir pour un humain, et un raccourci ambigu crée des malentendus qui coûtent plus qu'ils n'économisent. Retirer les mots qui rendent l'intention explicite est un pari que le contexte environnant porte assez de sens, et ce pari échoue précisément quand la tâche est inhabituelle. La compression aide surtout sur le travail répétitif et nuit surtout là où la nuance compte, une règle à retenir avant de l'appliquer partout.

L'offre et la demande d'attention

Il y a une raison structurelle à l'explosion actuelle de cette catégorie, et elle n'a rien à voir avec un dépôt en particulier.

Les fenêtres de contexte sont devenues grandes, mais l'appétit pour les remplir aussi. Les agents qui lisent des dépôts entiers, gardent de longs historiques de tâches et coordonnent des sous-agents consommeront tout l'espace qu'on leur donne, parce que consommer du contexte est leur façon de faire le travail. Chaque augmentation de capacité est absorbée en quelques semaines, et la pression revient.

C'est une dynamique familière. Élargir les autoroutes ne réduit pas le trafic à long terme, parce que les gens répondent à un trajet moins cher en se déplaçant plus. Le contexte, c'est pareil. Une fenêtre plus grande ne met pas fin à la pénurie, elle redéfinit ce qui compte comme usage raisonnable, et la pénurie se réaffirme à un niveau supérieur.

Ce qui signifie que la compression n'est pas une solution provisoire. C'est une couche permanente de la pile, et les projets qui la réussissent finiront dans une position semblable à celle des bases de données et des caches : invisibles, sans éclat, et impossibles à retirer une fois que les gens en dépendent.

Ce qu'il faut vraiment surveiller

Le nombre d'étoiles est un mauvais guide ici, parce qu'un nom drôle voyage plus vite qu'un bon algorithme. Trois choses valent la peine d'être vérifiées avant d'adopter tout cela.

La première est la réversibilité. Une compression avec perte qui ne peut pas être annulée rend les bugs plus difficiles à trouver, parce que l'agent raisonne peut-être à partir d'un résumé qui a laissé tomber le détail qui comptait. La deuxième est son domaine d'application. Un proxy qui compresse tout le trafic sans discernement finira par avaler quelque chose de porteur, et la panne ressemblera à une hallucination du modèle plutôt qu'à un bug d'outillage. La troisième est la mesure. 65 pour cent de tokens en moins est une affirmation sur un type précis de session, et le seul chiffre qui compte est celui mesuré sur votre propre trafic.

Le point plus profond est que l'industrie a passé deux ans à courir après la capacité et découvre maintenant que l'efficacité est là où vit la prochaine vague de gains pratiques. Le modèle qui répond correctement est la condition de base. La chaîne qui répond correctement pour un dixième du coût est un produit. Caveman, Headroom et Xerj pointent tous vers la même vérité : dans le travail des agents, l'attention est la ressource rare et tout le reste n'est que comptabilité.