Comment réduire Claude Code token usage efficacement ?

On réduit l’utilisation des tokens Claude Code en ciblant le contexte persistant et en optimisant modèle, mémoire et sorties. Voici 7 méthodes concrètes : choix de modèle, CLAUDE.md concis, subagents, ciblage de fichiers, compactage, mise en cache et mémoire externe.

Quel modèle choisir selon la tâche

Quel modèle choisir selon la tâche

Choisir le bon modèle permet de réduire fortement l’usage de tokens sans sacrifier la qualité. Sonnet convient aux tâches légères, Opus pour les analyses profondes et Haiku pour les opérations rapides et répétitives.

Explication des familles et du compromis coût/qualité/latence :

• Présentation rapide : Sonnet privilégie faible coût et latence réduite, utile pour interactions courtes et éditing simple.
• Présentation rapide : Opus favorise qualité et profondeur d’analyse au prix d’un coût et d’une latence supérieurs, adapté aux revues complexes et refactorings multi-fichiers.
• Présentation rapide : Haiku optimise temps de réponse et exécution répétée (scripts, génération de tests), avec coût modéré et qualité suffisante pour tâches routinières.

Démarrage et bascule :

• Commencer sur Sonnet pour prototyper ou pour agents interactifs à faible contexte.
• Bascule vers Opus quand plusieurs signes apparaissent : échecs de tests automatisés, erreurs de compilation répétées, réponses incohérentes nécessitant analyse multi-fichiers ou demande explicite de preuve/justification.

Paramètre /effort :

• Rôle : Contrôle le « budget de réflexion » du modèle, c’est-à-dire la quantité de calcul et d’attention consacrée à la tâche.
• Réduction du coût : Abaisser /effort diminue la consommation de tokens et la latence, au risque d’omettre des cas limites.
• Valeurs recommandées : édition simple 0.2–0.4, refactoring multi-fichiers 0.6–0.8, revue complexe 0.9–1.0.

Exemples de prompts (inclure /effort explicitement) :

// Tests unitaires (Sonnet)
Génère 5 tests unitaires pour la fonction parseDate en JavaScript. /effort:0.3

// Refactoring multi-fichiers (Opus)
Refactorise ce module en extrayant la logique de validation dans une classe séparée, mets à jour les imports dans 6 fichiers. Fournis diffs. /effort:0.7

// Explication technique (Haiku)
Explique simplement le backpressure dans Kafka en 3 points concis. /effort:0.2

Conseils pratiques :

• Débuter toujours sur Sonnet, valider avec tests automatisés, puis monter vers Opus si la qualité chute.
• Automatiser la bascule : déclencher Opus si plus de 3 tests échouent, si la compilation bloque, ou si l’analyse multi-fichiers est requise.

Tâche typique	Modèle recommandé	/effort conseillé	Indicateurs de passage
Génération de tests unitaires simples	Sonnet	0.2–0.4	Itérations multiples pour corriger des cas limites
Refactoring multi-fichiers	Opus	0.6–0.8	Échecs de build, imports cassés, besoin de compréhension globale
Scripts et tâches répétitives	Haiku	0.1–0.3	Faible complexité, exigence de latence
Revue de code approfondie	Opus	0.9–1.0	Demandes de preuves, nombreuses modifications logiques

Que mettre dans CLAUDE.md

Gardez CLAUDE.md concis : instructions stables comme commandes de test, règles de style, contraintes architecturales ; évitez notes volatiles ou historiques longs.

Rôle de CLAUDE.md et impact du volume. Fichier chargé avant chaque entrée pour fournir instructions persistantes. Par conséquent, tout ce qui est dans CLAUDE.md est renvoyé à l’API à chaque tour de conversation. Par exemple, un CLAUDE.md de 5 000 tokens est renvoyé à chaque tour, ce qui multiplie immédiatement l’usage de tokens et le coût. Pour donner une idée chiffrée, 100 tours avec ce fichier équivalent à 500 000 tokens supplémentaires.

