Dépenser moins de tokens

Ce que c'est et pourquoi ça compte

Un token est un petit morceau de texte : c'est l'unité qui mesure combien le modèle travaille. Chaque message que vous envoyez, chaque fichier que Claude lit, chaque réponse et chaque raisonnement consomment des tokens. Avec un abonnement, ils comptent dans vos limites d'utilisation. Avec l'API, ils finissent sur la facture.

Ce que je n'avais pas compris au début, c'est ceci : à chaque message, Claude Code renvoie au modèle toute la conversation, pas seulement votre dernière phrase. Le cache rend cette relecture moins chère, mais pas gratuite. Une longue conversation coûte donc plus cher à chaque question, même pour une question d'une ligne.

La deuxième chose : l'essentiel du gaspillage, ce n'est pas le modèle que vous choisissez, ce sont les tours pour rien. Vous écrivez une demande vague, Claude fait autre chose, vous dites « refais-le », il relit tout et recommence. Chaque tour se paie.

1. Conversations courtes, fichiers longs

Je ne laisse pas les décisions importantes dans la conversation. Je les écris dans un fichier du projet. Je l'appelle DECISIONS.md, mais le nom, c'est vous qui le choisissez. Il contient peu de choses : ce qu'on a décidé, pourquoi, et ce qui manque.

Quand la conversation s'allonge, ou quand je passe à un travail sans rapport, je la ferme et j'en ouvre une nouvelle. Dans Claude Code, ça se fait avec /clear : vous repartez d'une conversation vide, et les fichiers du projet restent où ils sont.

Avant de fermer, j'écris :

Mets à jour DECISIONS.md avec ce qu'on a décidé aujourd'hui et ce qui manque.

Puis /clear, et dans la nouvelle conversation :

Lis DECISIONS.md et repars de là.

Comme ça, la nouvelle conversation démarre légère, avec seulement ce qu'il faut, au lieu de traîner des heures d'essais, d'erreurs et de messages dépassés. Si vous tenez à une ancienne conversation, vous ne la perdez pas : avec /resume, vous y revenez.

Une remarque sur CLAUDE.md, le fichier d'instructions que Claude Code charge tout seul à chaque session. Je n'y mets que les règles qui valent toujours et je le garde court, parce qu'il entre dans chaque session même quand il ne sert pas. Les décisions du jour vont dans DECISIONS.md, que Claude lit quand vous le lui demandez.

2. Ne collez pas les logs

Un log, c'est le journal de ce que fait le programme pendant qu'il tourne : erreurs, avertissements, messages. Souvent des centaines ou des milliers de lignes. Si vous les collez dans la conversation, elles y entrent toutes et y restent. Et comme la conversation est renvoyée à chaque message, ces lignes, vous les payez à nouveau à chaque question suivante.

Je ne colle plus rien de long. Je dis à Claude où se trouve le fichier, ou je lui demande de lancer la commande lui-même, et je lui demande de revenir seulement avec ce qui compte :

Lis logs/server.log et trouve-moi l'erreur : donne-moi seulement les lignes qui comptent.

Lance toi-même les tests et regarde la sortie : dis-moi ce qui échoue et pourquoi.

Une chose à savoir : ce que Claude lit entre aussi dans la conversation. L'avantage, c'est qu'il peut chercher dans le fichier et lire seulement les passages utiles, au lieu de tout prendre comme quand vous collez. Si la sortie est vraiment énorme, comme tous les tests du projet, je confie le travail à un assistant : le bruit reste dans sa conversation et seul le résumé me revient.

Utilise un assistant pour lancer les tests : rapporte-moi seulement ceux qui échouent et pourquoi.

3. Raisonnement élevé, pas maximum

Dans Claude Code, vous pouvez décider combien Claude réfléchit avant de répondre. Ça s'appelle le niveau d'effort, et il a cinq crans : low, medium, high, xhigh et max. Plus il est haut, plus Claude dépense de tokens à réfléchir, et les tokens du raisonnement se paient comme ceux de la réponse.

Sur les modèles actuels, le niveau de départ est medium. Moi, comme niveau de base, je le laisse sur medium ou high, c'est-à-dire moyen ou élevé, selon le travail : c'est mon choix, pas une règle. Il se change avec la commande /effort : seule, elle ouvre un curseur, sinon vous tapez directement le niveau.

/effort high

Le maximum, je ne l'active que pour la session où il est nécessaire : un bug introuvable, un travail qui touche tout le projet. Ensuite, je repars de mon niveau de base. C'est pratique, parce que max ne vaut que pour la session en cours et ne reste pas enregistré. Et la documentation elle-même prévient qu'en max, le modèle a tendance à trop réfléchir, pour un gain qui souvent ne vaut pas les tokens.

4. Des assistants avec le petit modèle

Claude Code peut confier des morceaux de travail à des assistants, les sous-agents (subagents). Chaque assistant travaille dans sa propre conversation séparée et, à la fin, ne vous rend que le résultat. Pour les travaux simples, comme chercher où une fonction est utilisée, résumer un fichier ou vérifier des textes, pas besoin du plus gros modèle.

