Si vous aimez faire des économies ou si vous détestez simplement la façon dont les modèles de langage s’expriment, une nouvelle fonctionnalité très en vogue pourrait changer votre quotidien. Appelée « Caveman », elle promet de réduire jusqu’à 75 % des tokens générés tout en conservant une précision technique totale. Voici pourquoi cette approche rudimentaire pourrait bien devenir indispensable.
Les modèles de langage ont un défaut récurrent : ils parlent trop. Chaque requête génère des paragraphes entiers de mots de remplissage, des formules de politesse inutiles et des tournures alambiquées pour dire ce qui pourrait tenir en deux lignes. Ce n’est pas seulement agaçant, c’est coûteux. Chaque token a un prix, et quand on utilise ces outils au quotidien, la facture peut vite grimper. C’est ce problème que le skill Caveman prétend résoudre.
Ce que vous allez découvrir dans cet article
- Je vais vous montrer le résultat d’un test comparatif entre Claude Code standard et Claude Code équipé de Caveman.
- Vous verrez les chiffres concrets sur la réduction des tokens, mais aussi le piège caché dans les coûts d’entrée.
- Enfin, nous passerons en revue les différents réglages disponibles et les scénarios où cette compétence devient réellement rentable.
« Pourquoi perdre du temps à dire beaucoup de mots alors que quelques-uns suffisent ? » Cette citation résume parfaitement la philosophie de Caveman. Cette compétence fonctionne sur Claude, Codex et bien d’autres plateformes comme Opencode. Elle transforme vos résultats, qu’il s’agisse de mots de remplissage ou de longues réponses illisibles, en un résumé concis tout en conservant la même précision technique.
Elle est même personnalisable et propose des fonctionnalités supplémentaires telles que le mode Wenyan, des commits concis, des revues de code en une ligne et un outil de compression des entrées. Cela peut sembler un peu fou au premier abord, mais il y a même une base scientifique derrière tout ça.
Un test concret dans Claude Code
Je testais cela tout à l’heure dans Claude Code avec une application de démonstration Next.js que je possède et qui comporte un faux système d’authentification. Ma requête était simple : « Peux-tu expliquer comment l’authentification est implémentée dans cette application ? »
Voici le Claude Code standard, sans la compétence Caveman installée. Il utilise des mots de remplissage : « Il s’agit d’un système d’authentification simulé. » Puis il enchaîne avec des deux-points : « Pas de backend, pas de mots de passe, pas de véritable sécurité. Existe pour démontrer le suivi utilisateur RUM de Better Stack. »
Après cela, il passe à l’explication des fichiers principaux et de leur fonctionnement. Tout est rédigé dans un anglais lisible, certes, mais inutilement verbeux quand on cherche juste une information technique.
Avec la compétence Caveman activée
Si nous posons la même question en utilisant la compétence Caveman, le résultat va droit au but. La première phrase devient : « Démonstration uniquement, authentification côté client, aucune sécurité réelle, conçu pour les démonstrations de suivi RUM de Better Stack. »
- Plus de mots de remplissage,
- plus de tournures inutiles.
- Pas besoin de former une phrase correcte : l’agent donne directement les informations techniques.
Il en va de même pour la section sur le fonctionnement, le flux et les points d’intégration. Au lieu d’expliquer le processus dans une phrase en anglais courant, on lit simplement « chargement de l’application », suivi d’une flèche pointant vers « vérifier le stockage local pour l’utilisateur enregistré ».
C’est tout simplement beaucoup plus concis, et c’est ce qui m’importe pour être honnête. Je me fiche que ce soit rédigé en anglais parfait. Je veux juste les informations techniques, rapidement.
L’essentiel à retenir : la concision est la raison principale pour laquelle j’apprécie cette compétence. Quand on passe sa journée à interroger un LLM, chaque phrase superflue est du temps perdu.
Le vrai problème derrière les économies de tokens
L’autre argument de vente de Caveman est évidemment financier. Moins de tokens de sortie signifie théoriquement plus de requêtes possibles avec votre abonnement Claude Code, ou des économies directes sur vos tokens API. Mais il y a un piège.
Voici les résultats d’un test comparatif que j’ai effectué, en comparant trois approches : la réponse de base de Claude Code, une réponse où je demande simplement « Sois concis », et l’utilisation de la compétence Caveman. Ce test a porté sur 10 requêtes simples comme « En quoi le rebase Git diffère-t-il d’un merge Git ? »
En quoi le rebase Git diffère-t-il d’un merge Git ?
C’est le type de requête utilisé pour le test comparatif : une question simple et technique, parfaite pour mesurer l’efficacité de Caveman sur des réponses factuelles.
Des chiffres encourageants sur les tokens de sortie
Je mets à jour ou crée vos articles personnellement, assisté par l'IA, avec optimisation SEO incluse.
| 📝 Mise à jour | 14 € |
| ✨ Création | 49 € |
Les résultats sont sans appel. Avec Caveman par rapport à la réponse de base, nous obtenons une réduction de 45 % des tokens de sortie, et de 39 % par rapport au simple fait de dire « Sois concis » à Claude Code.
En termes de coût, cela se traduit par une économie de 45 % sur les tokens de sortie. Le scénario de base coûte environ 8 cents, tandis que Caveman coûte environ 4 cents. Tout semble donc plutôt bien se présenter au premier abord.
Le coût caché des tokens d’entrée
Mais les choses deviennent plus intéressantes lorsqu’on prend en compte le coût des tokens d’entrée. En activant la compétence Caveman, nous chargeons un fichier Markdown qui contient beaucoup plus de texte que nos requêtes d’une seule phrase.
Pour le scénario de base, où nous envoyions simplement la phrase, cela coûte quelques fractions de centime. Avec la compétence Caveman, le coût d’entrée grimpe à environ 4 centimes.
Si l’on combine les coûts des tokens d’entrée et de sortie, Caveman est en réalité 10 % plus cher que le scénario de base sur un envoi unique. Les économies réalisées sur les tokens de sortie sont absorbées par le surplus de tokens d’entrée.
Ce résultat peut sembler décourageant, mais il faut le remettre en contexte. Ce désavantage ne se vérifie que dans un cas très précis : l’envoi d’une seule petite requête sans aucune question de suivi.
Pourquoi Caveman redevient rentable sur le long terme
Dès que vous commencez à poser des questions de suivi, vous touchez la tarification du cache de requêtes. Et c’est là que la balance penche franchement en faveur de Caveman, avec une économie de 39 % sur les coûts globaux.
Je me suis un peu égaré dans ces calculs, mais cela prouve qu’il y a une logique réelle à utiliser Caveman. Et ce, avant même de prendre en compte un autre avantage possible.
Une étude réalisée cette année a montré que le fait de limiter les grands modèles à des réponses brèves améliore la précision de 26 % sur certains benchmarks. Autrement dit, contrairement à ce qu’on pourrait penser, la concision ne sacrifie pas la qualité : elle l’améliore.
Ce que la compétence Caveman demande réellement à l’agent
Vous pouvez essayer cette compétence par vous-même en utilisant le paquet de compétences Vercel et en exécutant une commande appropriée. Le fichier Markdown contient des règles précises que l’agent doit suivre.
| Action | Exemples concrets |
|---|---|
| Supprimer | Articles (a, an, the), mots de remplissage, formules de politesse, tournures prudentes |
| Remplacer par des synonymes courts | « extensive » devient « big », « implement a solution for » devient « fix » |
| Conserver intact | Termes techniques, blocs de code, messages d’erreur |
| Structurer selon le pattern | Un élément, une action, une raison, puis une étape suivante |
Le résultat est une réponse structurée, claire et dépourvue de tout superflu. Mais le niveau de concision n’est pas fixe : il est ajustable.
- Sur notre blog ⇒ Automatisez la création de code avec les skills Grill Me, Shape et Ralph
- Les principes des Karpathy Skills : 1. Réfléchir avant de coder 2. La simplicité d’abord
Les différents niveaux de concision de Caveman
La compétence propose des modes d’intensité pour ajuster le niveau de « Caveman » selon vos besoins. Voici ce que chaque niveau implique concrètement.
| Mode | Comportement |
|---|---|
| Light | Concision légère, garde la plupart des connecteurs logiques |
| Full (par défaut) | Supprime les mots de remplissage et les formules de politesse, phrases courtes |
| Ultra | Tout est abrégé, les conjonctions sont supprimées, des flèches remplacent la causalité, un seul mot quand un seul suffit |
J’utilisais le mode « full » car c’est le réglage par défaut, et il offre un bon équilibre entre concision et lisibilité. Le mode « ultra » est réservé aux cas où vous voulez un résultat extrême.
Il existe également un mode Wenyan, qui utilise les caractères chinois classiques car ils sont les plus efficaces en termes de tokens. Malheureusement, je ne sais pas les lire, donc cela ne m’est pas d’une grande utilité. L’idée reste fascinante cependant : choisir une langue uniquement pour son efficacité en tokens.
Ce n’est même pas tout ce que Caveman a à offrir. Il possède quelques autres compétences supplémentaires pour des scénarios spécifiques (voir ici la totale).
- Caveman commit pour rédiger des messages concis et précis dans un format de commits conventionnel.
- Caveman review pour rédiger des commentaires de revue de code sous la forme d’une ligne concise par constatation.
- Et une compétence de compression pour prendre vos fichiers en langage naturel et les « cavemanifier » afin de les réutiliser avec un peu moins de tokens d’entrée.
Ces outils supplémentaires montrent que l’approche Caveman n’est pas un simple gadget. C’est une philosophie qui s’applique à différentes étapes du développement : de l’écriture de commits à la revue de code, en passant par la gestion des requêtes. Plus on l’utilise, plus on se demande pourquoi on acceptait pendant si longtemps des réponses verbeuses de la part de nos modèles de langage.
