caveman : réduire le coût en tokens des agents de code en parlant comme un homme des cavernes

Contexte et définition du problème

Les agents de programmation facturent à la token. Chaque token coûte de l'argent, et l'agent paie deux fois : pour ce qu'il écrit et pour ce qu'il lit. L'écriture, c'est la réponse. La lecture, ce sont tous les retours des outils : journaux, sorties de tests, fichiers JSON, diffs et résultats de recherche. Les deux postes s'additionnent sur la facture. Le projet caveman, publié par JuliusBrussee sur GitHub, s'attaque aux deux côtés. Il est né d'une plaisanterie en avril 2026. Selon le README, il a atteint la première place sur Hacker News, et le dépôt dépasse aujourd'hui les 109 000 étoiles. Ces chiffres viennent du projet lui-même, et la popularité ne prouve pas que la technique fonctionne. Ce sont les mesures qui le prouvent, et elles sont au cœur de cet article.

Le problème tient en une phrase : la plupart des agents écrivent comme une lettre de motivation et lisent comme une lance à incendie. La première moitié relève du style. Le modèle ajoute des préambules, des reformulations et des formules de politesse. La seconde relève de la plomberie. Les sorties d'outils sont brutes, verbeuses et, pour la question posée, largement redondantes. Le titre du README affirme que le projet « réduit de 65 % les tokens ». Ce chiffre vient d'un argument commercial. Les mesures disponibles sont plus étroites, et l'une d'elles émane du projet lui-même. Cet article les sépare, car un lecteur qui les additionne surestimerait l'économie.

Architecture centrale et principes techniques

caveman compte trois composants, chacun installable seul. Le skill est un fichier de règles. Il demande à l'agent de répondre dans une prose télégraphique, à la manière d'un homme des cavernes. Le README indique qu'il fonctionne avec plus de trente agents, dont Claude Code, OpenAI Codex, Gemini CLI, Cursor et Windsurf. La commande d'installation est `npx skills add JuliusBrussee/caveman -g`. Le skill ne modifie que la prose du modèle. Il ne touche pas aux sorties d'outils. Le proxy tourne sur la machine de l'utilisateur, entre l'agent et le fournisseur du modèle. Avant l'envoi d'une requête, il compresse les résultats d'outils : journaux, JSON, diffs et sorties de tests. L'original est stocké octet par octet dans une base SQLite locale, avec un identifiant de récupération. Si le modèle a besoin du texte complet, il appelle l'outil `caveman_retrieve`. Le README précise que le proxy transmet l'authentification sans modification, de sorte que le fournisseur reçoit les identifiants de la requête tels quels.

Le middleware s'adresse aux développeurs qui construisent leurs propres agents. Il enveloppe un seul appel dans LangChain, le Vercel AI SDK, le client OpenAI ou le client Anthropic. Les gros résultats d'outils sont remplacés par des copies plus courtes avant d'atteindre le modèle. L'historique de la conversation conserve chaque octet original, de sorte que le modèle peut relire la version complète lorsque la version courte ne suffit pas. Les trois composants reposent sur un même principe : la compression doit être réversible. Le texte raccourci n'est qu'une vue, et l'original reste accessible par un identifiant. Cela compte. Un résumé avec perte, choisi par une heuristique, peut supprimer silencieusement la ligne dont le modèle avait besoin. La réversibilité transforme cette erreur silencieuse en un appel d'outil supplémentaire, visible. La répartition des rôles est elle aussi instructive. Le skill agit sur la sortie, le proxy sur l'entrée, et le middleware transporte l'idée d'entrée dans le code sur mesure. Chaque pièce peut être adoptée seule, ce qui permet à une équipe de commencer par la moins coûteuse.

Évaluation pratique et applications

