Caveman English : économiser tokens et contexte avec Claude Code
Quand tu écris à Claude, chaque « le », « peux-tu », « s'il te plaît » coûte des tokens. Multiplié sur une longue session Claude Code, l'anglais (ou le français) poli est l'une des choses les plus chères que tu envoies dans le contexte.
Caveman English — l'anglais "homme des cavernes" — réduit les prompts à un noyau télégraphique : on supprime articles et formules de politesse, on garde verbes et noms. Le modèle comprend toujours. Économie : 30 à 50 % de tokens d'entrée — et surtout, économie de fenêtre de contexte, qui est la limite la plus dure à éviter sur les sessions longues.
À quoi ça ressemble
Avant :
Could you please refactor the Frontend.elm file to extract the navigation
into its own module, and make sure the existing tests still pass?
Après :
refactor Frontend.elm: extract nav into own module. tests must still pass.
Même instruction, ~55 % de tokens en moins. Claude la suit à l'identique.
Pourquoi ça marche
Les LLM sont robustes au bruit grammatical. Les articles (« a », « the »), la politesse modale (« could you », « would you mind »), les hedges (« peut-être », « si possible ») sont en grande partie redondants étant donné le verbe impératif qui suit. Le modèle utilise les mots de contenu — verbes, noms, chemins de fichiers, contraintes — pour planifier sa réponse. Les mots fonctionnels ne pèsent quasiment pas sur l'adhérence aux instructions.
Là où le Caveman English perd quelque chose : nuance et ton. Si la différence entre « réécris ceci » et « réfléchis à savoir si une réécriture est appropriée » importe pour ta tâche, garde la forme longue. Pour 90 % du travail de dev — corrige ça, construis ceci, refactor X, lance Y — le style télégraphique suffit.
Règles pratiques
- Verbe en premier.
refactor X,add Y,fix Z,run tests. Le verbe dit à Claude dans quel mode il est. - Pas d'articles. « the file », « a function », « an error » — disparus. Ne change quasi jamais le résultat.
- Pas de politesse. Pas de « please », pas de « could you ». Claude n'a pas besoin d'encouragement.
- Garde les détails. Chemins de fichiers, noms de fonctions, messages d'erreur, numéros de ligne — ce sont des mots de contenu, ne jamais les retirer.
- Garde les contraintes. « no new deps », « must pass tests », « don't touch CSS » — porteuses de sens.
- Garde le pourquoi quand il change la réponse. « fast for prod » vs « readable for review » → sortie différente. Vaut les tokens.
Ce que tu économises
Deux choses, et la seconde compte le plus :
- Tokens d'entrée = coût direct. Réduction de 30 à 50 % sur le texte du prompt. Argent réel sur de longues sessions API Claude.
- Budget de contexte = la limite la plus dure. Chaque prompt, chaque appel d'outil, chaque lecture de fichier va dans une fenêtre de taille fixe. Les prompts en Caveman English laissent plus de place pour la sortie de Claude et pour le prochain tour. Sur une fenêtre de 200k avec 50 appels d'outils, ça se cumule.
Les tokens de sortie ne bougent pas — Claude écrit toujours en anglais (ou français) complet dans ses réponses. Seule ta moitié de la conversation est compressée.
Le plus gros gain : faire parler Claude en Caveman aussi
Compresser tes prompts économise les tokens d'entrée. Mais le gros gain est ailleurs : demander à Claude de raisonner et répondre en Caveman English. Pourquoi ? Parce que les tokens de sortie coûtent environ 5× plus cher que les tokens d'entrée chez Anthropic, et Claude est naturellement bavard.
Une seule instruction dans ton CLAUDE.md, ton system prompt, ou ton premier message :
Respond in caveman English. Drop articles, drop politeness,
drop hedges. Verbs first. No preambles ("Great question!",
"Let me think...", "I'll now..."). Skip closing pleasantries.
Just answer.
Ce que ça change :
- Les réponses finales se réduisent de 30 à 60 % sans perte d'info. Le sandwich « Sure! Let me look at that... » → « I'll now check... » → « Let me know if... » est à lui seul une taxe brutale sur des centaines de tours.
- Les blocs de raisonnement / extended thinking (quand activés) se compressent pareil — moins de tokens en délibération interne, latence plus basse, coût plus bas.
- Les sessions à outils (Claude Code, boucles agentiques) : chaque appel d'outil est suivi d'un bout de réponse. Multiplié par 50+ appels dans une session, les tokens de sortie économisés dominent tout le reste.
Réalité tarifaire (API Anthropic, mi-2026) : chaque token de sortie coûte environ 5× le prix d'un token d'entrée, sur Sonnet, Opus et Haiku. Donc gagner 30 % sur le texte de sortie pèse plus que gagner 50 % sur le texte d'entrée. Les deux se cumulent.
Bémol : tu perds le ton pédagogique — Claude ne t'expliquera plus le pourquoi sans qu'on le demande. Pour du dev en mode "ship", c'est une feature. Pour apprendre un nouveau domaine, lâche un « explain in full English for this answer » ponctuel quand tu veux la version cours magistral.
Quand NE PAS l'utiliser
- Premier message d'une session quand tu cadres l'intention et les contraintes. Dépense les tokens, plante le décor.
- Discussions d'architecture où la nuance compte.
- Prompts de revue de code où tu veux que Claude explique le pourquoi, pas juste le quoi.
- Tout ce qui est destiné aux utilisateurs. Ne mets pas de Caveman English dans les messages de commit, les PR ou la doc. C'est un schéma de compression d'entrée privé.
Économies concrètes
Voici la même tâche envoyée à Claude Code dans les deux styles :
# Poli (52 tokens)
Could you please look at the failing test in tests/AuthSpec.elm and figure out
why it's broken? It started failing after the last commit. Don't change any
production code unless absolutely necessary.
# Caveman English (28 tokens)
tests/AuthSpec.elm: failing since last commit. find cause. fix in test only,
not prod code.
46 % de réduction. Même résultat. Maintenant imagine 100 prompts dans une session.
En résumé
Traite tes prompts comme des messages de commit, pas comme des emails. Impératif, concis, riche en contenu. Garde les tokens pour ce que Claude va faire, pas pour ce que tu vas dire.