Recommandations pratiques. Conserver uniquement informations stables et critiques : paquets requis, commandes de test, chemins à ignorer, règles de formatage et contraintes architecturales incontournables. Déplacer notes de réunion, comptes rendus, gros guides d’implémentation ou historiques vers un stockage externe (wiki, gestionnaire de docs, base de données de connaissances) et référencer par lien ou ID.

Techniques pour condenser. Préférer formes courtes et référencées plutôt que paragraphes longs. Exemple de bonnes pratiques :

• Utiliser listes à puces pour règles : facilite la lecture et réduit la redondance.
• Employer templates courts et placeholders : garder modèles de réponse minimaux.
• Créer alias pour commandes fréquentes : par exemple tests-command -> commande exacte, stocker le détail en doc externe.
• Remplacer procédures longues par référence : stocker l’implémentation complète dans un document et mettre seulement l’ID/lien.

Procédure d’audit. Extraire CLAUDE.md, mesurer tokens section par section avec un tokenizer (ex. tiktoken d’OpenAI ou Hugging Face Tokenizers). Identifier sections rarement utilisées en croisant logs de conversation et recherche de correspondances ; extraire et archiver celles ayant peu d’occurrences. Exemple de script pour compter tokens :

import tiktoken
# Choisir l'encodeur adapté
enc = tiktoken.get_encoding("cl100k_base")
text = open("CLAUDE.md","r",encoding="utf-8").read()
token_count = len(enc.encode(text))
print("Token count:", token_count)

Type d’information	Conserver dans CLAUDE.md (oui/non)	Alternative recommandée
Paquets et commandes de tests	Oui	Verifier courts, garder alias
Règles de formatage	Oui	Liste à puces concise
Notes de réunion	Non	Wiki ou gestionnaire de docs (lien/ID)
Guides d’implémentation détaillés	Non	Doc externe + référence courte

Quand utiliser des subagents

Utilisez des subagents pour isoler tâches verbeuses et renvoyer uniquement des résumés utiles au fil principal.

Définition opérationnelle : Une instance Claude isolée avec sa propre fenêtre de contexte pour traiter tâches verbeuses (recherches, dumps, logs, raisonnement multi-étapes). Cette instance prend en charge la mémoire temporaire et renvoie uniquement un condensé ou un artefact structuré au fil principal.

Avant une liste d’avantages/inconvénients, voici les critères courts pour décider quand en créer un.

• Réduction du contexte principal : Utile quand le texte à traiter dépasse plusieurs centaines à milliers de tokens.
• Coût d’initialisation : Nécessaire à prendre en compte si vous créez des subagents très fréquemment pour de petites tâches.
• Réutilisation et propreté : Préférer un subagent si la tâche est récurrente ou si vous tenez à garder le fil principal lisible.

Workflows types : Exemple 1 — Analyser logs : Le subagent ingère les fichiers de log, produit un résumé structurel et des highlights ; le fil principal ne reçoit que ce résumé. Exemple 2 — Refactoring multi-fichier : Le subagent parcourt les fichiers ciblés, propose un plan et un patch minimal.

Exemples pratiques et pseudocode d’orchestration :

# Lancer subagent, demander résumé de N phrases, valider et ramener résultat
Subagent = spawn_subagent(context_limit=8000)  # Création isolée
Subagent.send({"task":"analyse_logs","files":["a.log","b.log"]})
Summary = Subagent.request({"action":"summarize","max_sentences":5})
If validate(Summary):  # Validation simple (format, non-empty)
  MainConversation.append(Summary)
Subagent.terminate()

Bonnes pratiques pour les résumés : Formater structuré (JSON key: value), inclure méta (source fichiers, plages de lignes, score de confiance entre 0 et 1), fixer des limites de longueur (ex. 5 phrases ou 500 tokens).

Situation	Bénéfice	Coût	Exemple d’usage
Analyse de logs volumineux	Réduit le contexte principal, facilite tri	Démarrage du subagent (~quelques centaines de ms)	Résumé structurel + highlights
Refactor multi-fichier	Plan et patch minimal automatisés	Temps CPU selon taille du dépôt	Parcours + patch proposé
Tâches courtes et isolées	Faible — éviter	Coût disproportionné	Éviter la création d’un subagent

Comment pointer Claude vers des fichiers précis