Si vous ne dites rien, un assistant utilise en général le même modèle que la conversation principale. Le plus petit modèle, Haiku, convient à ces travaux et consomme moins. Il y a deux façons de l'utiliser.

Vous le demandez sur le moment

Quand Claude lance un assistant, il peut choisir le modèle pour ce travail. Il suffit de le demander :

Utilise un assistant avec le petit modèle pour trouver tous les endroits où le login est utilisé, puis donne-moi la liste.

Vous le créez une fois et le réutilisez

Les assistants que vous utilisez souvent peuvent être enregistrés comme fichiers dans le dossier .claude/agents/ du projet. Le plus simple est de demander à Claude d'en créer un. Dans le fichier, le champ model décide du modèle : avec model: haiku, il tourne toujours sur le petit.

Crée un assistant pour ce projet qui cherche dans le code et résume les fichiers. Enregistre-le dans .claude/agents/ et mets-lui model: haiku.

Les assistants consomment aussi des tokens, qui s'ajoutent à ceux de la conversation principale. L'économie vient du modèle plus petit et du fait que leur bruit ne finit pas dans votre conversation.

5. Une demande claire

Trois demandes vagues coûtent plus qu'une demande claire. Avec « corrige le profil », Claude doit explorer la moitié du projet pour comprendre ce que vous voulez dire, puis il corrige peut-être la mauvaise chose, et on recommence. Une demande précise lui fait lire peu de fichiers et aller droit au but.

Avant d'écrire, je mets quatre choses :

• Où : quelle page, quel fichier, quel bouton.
• Ce qui ne va pas : ce qui se passe maintenant.
• Ce que je veux : ce qui doit se passer ensuite.
• Comment je vérifie : un test, un contrôle, un résultat que je peux voir.

Au lieu de « corrige le profil », j'écris :

Sur la page profil, le bouton Enregistrer n'enregistre pas l'e-mail. Corrige-le et ajoute un test qui le prouve. Ne touche à aucun autre fichier.

Le « comment je vérifie » est la partie qui compte le plus : si Claude peut contrôler lui-même son travail, il trouve l'erreur avant que vous ayez à la trouver. Et un « refais-le » en moins, c'est un tour entier de tokens économisé.

Et si Claude part dans la mauvaise direction, arrêtez-le tout de suite avec Échap au lieu d'attendre qu'il ait fini.

Les chiffres : une journée type, sur un mois de travail

Ces chiffres sont un exemple réaliste de la façon dont les choses changent, pas une facture. Ils dépendent de combien vous travaillez, du projet et du modèle. Ils servent à vous montrer d'où vient l'économie.

• Avant, avec les longues conversations et les logs collés : chaque nouvelle fonctionnalité demandait en moyenne 4 ou 5 tours de « refais-le », et une journée de travail consommait environ 6 millions de tokens.
• Après les cinq habitudes : 1 ou 2 tours par fonctionnalité, et la même journée en consomme environ 3 millions.

L'essentiel de l'économie vient de deux choses : les conversations nettoyées, parce qu'une longue conversation est relue en entier à chaque message, et moins de « refais-le ». À la fin du mois, la dépense est à peu près divisée par deux, pour le même travail.

Vos propres chiffres, vous les voyez avec /usage : il montre les tokens de la session et, si vous avez un abonnement, quelle part de vos limites vous avez utilisée. Avec /context, vous voyez ce qui remplit la conversation en ce moment.

La règle : la dépense, ce n'est pas le prix du modèle, c'est le nombre de fois où vous lui faites refaire la même chose.

Les erreurs les plus courantes

• Garder une seule conversation ouverte toute la journée : chaque message renvoie tout l'historique, alors fermez-la avec /clear quand vous changez de travail.
• Laisser les décisions seulement dans la conversation : quand vous la fermez, vous ne les avez plus sous la main, alors faites-les d'abord écrire dans DECISIONS.md.
• Coller des logs et des sorties en entier : dites à Claude où est le fichier et demandez-lui seulement les lignes qui comptent.
• Laisser le raisonnement sur max même pour les petites choses : utilisez-le seulement pour la session du bug difficile, puis repartez de votre niveau de base.
• Envoyer des demandes vagues puis corriger à coups de « refais-le » : écrivez où, ce qui ne va pas, ce que vous voulez et comment vous vérifiez.

Check-list

• J'ai un fichier DECISIONS.md dans le projet
• Je le fais mettre à jour avant chaque /clear
• Je ne colle pas de longs logs dans la conversation
• Raisonnement de base sur moyen ou élevé, max seulement pour la session qui en a besoin
• Les assistants pour les travaux simples utilisent le petit modèle
• Chaque demande dit où, ce qui ne va pas, ce que je veux, comment je vérifie
• De temps en temps, je regarde /usage

Questions fréquentes