Anthropic vient tout juste de publier un article de blog.
Le message principal : Arrêtez de gaspiller vos tokens, nous en avons marre de regarder ça !
Pour cela, l'entreprise a détaillé six astuces pour économiser de l'argent. Les voici :
1. /clear une fois la tâche terminée. Après avoir corrigé un bug, effacez la conversation actuelle. Ne laissez pas les fichiers lus ou les sorties de commandes de la tâche précédente encombrer le contexte de la suivante.
2. Définissez le modèle et le niveau d'effort (effort level) dès le départ. Si vous changez en cours de route, tout le cache de prompt accumulé est invalidé et l'historique entier de la conversation doit être recalculé au prix fort.
3. Utilisez @ pour référencer les fichiers, ne tapez pas les chemins manuellement. En attachant le fichier directement au message avec @, Claude n'a pas besoin de dépenser un autre appel d'outil pour le lire. Si vous ne tapez que le nom du fichier, Claude peut d'abord le rechercher et ouvrir plusieurs fichiers pour tester, toutes ces opérations seront ajoutées à l'historique et traînées dans chaque tour suivant.
4. Ajoutez un paramètre silencieux (quiet flag) aux commandes générant beaucoup de sortie. Écrivez quelque chose comme `--reporter=dot` dans CLAUDE.md pour que la sortie des tests n'affiche qu'un résumé de quelques lignes au lieu de centaines de lignes de détails. Moins il y a de sortie, moins elle occupe de contexte.
5. Faites /compact avant une pause. Compressez la conversation tant qu'elle est encore dans le cache, le coût n'est qu'un dixième du prix normal. Si vous attendez que le cache expire après votre pause, il faudra relire et recompresser toute la conversation au prix fort.
6. Confiez les tâches à forte sortie à un sous-agent (subAgent). Le sous-agent s'exécute dans une fenêtre de contexte indépendante et ne renvoie que la conclusion. Les fichiers lus et les sorties de commandes générées pendant le processus n'entrent pas dans votre conversation principale.
La vie d'un token, de sa naissance à sa mort
Avec Claude Code, l'API fonctionne à la consommation, et l'abonnement mensuel va de 20 à 200 dollars selon trois paliers.
Selon les estimations officielles, les développeurs consomment en moyenne 13 dollars de tokens par jour, dépensant entre 150 et 250 dollars par mois.
Et ce n'est que la moyenne. Pour corriger le même bug, selon la façon de poser la question, le coût peut varier du simple au quintuple.
De plus, chaque tour de conversation renvoie l'intégralité du contenu de tous les tours précédents. Plus la session est longue, plus chaque tour est cher.
Pour comprendre où va cet argent, il faut regarder la logique de tarification des tokens.
Chaque fois que vous entrez une instruction dans Claude Code, deux choses se passent en arrière-plan.
La première est le pré-remplissage (prefill), c'est-à-dire que le modèle lit d'un coup toute votre requête, incluant le prompt système, CLAUDE.md, votre message, et tout l'historique de conversation accumulé. Ce sont des tokens d'entrée.
La seconde est le décodage (decode), c'est-à-dire le processus où le modèle écrit mot par mot, incluant sa réflexion, ses appels d'outils et le texte final que vous voyez. Ce sont des tokens de sortie.
La différence clé est ici.
Le pré-remplissage est parallèle, tous les tokens d'entrée passent par le GPU en une fois. Le décodage est séquentiel, chaque token généré nécessite une exécution du modèle. Une réponse de 200 tokens, c'est 200 calculs indépendants.
Il n'est donc pas surprenant que les tokens de sortie coûtent 5 fois plus cher que les tokens d'entrée.
Sur cette base, la facture finale dépend de deux choses.
La première est le modèle, qui détermine le prix unitaire par token.
Opus 5 : Entrée 5$/million de tokens, Sortie 25$.
Sonnet 5 : Entrée 2$, Sortie 10$.
Haiku 4.5 : Entrée 1$, Sortie 5$.
La seconde est le niveau d'effort de raisonnement, qui détermine la quantité de tokens.
Dans une session, la majorité des tokens de sortie sont des tokens de réflexion. Le niveau d'effort contrôle précisément cette quantité. Plus le niveau est élevé, plus le modèle réfléchit longtemps, et plus il génère de tokens de réflexion. La différence entre 'max' et 'low' peut être de plusieurs fois.
Utilisez Sonnet pour les tâches simples, réservez Opus pour les problèmes ardus. L'argent dépensé à utiliser un couteau suisse pour tuer une mouche est le plus mal dépensé.
Le cache de prompt, le meilleur outil pour économiser
Dans la tarification des tokens, il y a une autre variable énorme : le cache.
Chaque requête de Claude Code commence par le même préfixe : le prompt système, les définitions d'outils, CLAUDE.md et l'historique de conversation.
Si le préfixe de cette requête est identique octet par octet à celui de la précédente, le serveur ne recalcule pas, il charge directement le résultat du calcul précédent.
La lecture depuis le cache ne coûte que 0.1 fois le prix d'entrée normal, permettant d'économiser directement 90%.
L'écriture dans le cache est un peu plus chère, jusqu'à 2 fois le prix. Mais l'écriture n'a lieu qu'une seule fois, et chaque tour suivant bénéficie de la lecture à 0.1x.
Prenons un exemple.
Supposons que votre historique de conversation fasse 50 000 tokens. Sans cache, à chaque tour, simplement relire ces 50 000 tokens coûterait le prix fort. Mais si le cache est utilisé, les mêmes 50 000 tokens ne coûtent qu'un dixième.
Sur une session de vingt à trente tours, les économies cumulées grâce au cache sont astronomiques.
C'est votre plus grand levier pour optimiser les coûts.
Mais le cache a une faiblesse fatale. Il doit correspondre de manière continue depuis le premier octet de la requête. Si quoi que ce soit change au milieu, tout ce qui suit devient invalide.
Plus précisément, il y a six situations :
1. Changer de modèle avec /model : Chaque modèle a son cache indépendant. Passer de Sonnet à Opus signifie que tout l'historique de conversation doit être pré-rempli au prix d'Opus, sans remise.
2. Changer le niveau d'effort avec /effort : Le niveau d'effort fait aussi partie de la clé de cache. Après un changement, tout l'historique de conversation doit être recalculé.
3. Activer/désactiver le mode Rapide (Fast mode) : Même effet que les deux précédents, le cache est immédiatement invalidé.
4. Compresser la conversation avec /compact : La conversation est réécrite en résumé, le contenu original ne correspond plus, l'ancien cache est directement invalidé.
5. Expiration temporelle : Le cache reste actif 1 heure pour les utilisateurs abonnés, 5 minutes par défaut pour les utilisateurs de l'API. Après ce délai, le tour suivant nécessite un recalcul complet.
6. Reprendre une ancienne session : Si trop de temps s'est écoulé, le cache a disparu depuis longtemps, il faut presque à 100% recalculer au prix fort.
La mauvaise nouvelle est que si l'une de ces situations se produit, tout l'historique de conversation passe de 0.1x au prix fort.
La bonne nouvelle est qu'en sachant ce qui invalide le cache, vous savez comment le préserver.
Par exemple, verrouillez le modèle et le niveau d'effort au début de la session et ne les changez pas. Ne faites pas /compact tant que le cache est chaud, attendez d'être sur le point de faire une pause.
Il y a aussi un piège caché.
Le mode opusplan change de modèle à chaque fois qu'on y entre ou en sort. Chaque entrée invalide le cache. Chaque sortie, l'invalide à nouveau. Si vous allez et venez, chaque changement coûte un pré-remplissage au prix fort.
Votre conversation grossit en secret
Le cache vous aide à réduire le coût de renvoi de l'historique à un dixième.
Mais il y a une chose qu'il ne peut pas aider : votre historique lui-même gonfle tour après tour.
Chaque fois que Claude lit un fichier, son contenu est ajouté à la conversation. Chaque fois que Claude exécute une commande, sa sortie est aussi ajoutée. À partir du tour où c'est ajouté, chaque tour suivant le transporte.
Le 40ème tour de conversation renvoie l'intégralité du contenu accumulé des tours 1 à 39.
Cette croissance est proche d'un niveau O(n²).
Claude Code a un mécanisme de secours.
Si la sortie d'une commande dépasse 30 000 caractères, elle n'est pas mise dans la conversation, mais écrite dans un fichier temporaire, seule une phrase de résumé reste dans la conversation. Mais les sorties de moins de 30 000 caractères ne sont pas gérées.
Par exemple, un framework de tests qui termine son exécution et imprime 400 lignes de résultats positifs, chaque ligne faisant quelques dizaines de caractères, le total est inférieur à 30 000, ne déclenchant pas ce seuil.
Ainsi, ces 400 lignes restent intactes dans l'historique de conversation et sont renvoyées dans chaque tour suivant.
Face à cela, l'article de blog d'Anthropic donne plusieurs méthodes pratiques pour maigrir.
1. Référencez les fichiers avec @.
Ne tapez pas manuellement les chemins pour que Claude les trouve lui-même. @ attache le fichier directement au message, économisant une opération de lecture.
Si vous ne donnez que le nom du fichier, Claude peut d'abord faire une recherche grep, ouvrir plusieurs fichiers pour voir lequel convient. Toutes ces tentatives entreront alors dans l'historique de conversation, augmentant inutilement les coûts.
2. Ajoutez un paramètre silencieux (quiet flag) aux commandes bruyantes.
Écrivez dans CLAUDE.md : « run tests with npx vitest run --reporter=dot ». Désormais, chaque exécution de tests n'affichera que quelques lignes de points au lieu de centaines de lignes de détails. Une minute de configuration économisera des centaines de lignes de contexte à chaque session.
3. Isolez les tâches à forte sortie avec un sous-agent (subagent).
Le sous-agent s'exécute dans sa propre fenêtre de contexte indépendante et ne renvoie que la réponse finale. Les fichiers lus et les sorties de commandes générés pendant le processus sont tous jetés. Idéal pour des tâches comme « va regarder les logs pour voir s'il y a des anomalies » ou « passe-moi en revue ce gros fichier ». Vous ne voulez que la conclusion, pas le processus.
Et la règle la plus importante.
4. /clear pour changer de tâche.
Après avoir corrigé un bug, faites /clear et commencez la chose suivante. Les fichiers, sorties de commandes et explorations intermédiaires du bug précédent n'ont rien à voir avec la tâche suivante, mais si vous ne les effacez pas, ils occuperont de l'espace et consommeront des tokens à chaque tour suivant.
Si vous ne voulez pas tout vider complètement, /compact peut compresser la conversation en résumé. De dix à vingt mille tokens peuvent être réduits à mille ou trois mille.
De plus, l'article de blog mentionne une opération peu connue mais gratuite, /rewind.
Si les derniers tours sont partis dans la mauvaise direction, /rewind supprime directement ces tours, sans toucher au cache précédent.
Gérer les tokens, c'est aussi une compétence de développeur
Après avoir décomposé toutes ces opérations, vous remarquerez une tendance. Les personnes qui écrivent du code développent un nouvel ensemble de compétences.
Cela n'a rien à voir avec les frameworks ou les langages, mais c'est savoir quel modèle choisir, comment gérer le contexte, comment préserver le cache, à quel niveau régler l'effort de raisonnement.
Ces capacités n'existaient pas il y a un an. Mais aujourd'hui, elles déterminent si vous dépensez 3 dollars ou 30 dollars pour la même tâche.
Anthropic lui-même en est le meilleur exemple.
80 % de leur code est écrit par l'IA, la quantité de fusions de code a été multipliée par 8 en un an, les tests de référence sont 52 fois plus rapides. Avec une utilisation de l'IA aussi intensive, si personne ne gérait les tokens, le coût du seul raisonnement pourrait dévorer le budget.
Sous cet angle, plutôt que de présenter des astuces pour économiser de l'argent, cet article de blog parle d'un nouvel instinct que les codeurs doivent développer à l'ère de l'IA —
Comprendre ce que consomme chacune de vos actions, savoir comment faire plus de travail avec le même budget.
Ceux qui le comprennent ne récolteront pas seulement quelques dollars de tokens.
Références :
https://claude.com/blog/maximizing-the-value-of-your-claude-code-sessions
Cet article provient du compte public WeChat « 新智元 », auteur : 摩西