Comment pointer Claude vers des fichiers précis

Pointer Claude vers des fichiers et plages de lignes précises réduit significativement le travail inutile du modèle et donc le nombre de tokens consommés. Un token est une unité de texte (approximativement 4 caractères ou 0,75 mot en anglais), et chaque analyse superflue augmente la consommation. En ciblant, on obtient des réponses plus rapides, plus pertinentes et moins coûteuses.

Pourquoi la précision réduit les tokens : Préciser fichiers et plages de lignes évite l’exploration de tout le dépôt, donc moins de contexte à charger et à analyser. Préciser le but (recherche de bug, comparaison, revue) oriente la génération et réduit la longueur de la réponse nécessaire.

Formulations de prompt recommandées : Remplacer les consignes vagues par des appels directs vers fichiers et lignes. Par exemple :

Compare src/auth/login.py lines 10-80 with src/auth/session.py lines 5-40 and list functional differences.

Privilégier des verbes opérationnels (Compare, Identify, Fix, Summarize) et indiquer le format de sortie (liste, diff compact, patch).

Utilisation du mode plan : Demander d’abord un plan étape par étape permet d’éviter d’exécuter des opérations coûteuses immédiatement. Le plan sert à valider l’approche et à restreindre ensuite l’analyse aux étapes utiles. Exemple de bascule : Shift+Tab (bascule) pour demander un plan succinct avant la mise en œuvre.

Scénarios et prompts précis (courts)

• Recherche de bug dans une route API : Reproduce route POST /users error — Inspect api/users.py lines 120-200 and list potential null pointer causes.
• Revue de patch limité : Review changes in patch.txt lines 1-50 only and summarize risky spots.
• Comparaison de fonctions : Compare function validate_email in utils/validators.py lines 30-70 with utils/legacy_validators.py lines 10-40 and report behavioral diffs.

Prompt vague	Prompt précis	Économie attendue
Parcourez le code d’auth et trouvez le bug.	Inspect src/auth/login.py lines 10-80 for IndexError on line 42.	Élevée (réduit beaucoup d’analyse)
Relisez ce patch.	Review patch file patch.diff lines 1-40 only and list security issues.	Moyenne (évite analyse complète)
Comparez les deux modules.	Compare src/moduleA.py lines 5-120 with src/moduleB.py lines 5-120 for API differences.	Faible à moyenne (selon taille)

Comment utiliser /compact pour réduire le contexte

Exécutez /compact pour compresser automatiquement ou manuellement la session et supprimer redondances dans le contexte avant qu’elles s’accumulent.

Exécution simple : /compact fusionne ou supprime les éléments redondants du contexte de la session afin de conserver l’essentiel des informations utiles.

Fonctionnement succinct : Le compactage peut être automatique (règles pré-définies) ou manuel (commande explicite).

Quand l’utiliser : Périodiquement après une étape majeure comme la fin d’une correction, avant de lancer une nouvelle tâche longue, ou automatiquement selon des règles définies (par exemple après 5–10 tours d’échanges ou quand le contexte atteint un seuil que vous définissez).

Consignes d’usage : Vérifier toujours qu’aucune information critique (décision, règle métier, donnée de référence) ne sera supprimée. Combiner /compact avec un résumé structuré qui remplace les échanges longs par une représentation compacte et fiable.

Exemple de résumé structuré (format JSON recommandé pour automatisation) :

{
  "objectifs": "Livrer v1 API /auth avant 2026-06-30",
  "décisions": [
    "Utiliser OAuth2",
    "Base de données PostgreSQL"
  ],
  "tâches_restantes": 3
}

Exemples de commandes et workflow :

• Avant compactage : Faire un check rapide des points critiques (liste de décisions, contraintes, variables secrètes).
• Commande manuelle type :

  /compact --force --keep-tags decisions,config

• Workflow recommandé : Exporter le résumé externe → Exécuter /compact → Valider le résumé conservé dans la session → Continuer.
• Procédure de restauration : Si une information importante manque, recharger le résumé externe sauvegardé ou réinjecter le JSON résumé.