Trois séries de chiffres sont disponibles. Elles mesurent des choses différentes et ne doivent pas être additionnées. La première vient de JetBrains. Le laboratoire a mené un test A/B apparié sur 86 tâches de programmation réelles, avec Claude Code 2.1.200 et le skill seul. Le proxy ne faisait pas partie du test. Les tokens de sortie ont baissé de 8,5 %, et le coût d'environ 10 %. Le test du signe sur les 18 tâches où les deux bras diffèrent donne p = 0,82. Le score moyen par tâche passe de 0,326 à 0,311, soit un écart de 0,015. Selon ces données, la qualité ne varie pas de façon mesurable, mais l'économie reste modeste. La deuxième vient d'un article de recherche d'Adobe, CAVEWOMAN, cité dans le README. L'article indique qu'un style de sortie de type caveman réduit le coût réel de 1,4 à 2,4 fois selon le modèle, et jusqu'à 3 fois dans le meilleur cas. Ces chiffres sont ceux de l'article. Cet article ne les a pas reproduits. La troisième vient du projet lui-même. Un benchmark de 54 exécutions avec Claude Code montre une baisse de 33,2 % des tokens d'entrée grâce au proxy, sur six charges de travail. Les 18 contrôles de réponse ont tous réussi. L'intervalle à 95 % va de 14,6 % à 48,5 %. Le README précise cependant que les artefacts bruts du harnais ne figurent pas dans le dépôt. Il s'agit donc d'un rapport figé, et non d'une reproduction publique. Ce sont les auteurs qui l'ont réalisé, et le lecteur doit en tenir compte.

Deux points supplémentaires méritent attention. D'abord, la télémétrie : l'outil en ligne de commande envoie des statistiques d'usage, avec un identifiant d'installation aléatoire et l'adresse IP, et ce envoi est activé par défaut. La commande `caveman telemetry off` le désactive. Le skill seul n'envoie rien. Les équipes soumises à des règles sur les données doivent le vérifier avant l'installation. Ensuite, la comparaison avec Headroom et RTK : le README cite des données JetBrains qui attribuent à RTK une hausse médiane du coût de 7,6 % par tâche à faible effort de raisonnement. Il s'agit d'une affirmation sur un concurrent, reprise d'un test tiers. Où l'outil est-il utile ? Il convient aux sessions d'agent à fort volume, où la réponse est courante et les sorties d'outils sont volumineuses. Le tri de journaux, le débogage de tests et l'exploration de dépôts s'y prêtent. En revanche, il est mal adapté lorsque la formulation a un poids juridique, sécuritaire ou commercial. Le README le reconnaît lui-même : les avertissements de sécurité et les demandes de confirmation reviennent en phrases complètes. Une réponse plus courte n'est pas automatiquement plus sûre. La méthode raisonnable consiste à mesurer avant d'adopter. La commande `caveman trial` exécute une session avec et sans caveman, puis montre la différence. Un pourcentage mesuré sur une autre base de code dit peu de chose sur la vôtre.

Impact sur le secteur et perspectives

caveman a surtout changé la conversation. Il a rendu visible un fait de facturation. Les équipes surveillent les tokens de sortie, parce que ce sont les textes qu'elles lisent. Le projet rappelle que la lecture représente souvent la plus grande part de la facture, et que le proxy vise précisément cette part. Il montre aussi qu'une plaisanterie peut porter une idée d'ingénierie sérieuse. Le ton reste ludique. Le mécanisme, lui, est une couche de compression réversible entre le modèle et ses outils. Cette couche n'est pas propre à caveman, et des projets concurrents comme Headroom ou RTK explorent des approches voisines.

Trois leçons en découlent pour les praticiens. Mesurer la charge de travail avant de faire confiance à un pourcentage. Garder la compression réversible, car une coupe avec perte qu'on ne peut pas annuler transforme une décision du modèle en perte définitive. Suivre la qualité en même temps que le coût, car une économie qui dégrade les réponses n'en est pas une. La question ouverte est de savoir si la compression côté lecture tient sur des sessions plus longues, avec davantage d'outils et de grands dépôts. Les données publiées portent sur des tâches de programmation courtes et sur le benchmark du projet lui-même. Elles ne tranchent pas la question. Une reproduction indépendante du résultat du proxy serait la prochaine étape la plus utile. La licence Apache-2.0, appliquée à tout le dépôt depuis la version 3.0.0, rend cette reproduction simple à mener.