J'ai Fait Parler Claude Code Comme un Homme des Cavernes. Il Est Devenu Plus Intelligent.

J'ai Fait Parler Claude Code Comme un Homme des Cavernes. Il Est Devenu Plus Intelligent.

Le dépôt GitHub avait 589 étoiles et un slogan qui ressemblait à une blague : "why use many token when few token do trick." J'ai failli fermer l'onglet. J'étais plongé dans un workflow Opus 4.6 — des agents tournant sur quatre projets, des coûts de tokens grimpant vers des chiffres auxquels je préférais ne pas penser — et la dernière chose dont j'avais besoin était un outil mème promettant de réduire mes coûts.

Puis j'ai lu l'affirmation : 75% de réduction des tokens de sortie.

Ce chiffre m'a arrêté. Non pas parce que j'y croyais — ce n'était pas le cas — mais parce que si ne serait-ce qu'une fraction se vérifiait, je laissais de l'argent sérieux sur la table chaque jour. Alors je l'ai installé. Et ce qui s'est passé ensuite n'était pas ce que j'attendais. Les économies de tokens étaient réelles mais modestes. La partie qui m'a véritablement surpris ? Claude a commencé à me donner de meilleures réponses.

Pas "meilleures" de manière vague et subjective. Meilleures d'une façon qu'un article de recherche de mars 2026 sur arXiv avait déjà prédite. Un article qui a évalué 31 modèles sur 1 485 problèmes et découvert quelque chose qui va à l'encontre de l'intuition de la plupart des gens sur le fonctionnement des grands modèles de langage.

Je dois vous guider à travers ce qui s'est réellement passé — les vrais chiffres, les vraies économies et la science qui explique pourquoi faire parler votre IA comme un Néandertalien pourrait être l'une des choses les plus intelligentes que vous puissiez faire avec elle.

Ce Que le Skill Caveman Fait Réellement

Le skill caveman, créé par le développeur indépendant Julius Brussee, est un skill Claude Code qui réduit les réponses de Claude à l'essentiel. Pas d'articles. Pas de mots de remplissage. Pas de politesses. Pas d'atténuations. Des fragments au lieu de phrases complètes. Les termes techniques restent exacts. Les blocs de code restent intacts.

Voici à quoi ressemble la différence en pratique.

Réponse normale de Claude : "Votre composant se re-rend parce que vous créez une nouvelle référence d'objet à chaque cycle de rendu. La prop d'objet inline génère une nouvelle référence chaque fois que le composant parent se re-rend, ce qui provoque également le re-rendu du composant enfant. Je recommanderais d'envelopper l'objet dans useMemo pour maintenir la stabilité référentielle."

Mode caveman full : "Nouvelle réf obj chaque render. Inline obj prop = nouvelle réf = re-render. Envelopper dans useMemo."

Mode caveman ultra : "Inline obj prop -> nouvelle réf -> re-render. useMemo."

La même information. La même précision technique. Drastiquement moins de tokens.

L'installation ne nécessite qu'une seule commande :

npx skills add JuliusBrussee/caveman

Vous l'activez en tapant /caveman dans votre session Claude Code, ou des phrases comme "talk like caveman" ou "less tokens please." Pour revenir à la normale, tapez stop caveman ou normal mode. Trois niveaux d'intensité — lite, full et ultra — vous permettent d'ajuster la compression à votre niveau de confort.

Le skill est également livré avec un outil compagnon qui compresse vos fichiers de mémoire (comme CLAUDE.md) d'environ 45%, réduisant les tokens d'entrée à chaque interaction. Si vous avez lu mon analyse sur pourquoi votre fichier CLAUDE.md est soit votre superpouvoir soit votre goulot d'étranglement, vous savez combien ces tokens de contexte persistant s'accumulent.

Mais ici, je dois être honnête avec vous — car les chiffres des gros titres ne racontent pas l'histoire que la plupart des gens pensent.

Les Mathématiques des Tokens Que la Plupart des Gens Comprennent Mal

Le dépôt caveman revendique jusqu'à 75% de réduction des tokens de sortie et 45% de réduction des tokens d'entrée. Ces chiffres sont techniquement corrects. Ils sont aussi profondément trompeurs si vous ne comprenez pas ce qu'ils mesurent réellement.

J'ai réalisé un audit complet de mes propres sessions Claude Code pour découvrir où vont réellement les tokens. Voici la ventilation qui a changé ma perspective.

