Caveman - économiser les tokens Claude/Codex avec un parler d’homme des cavernes

 (github.com/JuliusBrussee)
30 points par GN⁺ 2026-04-06 | 2 commentaires | Partager sur WhatsApp
  • Une astuce qui force les réponses en parler d’homme des cavernes pour réduire en moyenne de 65 à 75 % les tokens de sortie
  • Trois niveaux de compression, Lite · Full · Ultra, pour ajuster l’intensité tout en conservant la précision technique et en produisant des réponses courtes et efficaces
  • Dans des benchmarks réels, les explications liées à React, PostgreSQL et Git voient toutes leur consommation de tokens tomber à moins de la moitié
  • Offre en même temps une vitesse de réponse environ 3 fois supérieure, une meilleure lisibilité et une réduction des coûts
  • Installation possible par une commande simple sur Claude Code et Codex, avec un fonctionnement persistant sur toute la session

Présentation de Caveman

  • Un plugin pour Claude Code et Codex qui convertit les réponses du LLM en « parler d’homme des cavernes » (caveman-speak) afin de réduire l’usage des tokens d’environ 75 %
  • Produit des réponses courtes et efficaces en supprimant les mots inutiles tout en gardant la précision technique
  • L’installation se fait avec une commande sur une seule ligne et reste active dans toutes les sessions
  • Seuls les tokens de sortie sont réduits — aucun effet sur les tokens de réflexion/raisonnement
  • Éléments supprimés :
    • Salutations et introductions : "Sure, I'd be happy to help" (8 tokens gaspillés)
    • Débuts d’explication causale : "The reason this is happening is because" (7 tokens)
    • Formulations de recommandation : "I would recommend that you consider" (7 tokens)
    • Entrées superflues : "Sure, let me take a look at that for you" (10 tokens)
  • Éléments conservés : blocs de code, termes techniques (comme polymorphism), messages d’erreur, messages de commit git et de PR

Exemples Before / After

  • La même explication technique est compressée en phrases courtes
    • Explication des causes d’un rerender de composant React : 69 tokens → 19 tokens
    • Explication d’un bug de middleware d’authentification : plus de 75 % de réduction des tokens
  • Trois niveaux de compression réglables : Lite / Full / Ultra
    • Lite (/caveman lite) : supprime les formulations inutiles tout en gardant la grammaire — professionnel, sans verbiage
    • Full (/caveman full) : mode caveman par défaut — articles omis, phrases courtes et fragmentaires
    • Ultra (/caveman ultra) : compression maximale — style télégraphique, tout est abrégé

Benchmarks

  • La comparaison de l’usage réel des tokens via l’API Claude montre une réduction moyenne de 65 %
  • Plage de réduction : 22 % à 87 %
    • Explication d’un bug de rerender React : 1 180 → 159 tokens (87 % de réduction)
    • Configuration du pool de connexions PostgreSQL : 2 347 → 380 tokens (84 % de réduction)
    • Build multi-stage Docker : 1 042 → 290 tokens (72 % de réduction)
    • Explication de git rebase vs merge : 702 → 292 tokens (58 % de réduction)
    • Refactorisation callback → async/await : 387 → 301 tokens (22 % de réduction, effet minimal)
  • Seuls les tokens de sortie diminuent, les tokens de réflexion et de raisonnement restent inchangés
  • Les principaux bénéfices sont une meilleure lisibilité et une hausse de la vitesse de réponse ; la baisse des coûts est un effet secondaire

Fondement scientifique

  • L’article de mars 2026 "Brevity Constraints Reverse Performance Hierarchies in Language Models" montre qu’en imposant des réponses concises à de grands modèles, on obtient jusqu’à 26 points de pourcentage de gain de précision sur certains benchmarks, avec inversion du classement de performance
  • "Verbose not always better. Sometimes less word = more correct"
    • Une réponse courte peut parfois être plus juste qu’une réponse verbeuse

Installation

  • Installation en une ligne : npx skills add JuliusBrussee/caveman
  • Plugin Claude Code : claude plugin marketplace add JuliusBrussee/caveman
  • Codex : cloner le dépôt puis rechercher et installer Caveman dans le menu /plugins
  • Déclencheurs : /caveman, "talk like caveman", "caveman mode", "less tokens please"
  • Désactivation : "stop caveman" ou "normal mode"
  • Une seule installation → s’applique ensuite à toute la session

