Réduisez votre consommation de tokens (et son coût)
Vous payez chaque token en entrée et chaque token en sortie. La bonne nouvelle : la plupart des charges de travail réelles traînent du poids mort — prompts système gonflés, contexte renvoyé, réponses verbeuses, le mauvais modèle pour une tâche facile. Éliminez tout ça et la facture baisse sans toucher à la qualité. Cette page est la boîte à outils du power-user, classée grosso modo par effet de levier.
- Où les tokens fuient réellement — entrée vs sortie vs contexte réutilisé
- Le style laconique / « caveman » : ce qu'il économise vraiment, et où il se retourne contre vous
- Le cache de prompt et le traitement par lots pour des économies structurelles à chaque euro dépensé
- Dimensionner le modèle au besoin (Haiku pour les tâches faciles) et préférer la sortie structurée à la prose
- Mesurer avant de livrer avec l'endpoint de comptage de tokens
D'abord, trouvez où partent les tokens
Avant d'optimiser, répartissez vos dépenses en trois catégories — chacune a un remède différent :
Les remèdes s'alignent proprement : mettez en cache le contexte réutilisé, élaguez l'entrée, raccourcissez la sortie, dimensionnez le modèle et regroupez ce qui n'est pas urgent.
Le style laconique / « caveman » (économies en sortie)
Le geste viral consiste à dire à Claude de supprimer le remplissage et de répondre par fragments — popularisé par la skill Claude Code open-source caveman (sous licence MIT, par Julius Brussee), dont le slogan est « why use many token when few token do trick ». Elle force des phrases courtes, des verbes à l'infinitif et zéro politesse.
Le constat honnête des tests indépendants : le style ne coûte rien sur le contenu (le code, les termes techniques, le JSON restent exacts) mais les économies dépendent entièrement de votre référence de base. Si vos prompts disent déjà « sois concis », l'essentiel du gain est déjà acquis. Les grosses réductions (40–65 %) apparaissent sur les réponses riches en explications ; l'extraction structurée bouge à peine.
Bloc d'instruction sobre — à coller dans votre prompt système
Answer terse. Cut filler, hedging, and pleasantries. Drop articles (a/an/the) and softeners (just, really, basically, actually). No preamble, no restating the question, no "happy to help." Fragments are fine. Keep technical terms and code blocks exact. Pattern per point: [thing] [action] [reason]. Next step if any.
- Mettez la règle laconique une seule fois dans le prompt système, pas à chaque tour utilisateur — la répéter re-paie le coût d'entrée à chaque appel.
- Ne compressez jamais le code, les identifiants, le JSON ou les nombres. Compressez uniquement la prose.
- « Be concise. Return JSON only. » représente à lui seul ~60 % des économies de sortie atteignables — écrivez-le avant de vous tourner vers des astuces plus sophistiquées.
- Le style laconique réduit UNIQUEMENT la sortie. Il ne fait rien pour un prompt système de 20k tokens que vous renvoyez à chaque appel — ça, c'est un problème d'entrée/cache.
- Sur les tâches à réflexion étendue, les tokens de raisonnement ne sont pas affectés ; vous ne réduisez que la réponse finale visible.
Compressez la sortie des outils avant qu'elle ne revienne dans le contexte (RTK)
Caveman réduit ce que Claude écrit. La fuite en miroir dans les sessions agentiques, c'est ce que Claude relit : chaque git status, npm test, ls -la ou log de build qu'un agent de code exécute est renvoyé — en-têtes, barres de progression et tout le reste — directement dans la fenêtre de contexte sous forme de tokens d'entrée au tour suivant. Sur une longue session Claude Code, ce bruit d'observation dépasse souvent le prompt système.
rtk (« Rust Token Killer », Apache-2.0, dans homebrew-core) est un proxy CLI visant exactement ça. rtk init -g installe un hook PreToolUse sur l'outil Bash de Claude Code (rtk hook claude) qui réécrit de façon transparente chaque commande en rtk <command> et compresse sa sortie — en supprimant les en-têtes et le bruit visuel, en groupant les lignes similaires, en dédupliquant les répétitions avec des compteurs et en tronquant la redondance — avant qu'elle n'atteigne le modèle.
Installer RTK et brancher le hook global (macOS)
brew install rtk # see the repo for cargo / other installers rtk init -g --hook-only # PreToolUse(Bash) hook only, no RTK.md file # undo anytime: rtk init -g --uninstall
Le drapeau --hook-only compte pour le budget de tokens : le rtk init par défaut écrit aussi un fichier d'instructions RTK.md qui se charge à chaque session — un coût d'entrée fixe qui combat en partie les économies. Le mode hook-only garde la compression de sortie et n'ajoute rien au préfixe. Redémarrez Claude Code après rtk init -g pour que le hook se charge.
- RTK et caveman sont complémentaires, pas redondants : caveman compresse la SORTIE du modèle, RTK compresse l'ENTRÉE des résultats d'outils (les observations renvoyées à chaque tour). Les empiler couvre les deux directions.
- Le hook se déclenche à chaque appel Bash et réécrit de façon transparente — vous ne changez pas votre façon de prompter.
- Mesurez avec la vraie facture, pas le README. Si vos sessions sont pauvres en commandes shell, RTK a peu à compresser — son gain croît avec le bruit de votre sortie d'outils.
Mettez en cache le préfixe réutilisé (économies en entrée)
Si de nombreux appels partagent un grand bloc inchangé — un long prompt système, un catalogue d'outils, un document de référence — le cache de prompt le traite une fois et le réutilise à une fraction du prix d'entrée à chaque appel ultérieur. C'est le changement structurel à plus fort effet de levier pour les charges de travail de chat et d'agent, car il rapporte à chaque tour.
La seule règle : le préfixe mis en cache doit être identique octet pour octet entre les appels. Un timestamp égaré ou une liste d'outils réordonnée près du début fait silencieusement chuter votre taux de succès à zéro. La mécanique complète, le snippet cache_control à copier-coller et la façon de vérifier les succès sont dans Cache de prompt et optimisation des coûts.
- Déplacez le prompt système, les outils et les documents au début ; gardez le tour changeant de l'utilisateur à la fin.
- Attachez cache_control au dernier bloc stable pour que tout le préfixe soit mis en cache. Voir le snippet dans notre page sur le cache de prompt.
- Lisez cache_read_input_tokens dans l'usage de la réponse — supérieur à zéro signifie que vous économisez ; zéro sur des appels répétés signale un invalidateur silencieux.
Élaguez le contexte que vous envoyez
Le cache réutilise le contexte à bas prix, mais le token le moins cher est celui que vous n'envoyez jamais. Auditez ce qu'il y a réellement dans la fenêtre :
- Élaguez le prompt système. Les longs blocs d'instructions accumulent des scories. Coupez les exemples qui ne justifient plus leurs tokens ; gardez un exemple fort plutôt que cinq médiocres.
- Récupérez, ne déversez pas. Au lieu de coller un document entier, ne cherchez que les passages pertinents (RAG). Envoyer un PDF de 50 pages pour répondre à une seule question est le gaspillage le plus courant.
- Compactez les longues sessions. Quand une conversation grandit, remplacez les vieux tours par un court résumé glissant au lieu de transporter chaque message pour toujours. L'historique, ce sont des tokens d'entrée que vous re-payez à chaque appel.
- Dimensionnez le catalogue d'outils. Chaque définition d'outil, ce sont des tokens d'entrée à chaque requête. N'exposez que les outils dont la tâche courante a besoin.
- Compressez les fichiers de mémoire statiques.
CLAUDE.mdet les notes de mémoire sont de l'entrée réutilisée que vous re-payez à chaque session. Les réécrire en prose laconique « caveman » (par ex. la commandecaveman-compressdu plugincaveman) en grignote une part — mais attendez-vous à des chiffres à un seul chiffre sur des fichiers déjà sobres : une passe pratique sur unCLAUDE.mdserré d'environ 350 mots n'a coupé qu'environ 10 %. Le levier est réel mais petit ; ne sacrifiez pas la clarté des instructions de votre config globale pour le poursuivre.
Dimensionnez le modèle au besoin
Ne payez pas le tarif Opus pour une tâche de niveau Haiku. Classification, extraction, formatage simple et routage tournent généralement très bien sur le plus petit modèle à une fraction du prix par token. Réservez les modèles plus grands au raisonnement vraiment difficile, et envisagez le routage : un modèle bon marché gère la majorité facile, en n'escaladant que les cas difficiles. Voir Choisir un modèle et Tokens, contexte et tarification pour les compromis.
Préférez la sortie structurée à la prose
Demander du JSON (ou un autre schéma serré) au lieu d'un paragraphe explicatif réduit les tokens de sortie et supprime les devinettes de parsing en aval. Dire à Claude de ne renvoyer qu'un objet compact comme {"label": ..., "score": ...} génère une fraction des tokens d'une réponse bavarde — et vous évitez complètement le préambule « Voici le résultat : ». Détails dans Sortie structurée.
Regroupez ce qui n'est pas urgent
Pour le travail hors ligne où vous n'avez pas besoin d'une réponse en quelques secondes — évals, classification en masse, étiquetage de jeux de données, résumé d'une archive — l'API Message Batches d'Anthropic exécute les requêtes de façon asynchrone avec une remise de 50 % sur les tokens d'entrée et de sortie, les résultats étant généralement renvoyés sous 24 heures.
Empilez ça avec le cache et un modèle bien dimensionné, et la remise combinée sur un gros travail hors ligne est spectaculaire.
Mesurez — ne devinez pas
Optimisez contre des chiffres, pas des impressions. L'endpoint de comptage de tokens d'Anthropic renvoie le nombre exact de tokens d'entrée d'une requête avant de l'envoyer — même forme qu'un appel Messages, et c'est gratuit (avec limite de débit). Utilisez-le pour comparer un prompt gonflé à un prompt élagué, pour décider du routage des modèles et pour garder les prompts dans la fenêtre de contexte.
Compter les tokens avant l'envoi (SDK Python)
import anthropic
client = anthropic.Anthropic()
resp = client.messages.count_tokens(
model="claude-opus-4-8",
system="You are a scientist",
messages=[{"role": "user", "content": "Hello, Claude"}],
)
print(resp.input_tokens) # exact input count, no charge for counting- N'utilisez pas le tokenizer d'un autre modèle (par ex. tiktoken) — les comptes diffèrent selon la famille de modèles. Utilisez l'endpoint d'Anthropic.
- Les tokenizers plus récents peuvent produire ~30 % de tokens en plus pour le même texte que les modèles plus anciens — recomptez lors d'une migration, ne réutilisez pas d'anciennes estimations.
- Lisez input_tokens, cache_read_input_tokens et output_tokens dans l'usage de la réponse pour confirmer que les économies sont bien réalisées en production.
Voir Tokens, contexte et tarification pour les règles de comptage et la formule d'estimation des coûts.
Un avant/après, de bout en bout
Un assistant de tri du support exécute le même prompt système de 4 000 tokens + catalogue d'outils sur chaque ticket et écrit une réponse bavarde de 600 tokens.
- ~4 000 tokens d'entrée renvoyés au prix fort à chaque appel + ~600 tokens de sortie verbeux, sur un grand modèle. Rien en cache, synchrone, réponses en prose.
- Marquez le bloc système+outils de 4 000 tokens avec cache_control. Après le premier appel, il est servi en lectures de cache à une fraction du prix d'entrée.
- Déplacez le tri vers un petit modèle et exigez du JSON uniquement ({"category", "priority", "reply"}). La sortie passe de ~600 tokens de prose à ~120.
- Les rattrapages de tickets nocturnes passent par l'API Batches à la remise de 50 % au lieu d'appels synchrones.
Chaque levier est multiplicatif : entrée en cache × modèle plus petit × sortie plus laconique × remise par lots se composent en une grande réduction totale — tandis que la qualité de la réponse sur cette tâche facile reste inchangée. Mesurez chaque étape avec count_tokens pour prouver le gain plutôt que de le supposer.
Testez-vous
0/4- Répartissez les dépenses en entrée, sortie et contexte réutilisé — chaque catégorie a un remède différent.
- Le style laconique / « caveman » ne réduit que la sortie ; les gains sont grands sur la prose, petits sur les tâches structurées déjà concises.
- Mettez en cache le préfixe stable (identique octet pour octet) pour des économies d'entrée à chaque euro dépensé sur chaque appel.
- Élaguez le contexte, dimensionnez le modèle et préférez le JSON à la prose — des gains bon marché et cumulatifs.
- Regroupez le travail non urgent pour une remise de 50 %, et mesurez toujours avec count_tokens au lieu de deviner.
Sources et lectures complémentaires
- JuliusBrussee/caveman — la skill Claude Code open-source « caveman » (MIT, par Julius Brussee) ; revendique ~65 % de réduction moyenne des tokens de sortie.
- « I Benchmarked the Viral 'Caveman' Prompt… » — DEV Community — benchmark indépendant trouvant ~9–21 % sur les tâches structurées et une alternative plus sobre en 6 lignes.
- rtk-ai/rtk — proxy CLI « Rust Token Killer » (Apache-2.0, dans homebrew-core) ; compresse la sortie des commandes de dev via un hook Bash PreToolUse ; revendique 60–90 % sur les commandes courantes.
- RTK Hook Increases Claude Code Costs by 18% — rtk-ai/rtk #582 — contre-preuve que le hook peut augmenter le coût total dans certaines configurations ; mesurez avant de faire confiance au chiffre annoncé.
- Token counting — Documentation Anthropic — l'endpoint
count_tokenset les notes sur le tokenizer par modèle. - Prompt caching — Documentation Anthropic — mécanique du cache, éligibilité et tarification.
- Introducing the Message Batches API — Anthropic — traitement asynchrone à une remise de 50 %.
- Pricing — Documentation Anthropic — tarifs par token actuels par modèle.