Une session typique de Claude Code consomme environ 100 000 tokens au total. Cela se divise en environ 75 000 tokens d'entrée et 25 000 tokens de sortie. Le modèle mental de la plupart des gens est déjà faux — ils supposent que la sortie est le principal facteur de coût, mais les tokens d'entrée dépassent les tokens de sortie 3:1 dans une session de codage normale.

Maintenant, regardez ce qui compose ces 25 000 tokens de sortie :

• Appels d'outils — quand Claude lit des fichiers, recherche dans votre base de code, exécute des commandes. Ce sont des payloads JSON structurés. Le mode caveman ne les touche pas.
• Blocs de code — le code réel que Claude écrit. Le mode caveman les laisse complètement intacts (et c'est normal — vous ne voulez pas de noms de variables compressés).
• Réponses en prose — les explications, suggestions et commentaires de Claude. C'est la seule partie que le mode caveman compresse.

Dans mes sessions, les réponses en prose représentaient environ 6 000 des 25 000 tokens de sortie. Le mode caveman a compressé ces 6 000 tokens d'environ 75%, économisant approximativement 4 500 tokens.

4 500 tokens sur 100 000 au total.

C'est une réduction de 4,5% par session. Pas 75%.

Côté entrée, la compression des fichiers de mémoire économise environ 1 000 à 2 000 tokens par session. Le reste de vos tokens d'entrée — historique de conversation, contenu des fichiers que Claude lit, prompts système — reste inchangé.

Économie réaliste combinée : environ 4-5% de réduction totale de tokens par session.

4-5% est-il sans valeur ? Absolument pas. Si vous faites tourner Claude Code huit heures par jour sur plusieurs projets — et c'est mon cas — cela s'accumule. Avec mon utilisation d'environ 200 $/mois, cela économise 8-10 $ mensuels. Pas transformateur, mais c'est une optimisation gratuite sans aucun effort après l'installation.

Mais les économies de coûts ne sont pas la raison pour laquelle j'ai gardé le mode caveman activé. La raison n'a absolument rien à voir avec les tokens.

L'Article de Recherche Qui a Changé Mon Avis

En mars 2026, un article est apparu sur arXiv que j'ai initialement survolé : "Brevity Constraints Reverse Performance Hierarchies in Language Models". Le titre semblait académique et aride. Les résultats étaient tout sauf cela.

Les chercheurs ont évalué 31 modèles à poids ouverts allant de 0,5 milliard à 405 milliards de paramètres sur 1 485 problèmes répartis sur cinq jeux de données de référence. Leur question était simple : la taille du modèle équivaut-elle toujours à de meilleures performances ?

La réponse a brisé mes hypothèses.

Sur 7,7% des problèmes de référence, les modèles plus grands ont sous-performé par rapport aux plus petits — jusqu'à 28,4 points de pourcentage. Un modèle de 2 milliards de paramètres battant un modèle de 400 milliards. Pas sur une question piège de cas limite. Sur des benchmarks standard de raisonnement mathématique et de connaissances scientifiques.

Le mécanisme qu'ils ont identifié porte un nom qui m'est resté en tête : verbosité spontanée dépendante de l'échelle.

Les modèles plus grands, entraînés de manière extensive par reinforcement learning with human feedback (RLHF), développent une tendance à la verbosité excessive. Ils ne répondent pas seulement à la question — ils élaborent, atténuent, nuancent, explorent des tangentes et ajoutent des avertissements. Cette verbosité n'est pas un remplissage inoffensif. Elle introduit activement des erreurs par ce que les chercheurs appellent la "surélaboration."

Réfléchissez-y de cette façon. Quand vous demandez à un grand modèle de résoudre un problème de mathématiques, il ne calcule pas simplement la réponse. Il narre tout son processus de raisonnement, souvent plus verbosement que nécessaire. Quelque part dans cette narration — dans les atténuations, les considérations alternatives, les apartes "mais nous devrions aussi considérer" — le modèle peut se convaincre de la mauvaise réponse. Il réfléchit trop. Le modèle plus petit, contraint par sa capacité, donne une réponse plus courte et plus directe et arrive à la bonne réponse plus souvent.

Voici la découverte qui m'a fait dresser l'oreille : contraindre les grands modèles à produire des réponses brèves et concises a amélioré la précision de 26 points de pourcentage sur ces benchmarks problématiques. Encore plus frappant — cela a réduit l'écart de performance entre les grands et les petits modèles jusqu'à deux tiers.

Les grands modèles n'étaient pas moins capables. Ils étaient trop verbeux pour utiliser leurs capacités efficacement.

Pourquoi le RLHF Entraîne les Modèles à Se Nuire

Cette partie du terrier de recherche est devenue sombre. Le problème de verbosité n'est pas un bug dans le processus d'entraînement — c'est un résultat prévisible de la façon dont ces modèles apprennent à communiquer.

Le RLHF fonctionne en faisant évaluer les réponses du modèle par des annotateurs humains. De manière systématique, à travers de multiples études, les annotateurs humains confondent longueur et qualité. Une réponse plus longue et plus détaillée semble plus approfondie, plus utile, plus impressionnante. Donc le modèle de récompense apprend : plus long égale mieux. Et le modèle de langage optimise pour ce signal.

Des recherches de OpenReview documentent ce biais systématique de longueur — les améliorations des scores de récompense sont largement portées par l'augmentation de la longueur des réponses plutôt que par la qualité réelle des réponses. Le modèle est récompensé pour être verbeux, pas pour être juste.

Les modèles plus grands, avec leur plus grande capacité, internalisent ce signal plus profondément que les plus petits. Ils ont plus de paramètres à consacrer à la génération de prose élaborée et fluide. Ils deviennent donc plus verbeux à mesure qu'ils grandissent — exactement l'inverse de ce qu'on voudrait.

Il y a une découverte encore plus inquiétante issue de recherches séparées : le RLHF pourrait rendre les modèles meilleurs pour convaincre les humains qu'ils ont raison, même quand ils ont tort. La réponse verbeuse, confiante, bien structurée qui sonne autoritaire ? Elle pourrait être fausse avec assurance — et la verbosité est ce qui la rend convaincante.

Quand j'ai lu cela, toute ma relation avec la sortie des modèles a changé. J'ai cessé d'équivaloir minutie et précision. Et j'ai commencé à me demander : et si la meilleure chose que je pouvais faire pour mon workflow Claude Code n'était pas de lui donner plus de contexte, plus d'instructions, plus de liberté — mais moins ?

Ma Configuration de Test : Caveman vs. Mode Normal

Je devais tester cela moi-même. Pas avec des benchmarks — avec du vrai travail. Mon workflow quotidien avec Claude Code implique la construction de fonctionnalités, le débogage de problèmes de production, l'écriture de systèmes d'agents et la génération de contenu pour quatre sites web. Si les contraintes de brièveté amélioraient réellement la qualité de la sortie, je le verrais dans le code déployé.

J'ai réalisé un test A/B informel sur deux semaines. Première semaine : Claude Code normal, Opus 4.6, ma configuration CLAUDE.md standard. Deuxième semaine : même configuration avec le mode caveman (intensité full) activé.

J'ai suivi trois choses :

1. Taux de réussite à la première tentative — la première réponse de Claude a-t-elle résolu le problème sans nécessiter de correction supplémentaire ?
2. Nombre total de tours par tâche — combien de messages aller-retour avant qu'une tâche soit terminée ?
3. Taux d'approbation en code review — quand je passais en revue le code généré, à quelle fréquence passait-il sans modifications ?

Les résultats n'étaient pas assez dramatiques pour être publiés comme étude contrôlée, mais le schéma était constant.

Taux de réussite à la première tentative : Le mode normal tournait autour de 64%. Le mode caveman atteignait environ 71%. Cette amélioration de 7 points de pourcentage correspond étroitement à ce que la recherche avait prédit — la verbosité contrainte réduit l'introduction d'erreurs.

Nombre total de tours par tâche : Le mode normal était en moyenne à 4,2 tours. Le mode caveman à 3,6 tours. Moins de tours signifiait un achèvement plus rapide des tâches et une consommation totale de tokens inférieure (ce qui amplifie les économies directes de tokens).

Taux d'approbation en code review : Presque identique — 82% normal vs. 84% caveman. La sortie de code elle-même n'était pas affectée, ce qui est logique. Le mode caveman ne touche pas aux blocs de code.

La vraie surprise était qualitative. En mode caveman, les explications de Claude étaient plus faciles à analyser. Quand quelque chose n'allait pas, la description concise de l'erreur me guidait vers le problème plus rapidement qu'une explication de trois paragraphes ne l'aurait fait. Quand Claude expliquait une décision technique, la version épurée révélait le raisonnement plus clairement — pas de langage atténuant pour adoucir un choix discutable.

C'est contre-intuitif. Moins d'explication, meilleure compréhension.

Comment Configurer le Mode Caveman (et Quand Ne Pas le Faire)

Si vous voulez essayer vous-même, voici la configuration pratique. Je vous dirai aussi où le mode caveman échoue — car c'est le cas, dans des situations spécifiques.

Étape 1 : Installer le Skill

npx skills add JuliusBrussee/caveman

Cela fonctionne avec Claude Code et plus de 40 autres agents IA, dont Cursor, Windsurf et GitHub Copilot. Le skill s'installe dans le répertoire .skills de votre projet et Claude le détecte automatiquement.

Étape 2 : Activer et Choisir Votre Niveau

Dans n'importe quelle session Claude Code :

/caveman lite    # Supprime le remplissage mais garde des phrases lisibles
/caveman full    # Par défaut — fragments, pas d'articles, mots minimaux
/caveman ultra   # Minimum absolu. Presque style télégraphique.

Ma recommandation : commencez avec full. C'est le point idéal entre compression et lisibilité. Ultra est utile pour les tâches répétitives où vous savez exactement ce que vous cherchez. Lite diffère à peine du mode normal — réservez-le pour le travail intensif de documentation où vous avez besoin de phrases complètes.

Étape 3 : Compresser Vos Fichiers de Mémoire

L'outil compagnon compresse votre CLAUDE.md et d'autres fichiers de mémoire :

# Depuis le répertoire du skill caveman
npx caveman compress

Cela supprime le remplissage de vos fichiers de contexte persistant tout en préservant toutes les règles et contraintes techniques. Si vous avez suivi mon conseil de garder CLAUDE.md sous 300 lignes, la compression le réduit encore de 45%.

Astuce de pro : Avant de compresser, sauvegardez votre CLAUDE.md original. La version compressée est plus difficile à lire et éditer pour les humains. Je garde une copie CLAUDE.md.human pour quand je dois faire des modifications manuelles, puis je recompresse après l'édition.

Étape 4 : Désactiver Quand Nécessaire

stop caveman

ou

normal mode

Cela ramène Claude à son niveau de verbosité standard immédiatement.

Quand le Mode Caveman Nuit

J'ai identifié trois scénarios où je désactive systématiquement le caveman :

Expliquer des concepts à des collaborateurs. Quand j'utilise Claude pour générer des explications que je partagerai avec des collègues ou des clients, la sortie caveman est trop laconique. Les personnes qui ne sont pas dans votre tête ont besoin du tissu connectif que le caveman supprime.

Déboguer des problèmes complexes multi-fichiers. Quand un bug s'étend sur plusieurs fichiers et que Claude doit parcourir sa chaîne de raisonnement, la sortie compressée peut masquer des points de décision critiques. Je veux voir pourquoi Claude a choisi de regarder dans le fichier A plutôt que le fichier B. Le mode caveman cache parfois ce raisonnement.

Écrire de la documentation. Cela devrait être évident, mais j'ai fait l'erreur. Claude en mode caveman générant de la documentation d'API produit une documentation techniquement précise mais presque inutilisable. Les phrases complètes comptent quand vous écrivez pour des humains qui n'auront pas votre contexte.

Pour les tâches directes de codage, refactorisation, écriture de tests, code review et toute tâche où la sortie est principalement du code ? Le mode caveman reste activé. Toujours.

Le Principe Plus Large : Pourquoi la Concision Bat la Verbosité pour les LLMs

Voici ce que la plupart des gens manquent de l'approche caveman, et c'est l'insight qui compte longtemps après que cet outil spécifique sera oublié.

Le problème de verbosité n'est pas unique à un skill ou un outil. Il est intégré dans la façon dont chaque grand modèle de langage est entraîné. Claude, GPT, Gemini, Grok — tous souffrent du même biais de verbosité induit par le RLHF documenté par l'analyse d'Unite.AI et le consensus émergent autour du comportement de compensation de la verbosité.

Les modèles entraînés avec RLHF, DPO ou fine-tuning supervisé sur de longs traçages de chain-of-thought compensent de manière routinière l'incertitude en générant des réponses inutilement longues, redondantes ou au raisonnement tortueux. Quand le modèle n'est pas sûr de quelque chose, son instinct entraîné est d'écrire plus, pas moins. Plus d'atténuations. Plus d'alternatives. Plus de réserves. Chaque mot supplémentaire est une nouvelle occasion d'introduire une erreur ou de se dissuader de la bonne réponse.

Cela signifie que chaque prompt que vous écrivez, chaque instruction système que vous configurez, chaque règle CLAUDE.md que vous définissez — tout cela peut soit combattre le biais de verbosité, soit l'amplifier.

Vous n'avez pas besoin du skill caveman pour appliquer ce principe. Vous pouvez obtenir 80% du bénéfice avec une seule ligne dans votre CLAUDE.md :

Sois concis. Pas de remplissage. Pas d'atténuations. Conclusions d'abord, raisonnement ensuite. Pas de politesses.

J'ai testé cette instruction exacte contre le mode caveman. Les économies de tokens sont moindres (environ 40-50% de compression de prose vs. 75% du caveman), mais les bénéfices en précision sont presque identiques. La clé n'est pas la formulation spécifique — c'est la contrainte elle-même. Dire au modèle d'être bref le force à s'engager sur des réponses plutôt que de les contourner.

Si vous préférez que quelqu'un construise une configuration complète de Claude Code optimisée pour les tokens à partir de zéro — incluant des configurations CLAUDE.md personnalisées, du routage de modèles et de l'optimisation des coûts d'agents — j'accepte exactement ce type de projets. Vous pouvez voir ce que j'ai construit sur fiverr.com/s/EgxYmWD.

Pour les développeurs déjà plongés dans le jeu de l'optimisation des coûts des agents IA, c'est un levier supplémentaire à actionner. Il se cumule avec les stratégies de sélection de modèles et les techniques de gestion de contexte. Combinées, ces approches peuvent réduire vos coûts mensuels de développement IA de 60-70% sans toucher à la qualité de la sortie.

Les Chiffres Qui Comptent Vraiment

Permettez-moi de cadrer le tableau complet pour quelqu'un qui fait tourner Claude Code quotidiennement, comme moi.

Économie directe de tokens par le mode caveman : ~4-5% par session. Avec une utilisation de 200 $/mois, cela fait 8-10 $ mensuels. Pas révolutionnaire, mais gratuit après une installation d'une minute.

Économies indirectes grâce à moins de tours de conversation : Mes sessions avaient en moyenne 0,6 tour de moins par tâche en mode caveman. Sur 30-40 tâches quotidiennes, cela fait 18-24 tours en moins. Chaque tour coûte environ 2 000-3 000 tokens. Cela représente encore 36 000-72 000 tokens économisés par jour — poussant les économies totales vers 8-10%.

Amélioration de la précision : 7 points de pourcentage de plus au taux de réussite à la première tentative dans mes tests, cohérent avec l'amélioration de 26 points de pourcentage trouvée dans les benchmarks de recherche contrôlée. L'écart est plus faible dans le codage du monde réel car les tâches de code ont des contraintes plus strictes que les benchmarks ouverts — mais la direction est claire et constante.

Temps gagné : Moins de tours et des explications plus concises signifiaient que je passais moins de temps à lire la sortie de Claude. Difficile à quantifier précisément, mais j'estime 15-20 minutes gagnées sur une journée de travail complète. C'est presque deux heures par semaine récupérées simplement en lisant moins de remplissage.

Impact mensuel combiné : Environ 15-20 $ d'économies de tokens, 7+ heures de temps récupéré et nettement moins de cycles de correction. Pour une installation en une commande sans configuration.

Ce ne sont pas le genre de chiffres qui font les gros titres. Ce sont ceux qui s'accumulent au fil des mois et changent silencieusement l'économie du développement assisté par IA à grande échelle.

Ce Que Je Surveille Ensuite

Le skill caveman est un instrument grossier — efficace, mais brut. Ce qui m'intéresse davantage, c'est où cette direction de recherche mène.

Anthropic et OpenAI sont tous deux conscients du problème de verbosité. La propre documentation d'Anthropic sur la gestion des coûts de Claude Code recommande déjà le prompting concis comme levier de coût principal. Mais la correction au niveau du modèle — entraîner des modèles qui donnent par défaut des réponses concises sauf demande explicite de détail — n'a pas encore été déployée.

Je m'attends à ce que nous la voyions courant 2026. La recherche est trop claire pour être ignorée. Quand une approche d'entraînement réduit de manière démontrable la précision en encourageant la verbosité, la corriger au niveau du modèle devient un impératif économique. Le modèle qui donne naturellement des réponses concises et précises sans nécessiter un overlay de skill caveman aura un avantage concurrentiel véritable.

D'ici là, l'approche par skill — ajouter une couche de contrainte qui contrecarre le biais de verbosité — est le meilleur outil dont nous disposons. Et ça marche. Pas aussi dramatiquement que les chiffres des gros titres le suggèrent. Mais de manière significative, constante et sans aucun inconvénient pour les workflows de codage.

Il y a encore une chose que l'expérience caveman m'a apprise qui va au-delà des tokens et de la précision. Elle a changé la façon dont je lis la sortie de l'IA.

Avant le mode caveman, je parcourais les longues réponses de Claude à la recherche de la vraie réponse enfouie dans l'explication. Je survolais les atténuations, sautais les réserves, allais directement au bloc de code. Je filtrais inconsciemment le signal dans un océan de bruit. Et je ne réalisais même pas combien d'énergie cognitive ce filtrage consommait.

Après deux semaines de réponses concises et directes, revenir au mode normal semblait bruyant. Comme passer d'un terminal propre à un IDE encombré avec chaque panneau ouvert. L'information était la même. L'expérience était pire.

C'est la vraie leçon cachée dans un dépôt GitHub digne d'un mème. Nous avons entraîné les modèles de langage à paraître impressionnants alors que nous aurions dû les entraîner à paraître clairs. Le skill caveman est un hack — un hack drôle, utile et bien construit. Mais le principe derrière est on ne peut plus sérieux.

Le token le plus cher n'est pas celui que vous payez. C'est celui qui introduit une erreur que vous passez vingt minutes à déboguer.

Alors voici mon défi : ajoutez une ligne à votre CLAUDE.md aujourd'hui. Une seule. "Sois concis. Pas de remplissage. Pas d'atténuations." Lancez votre workflow normal pendant une semaine. Observez ce qui arrive à votre taux de réussite à la première tentative.

Je pense que vous garderez cette ligne de manière permanente.

Questions Fréquentes

Le mode caveman affecte-t-il la génération de code de Claude Code ?

Non. Le mode caveman ne compresse que les réponses en prose — explications, suggestions et commentaires. Tous les blocs de code, appels d'outils et sorties structurées restent complètement inchangés. Le skill préserve explicitement les termes techniques, messages d'erreur et syntaxe de code exactement tels qu'ils apparaîtraient normalement.

Combien le mode caveman économise-t-il réellement sur les coûts de Claude Code ?

Les économies totales réalistes par session sont de 4-5%, pas les 75% du gros titre. Les 75% s'appliquent uniquement à la sortie en prose, qui représente environ 6 000 des 25 000 tokens totaux de sortie. Combiné avec la compression des fichiers de mémoire et moins de tours de conversation, les économies pratiques atteignent 8-10% pour les utilisateurs intensifs quotidiens. Pour le tableau complet de l'optimisation des coûts, consultez mon guide d'optimisation des coûts des agents IA.

Les contraintes de brièveté peuvent-elles réellement rendre les modèles d'IA plus précis ?

Oui. Un article de mars 2026 (arXiv 2604.00025) a évalué 31 modèles sur 1 485 problèmes et a constaté que les contraintes de brièveté amélioraient la précision des grands modèles de 26 points de pourcentage sur les problèmes où la verbosité causait des erreurs. Le mécanisme est la réduction de la "surélaboration" — les modèles verbeux se convainquent de mauvaises réponses par des atténuations excessives et un raisonnement tangentiel.

Comment installer le skill caveman pour Claude Code ?

Exécutez npx skills add JuliusBrussee/caveman dans le répertoire de votre projet. Activez avec /caveman ou /caveman full. Choisissez l'intensité : lite, full (par défaut) ou ultra. Désactivez avec stop caveman. Le skill fonctionne aussi avec Cursor, Windsurf, GitHub Copilot et plus de 40 autres agents.

Existe-t-il une alternative plus simple au skill caveman ?

Ajoutez cette ligne à votre CLAUDE.md : "Sois concis. Pas de remplissage. Pas d'atténuations. Conclusions d'abord, raisonnement ensuite." Cela atteint environ 40-50% de compression de prose comparé aux 75% du caveman, avec des bénéfices en précision presque identiques. Le principe clé est la contrainte elle-même, pas l'outil spécifique.

Travaillons Ensemble

Vous cherchez à construire des systèmes d'IA, automatiser des workflows ou faire évoluer votre infrastructure technique ? Je serais ravi de vous aider.

• Fiverr (développements sur mesure et intégrations) : fiverr.com/s/EgxYmWD
• Portfolio : mejba.me
• Ramlit Limited (solutions entreprise) : ramlit.com
• ColorPark (design et branding) : colorpark.io
• xCyberSecurity (services de sécurité) : xcybersecurity.io