Risques et mitigations : Risque de perte d’historique détaillé si on compacte trop agressivement. Mitiger en conservant un résumé structuré, en taguant éléments à préserver et en testant le résultat du compact avant d’engager des actions critiques.

Situation	Action recommandée	Conséquence attendue
Fin d’une grosse correction	/compact manuel + sauvegarde JSON	Contexte épuré, décisions préservées
Session longue et itérative	/compact automatique selon règles	Conservation efficace du contexte sans intervention
Session courte, tâche ponctuelle	Pas de compact	Historique complet disponible

Comment résumer et mettre en cache les résultats intermédiaires

Résumé et cache des outputs évitent de renvoyer à chaque tour des dumps verbeux : stockez un résumé structuré et récupérez-le quand nécessaire.

Pourquoi résumer et cacher : Réduire les tokens envoyés diminue directement le coût et la latence des appels à Claude Code. Réduire la taille des messages peut diminuer l’usage de tokens de 50–90% selon la verbosité des outputs, ce qui accélère les retours et permet la réutilisation des résultats intermédiaires sans recalculs inutiles.

• Méthodologie simple : Transformer chaque sortie lourde en petit objet JSON contenant métadonnées utiles pour réutilisation et traçabilité.
• Format recommandé : Utiliser un schéma minimal (titre, résumé, source, timestamp, confiance) pour préserver le contexte essentiel sans le dump complet.
• Stockage : Mettre le résumé dans un cache rapide tel que Redis (base en mémoire, latences sub-millisecondes en LAN) ou une base simple (Postgres, SQLite) selon la volatilité.
• Indexation : Indexer par clé logique ou empreinte (hash) de la requête pour retrouver rapidement le résumé pertinent.

Exemple de schéma de résumé :

{
  "id": "file-1234",
  "summary": "Fonction X extrait et normalise les données utilisateurs.",
  "files": ["src/parser.js"],
  "ranges": ["L10-L80"],
  "confidence": 0.92,
  "created_at": "2026-05-01T12:00:00Z"
}

Pseudocode du workflow :

// Appeler Claude pour produire un résumé court
summary = call_claude_short(file_dump)
// Stocker le résumé
cache.set(key, summary)
// Dans le fil principal récupérer résumé et demander mise à jour si obsolète
cached = cache.get(key)
if cached == null or is_stale(cached): updated = call_claude_short(delta) ; cache.set(key, updated)

Stratégies de TTL et invalidation : TTL signifie Time To Live, durée après laquelle l’entrée expire. Lier l’invalidation à des événements de dépôt via webhooks Git (push, merge) ou comparer hash de commit pour regénérer uniquement si le hash a changé.

Type d’output	Format de résumé recommandé	Stockage conseillé	Règle d’invalidation
Patch/PR	{id, summary, files, confidence, created_at}	Redis (cache), Postgres pour historique	Webhook push / hash commit change
Logs verbaux	{id, summary, severity, timestamp}	Redis	TTL court (1h) ou trigger manuel
Analyse statique	{id, summary, findings, confidence}	DB+index	Re-run on code change (commit hash)

Comment externaliser la mémoire persistante

Déplacez mémoires longues vers un store externe et ne rapatriez que les extraits pertinents via récupération ciblée pour limiter le contexte envoyé.

Principe : Ne pas conserver des mémoires larges dans la fenêtre de contexte du modèle. Utiliser un store externe (documents plats, base vectorielle, base relationnelle) et n’envoyer que les passages pertinents au moment où ils sont utiles. Cette approche réduit fortement le nombre de tokens envoyés et améliore la latence.

Pattern RAG appliqué aux mémoires : Le RAG (Retrieval-Augmented Generation) combine récupération d’informations et génération. Chunking signifie découper les documents en fragments cohérents. Embeddings sont des vecteurs numériques représentant le sens d’un texte (explication : vecteur = suite de nombres que les moteurs de similarité comparent). Retrieval par similarité consiste à rechercher les embeddings proches de la requête. Renvoi d’extraits courts limite le contexte et évite d’envoyer des documents entiers.