Utilisation

  • Commandes de déclenchement : /caveman, $caveman, “talk like caveman”, “caveman mode”, “less tokens please”

  • Commandes d’arrêt : “stop caveman”, “normal mode”

  • Réglage de l’intensité

    Level Trigger Caractéristiques
    Lite /caveman lite Grammaire conservée, suppression des mots inutiles
    Full /caveman full Mode par défaut, suppression des articles et du verbiage
    Ultra /caveman ultra Compression maximale, expression centrée sur les abréviations

  • Le réglage reste actif jusqu’à la fin de la session

  • Licence MIT / Python 100 % / prise en charge des plugins Claude Code & Codex

À lire aussi

2 commentaires

 
joyfui 2026-04-06

Le style spartiate, ici aussi..? haha
 
GN⁺ 2026-04-06
Avis Hacker News

  • C’est l’auteur du post. Certaines personnes réfutent des affirmations plus fortes que ce que ce dépôt avance réellement. En fait, c’était fait comme une blague, pas comme un commentaire de niveau recherche
    Cette compétence ne cherche pas à réduire les reasoning tokens cachés, mais à diminuer le superflu du texte généré. Le code lui-même n’est pas affecté
    Je pense que les modèles d’Anthropic sont suffisamment ajustés via RL pour qu’il soit difficile de dégrader volontairement fortement leurs performances
    Le chiffre « ~75 % » indiqué dans le README venait de tests préliminaires, donc ça aurait dû être formulé avec plus de prudence. Un benchmark formel est maintenant en préparation
    La compétence n’est pas gratuite : elle consomme une partie du contexte au chargement. Donc une vraie évaluation doit inclure les tokens d’entrée/sortie, la latence et la qualité
    Il existe aussi des recherches montrant que des prompts concis peuvent réduire la longueur des réponses tout en maintenant la qualité (lien vers l’article)
    En résumé, c’est une idée intéressante, mais il y a beaucoup d’interprétations exagérées, et le README devrait être réécrit plus précisément avant une évaluation formelle

    • Ça paraît raisonnable. Les discussions en ligne prennent souvent cette tournure. Ce fil reste au-dessus de la moyenne, même s’il est parfois décevant
    • Si vous voulez des benchmarks, je recommande de regarder adam-s/testing-claude-agent
    • En gros : « C’est une blague. Ne me tombez pas dessus. Mais ça marche un peu, peut-être ? »
    • J’ai eu une conversation similaire avec un LLM, et il expliquait qu’il a tendance à répondre brièvement aux questions courtes, et avec des réponses plus riches en information aux demandes formulées poliment. Au final, la manière de poser la question influence le style de la réponse
      (Et je ne comprends toujours pas pourquoi ce genre de commentaire lié au sujet continue d’être downvoté)
    • La phrase « les modèles d’Anthropic sont optimisés pour le code, donc on ne peut pas forcer une baisse de performance » est un peu confuse.
      Si on ajoute un prompt du type « comporte-toi bêtement », on peut évidemment dégrader les performances. La vraie question, c’est l’impact réel d’un style de sortie particulier

  • J’ai toujours pensé que quand on force un LLM à parler autrement que dans son style par défaut, sa capacité de raisonnement diminue.
    Parce qu’une partie des couches du modèle doit alors se concentrer soit sur « quoi dire », soit sur « comment le dire »
    Dans des expériences de fiction collaborative ou de jeu de rôle, j’ai vu que plus le modèle doit prendre de faits en compte, plus il lui devient difficile de maintenir le style

    • À l’inverse, si on lui dit « parle de façon bavarde », il produit beaucoup plus. Les indications de personnalité ont réellement un gros impact
    • Je pense pareil. Au fond, le modèle a un budget d’attention limité, donc ce qu’il peut faire en une fois est forcément limité

  • L’idée est amusante. Mais j’aimerais aussi voir une approche qui mise non pas sur des tokens plus simples, mais sur des tokens plus riches.
    Par exemple, utiliser une expression plus fine comme « improve idiomatically » au lieu de « make good ». Le langage est un modulateur qui ajuste notre rapport au réel, donc un usage plus précis pourrait donner de meilleurs résultats. Hâte de voir les benchmarks

    • Ce style « caveman » me rappelle l’ancien style des télégrammes. Est-ce qu’un modèle pourrait apprendre des « tokens riches » compressant l’information, comme dans les recueils d’abréviations télégraphiques, puis les décoder dans le navigateur ? lien vers un recueil d’abréviations télégraphiques
    • Ça ressemble un peu au débat RISC vs CISC. Comme la simplicité a gagné en extensibilité, les LLM évoluent peut-être eux aussi vers une façon de penser à base de concepts simples et orthogonaux
    • Proposition de prompt : « MILSPEC prose register. Max per-token semantic yield. »

  • J’ai parlé à Claude en mode caveman, et la compréhension était moins bonne, avec beaucoup de malentendus.
    Au contraire, il fallait souvent expliquer davantage, et s’il y avait des fautes de frappe, la perte de contexte était importante.
    Au final, j’avais l’impression qu’il fallait plus de mots. Et le LLM semblait aussi tirer moins d’informations de ses propres réponses précédentes

    • Même sur les forums généralistes (Twitter, Reddit), des gens se plaignent que les LLM sont stupides, mais quand on voit leur manière d’écrire, on comprend pourquoi
    • Au début de ChatGPT, j’avais essayé de parler uniquement en s-expression, et le modèle répondait aussi en s-expression. Le contenu était mauvais, mais les parenthèses étaient bien équilibrées. Ce n’est plus le cas aujourd’hui
    • « Pourquoi parler beaucoup ? Parler peu fait gagner du temps. Monde mer. »
    • La plupart des données de style « caveman » ne concernent pas des conversations scientifiques, donc le modèle semble mal prédire ce contexte

  • J’ai vu un billet où un développeur au cerveau de Grug rencontre les outils d’IA (grugbrain.dev)

    • Moi aussi, j’utilise souvent Grug comme exemple quand je demande à un LLM d’expliquer un concept

  • L’idée est intéressante. Mais dans mon entreprise, la performance est évaluée selon la consommation de tokens. Est-ce qu’il existe aussi une compétence pour rendre Claude volontairement verbeux ?

    • Il suffit de lui faire écrire une explication style ELI5 dans /tmp à chaque boucle
    • C’est sérieux ou c’est une blague ? Vous travaillez chez Nvidia, par hasard ?

  • Idée mignonne, mais en pratique, le goulot d’étranglement, ce sont les tokens d’entrée.
    Le modèle lit une grande quantité de fichiers, de sorties d’outils et d’arbres de répertoires, mais la sortie ne contient que quelques centaines de lignes de code et une brève explication

    • Sur un seul tour, oui, mais sur plusieurs tours cumulés, optimiser la sortie peut avoir un intérêt.
      Au passage, on peut transmettre la même idée sans « Cute idea, but » (lien)
    • En plus, cette compétence n’a aucun effet sur les thinking tokens. Elle pourrait même demander davantage de raisonnement interne pour reformuler en mode caveman

  • Il y a aussi cette recherche connexe : ‘Brevity Constraints Reverse Performance Hierarchies in Language Models’ (2026)

  • Intéressant. On pourrait peut-être aussi décompresser le résultat avec un modèle 2B

  • Quelqu’un l’a peut-être déjà tenté, ou alors je me demande si je devrais l’implémenter moi-même
    Si les LLM communiquaient dans un langage non humain au lieu du langage humain, on pourrait gagner en efficacité.
    Un petit modèle local traduirait l’entrée humaine vers un langage plus adapté aux LLM, puis un grand modèle réfléchirait dans ce langage avant d’être retraduit
    Des modèles avec une petite fenêtre de contexte, comme Apple Fundamental Models, pourraient peut-être servir de couche de traduction
    Il semble aussi possible de faire découvrir ce langage par renforcement. Ça ferait un projet vraiment passionnant

    • J’ai eu une idée similaire. Créer un langage dédié aux LLM et entraîner les modèles avec serait intéressant, mais il faudrait probablement entre 60 et 100 millions de dollars.
      Parce qu’il faudrait inventer une langue totalement nouvelle et une nouvelle méthode d’entraînement. Mais si quelqu’un lève des fonds VC pour ça, je veux bien en être