Workflow concret : Indexer les mémoires longues avec un ID unique et un résumé court. Autoriser deux modes de recherche : recherche par mot-clé pour filtres simples et recherche par similarité d’embeddings pour pertinence sémantique. Renvoyer le top-N extraits (par exemple N=3) condensés et fusionnés dans la requête au modèle.

Exemples (pseudocode) :

# Indexation d'un document long
# Etape 1 : Chunking
chunks = chunk_document(document, size=800)  # Taille en tokens approximatifs
# Etape 2 : Embeddings (conceptuel)
for c in chunks:
    vec = embed(c)  # Embedding via modèle externe (ex: API ou FAISS)
    store.index(id=generate_id(c), vector=vec, summary=short_summary(c))

# Recherche et assemblage pour une requête
query_vec = embed(user_query)
hits = store.search_by_vector(query_vec, top_n=3)
assembled = assemble([condense(h.text) for h in hits])  # Condenser chaque extrait
response = model.generate(prompt + assembled)

Bonnes pratiques : Préférer des extraits très courts (moins d’un couple de paragraphes, soit ~100–300 tokens). Inclure des méta-données pour chaque extrait (source, ID, plage de texte). Vérifier la fraîcheur avec un hash de commit (SHA-256) pour savoir si l’extrait a changé et éviter la réindexation inutile. Prévoir un TTL ou pipeline de réindexation pour données volatiles.

Option	Avantages	Inconvénients
Documents plats (stockage fichier)	Simple à mettre en place, bon pour archives textuelles.	Recherche limitée, peu efficace pour similarité sémantique.
Vector DB (FAISS, Pinecone, Milvus)	Recherche sémantique rapide, scalable, optimal pour RAG.	Nécessite pipeline d’embeddings et ressources pour maintenir l’index.
Base relationnelle	Bonne traçabilité, transactions, jointures méta-données.	Recherche sémantique peu performante sans extension vectorielle.

Prêt à réduire durablement vos coûts de tokens Claude Code ?

En ciblant le contexte persistant (CLAUDE.md, mémoires, sorties verbeuses) et en adaptant le modèle, on réduit rapidement la consommation de tokens. Les techniques présentées — choix de modèle, subagents, ciblage de fichiers, compactage, mise en cache et externalisation de la mémoire — se combinent pour baisser coûts et latence. En appliquant ces méthodes, vous conservez la qualité des résultats tout en gagnant en maîtrise budgétaire.

FAQ

• Comment savoir si je gaspille des tokens à cause du contexte persistant ?
  Surveillez la taille moyenne du contexte renvoyé à chaque tour et identifiez éléments toujours présents (CLAUDE.md, historiques, dumps). Si le même bloc de centaines de tokens revient sans utile changement, il s’agit d’un gaspillage.
• Le /compact supprime des informations importantes ?
  /compact compresse le contexte en conservant l’essentiel, mais il faut vérifier avant d’exécuter et idéalement stocker un résumé externe si vous risquez de perdre des détails opérationnels.
• Quand vaut-il mieux lancer un subagent plutôt que tout faire dans la session principale ?
  Lancez un subagent quand la tâche génère de longs dumps, logs ou raisonnement multi-étapes qui pollueraient le fil principal ; si le gain de propreté dépasse le coût d’initialisation, c’est rentable.
• Que mettre absolument dans CLAUDE.md ?
  Conserver instructions stables et critiques : commandes de test, gestionnaire de paquets, règles de formatage, contraintes architecturales et répertoires à ignorer. Tout le reste va vers un stockage externe.
• Comment combiner cache et mémoire externe pour limiter les tokens ?
  Générez résumés structurés des outputs, stockez-les dans un cache (avec TTL et invalidation par hash de commit) et indexez les mémoires longues dans un store externe pour ne récupérer que des extraits pertinents au moment de la requête.

 

 

A propos de l’auteur

Franck Scandolera — expert & formateur en Tracking server-side, Analytics Engineering, Automatisation No/Low Code (n8n) et intégration de l’IA en entreprise. Responsable de l’agence webAnalyste et de l’organisme Formations Analytics. Références : Logis Hôtel, Yelloh Village, BazarChic, Fédération Française de Football, Texdecor. Dispo pour aider les entreprises => contactez moi.