Anthropic vient de publier un article de blog.
Le message principal est le suivant : Arrêtez de gaspiller vos tokens inutilement, nous n'en pouvons plus de voir cela !
À cette fin, l'équipe officielle a détaillé six méthodes pour économiser, que nous partageons ici sans attendre :
1. Faites /clear une fois la tâche terminée. Après avoir corrigé un bug, effacez la conversation en cours. Ne laissez pas les fichiers lus et les sorties de commandes de la tâche précédente s'accumuler dans la tâche suivante, occupant inutilement le contexte.
2. Définissez le modèle et le niveau d'effort (intensité de raisonnement) dès le début. Si vous changez en cours de route, le cache d'inférence précédemment accumulé sera entièrement invalidé, et toute l'historique de la conversation devra être recalculée au prix fort.
3. Utilisez @ pour référencer les fichiers, ne tapez pas les chemins manuellement. En attachant directement le fichier 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 effectuer une recherche, puis ouvrir plusieurs fichiers pour tester. Toutes ces opérations entreront dans l'historique de la conversation et seront portées à chaque tour suivant.
4. Ajoutez un paramètre de silence (quiet flag) aux commandes produisant beaucoup de sorties. Écrivez une configuration comme --reporter=dot dans le fichier CLAUDE.md, afin que la sortie des tests n'imprime que quelques lignes de résumé, et non des centaines de lignes de détails. Moins la sortie est longue, moins elle occupe de contexte.
5. Faites /compact avant de faire une pause. Compressez la conversation pendant 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 retour pour compresser, il faudra relire et recompresser tout 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. Une fois terminé, il ne renvoie que la conclusion. Les fichiers lus et les sorties de commandes générés pendant le processus n'entrent pas dans votre conversation principale.
La vie d'un token, de sa création à sa facturation
Lorsque vous utilisez Claude Code, l'API est facturée à la consommation, et les abonnements mensuels sont divisés en trois paliers, de 20 à 200 dollars.
Selon les estimations officielles, les développeurs consomment en moyenne 13 dollars de tokens par jour, avec des dépenses mensuelles comprises entre 150 et 250 dollars.
Et ce n'est que la moyenne. Pour corriger le même bug, selon la façon de poser la question, les coûts peuvent varier de plusieurs fois.
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 devient cher.
Pour comprendre où va cet argent, il faut examiner la logique de tarification des tokens.
Chaque fois que vous saisissez une instruction dans Claude Code, deux choses se produisent en arrière-plan.
La première est le préremplissage (prefill), c'est-à-dire que le modèle lit d'un coup votre requête entière, y compris l'invite système, le fichier CLAUDE.md, votre message, ainsi que tout ce qui a été accumulé dans l'historique de la conversation. Ce sont tous des tokens d'entrée.
La seconde est le décodage (decode), c'est-à-dire le processus par lequel le modèle écrit mot par mot, y compris sa réflexion, ses appels d'outils et le texte que vous voyez finalement. Ce sont tous des tokens de sortie.
La différence clé est ici.
Le préremplissage est parallèle, tous les tokens d'entrée passent une fois par le GPU. 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 difficile de comprendre pourquoi les tokens de sortie sont 5 fois plus chers 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 de chaque token.
Opus 5, entrée 5 dollars par million de tokens, sortie 25 dollars.
Sonnet 5, entrée 2 dollars, sortie 10 dollars.
Haiku 4.5, entrée 1 dollar, sortie 5 dollars.
La seconde est l'intensité de raisonnement (effort level), qui détermine la quantité de tokens.
Dans une session, la plupart des tokens de sortie sont des tokens de réflexion (thinking tokens). L'intensité de raisonnement contrôle précisément cette quantité. Plus l'intensité est élevée, 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 complexes. L'argent dépensé à utiliser une arme puissante pour une tâche insignifiante est le plus gaspillé.
Le cache d'inférence (prompt cache) est le plus grand outil d'économie
Il y a une autre variable énorme dans la tarification des tokens : le cache.
Chaque requête de Claude Code commence par le même préfixe : l'invite système, les définitions d'outils, le fichier CLAUDE.md et l'historique de la conversation.
Si le préfixe de cette requête est identique, octet par octet, à celui de la requête précédente, le serveur ne recalcule pas, mais charge directement le résultat du calcul précédent.
La lecture depuis le cache ne coûte que 0,1 fois le prix normal des tokens d'entrée, permettant d'économiser directement 90%.
L'écriture dans le cache est un peu plus chère, jusqu'à 2 fois. Mais l'écriture n'a lieu qu'une seule fois, et chaque tour suivant bénéficie de la lecture à 0,1 fois le prix.
Prenons un exemple.
Supposons que votre historique de conversation comporte 50 000 tokens. Sans cache, chaque tour nécessiterait de payer le prix fort rien que pour relire ces 50 000 tokens. Mais si le cache est utilisé, les mêmes 50 000 tokens ne coûtent qu'un dixième du prix.
Une session qui dure vingt ou trente tours, les réductions accumulées grâce au cache sont astronomiques.
C'est votre plus grand levier pour économiser.
Mais le cache a une faiblesse mortelle. Il doit correspondre de manière continue à partir du premier octet de la requête. Si quelque chose change à n'importe quel endroit intermédiaire, 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 la conversation doit être prérempli au prix d'Opus, sans réduction.
2. Changer l'intensité de raisonnement avec /effort : L'intensité de raisonnement fait également partie de la clé de cache. Après un changement, tout l'historique de la conversation doit être recalculé.
3. Activer/désactiver le mode rapide (Fast mode) : L'effet est le même que pour les deux cas précédents, le cache est directement 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 due au temps : Le cache des utilisateurs abonnés reste vivant pendant 1 heure, 5 minutes par défaut pour les utilisateurs de l'API. Après le délai, le tour suivant effectue un calcul complet au prix fort.
6. Reprendre une ancienne session : Après trop longtemps, le cache a depuis longtemps disparu, il faut presque à 100% recalculer au prix fort.
La mauvaise nouvelle est que si l'une de ces situations se produit, cela signifie que tout l'historique de la conversation passe du prix à 0,1 fois au prix fort.
La bonne nouvelle est qu'en sachant ce qui peut invalider le cache, on sait comment le préserver.
Par exemple, verrouillez le modèle et l'intensité de raisonnement au début de la session et ne les changez pas pendant toute la durée. Ne faites pas /compact pendant que le cache est encore chaud, attendez d'être sur le point de faire une pause pour l'exécuter.
Il y a aussi un piège caché ici.
Le mode opusplan change de modèle à chaque entrée et sortie du plan. À chaque entrée, le cache est invalidé. À la sortie, il est de nouveau invalidé. Si vous allez et venez, chaque saut est 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 également ajoutée. À partir du tour où l'ajout se produit, chaque tour suivant les transporte.
Le 40e tour de conversation renvoie l'intégralité du contenu accumulé des tours 1 à 39.
Cette croissance est de l'ordre de O(n²), proche du carré.
Claude Code a un mécanisme de secours.
Si la sortie d'une commande dépasse 30 000 caractères, elle n'est pas insérée dans la conversation, mais écrite dans un fichier temporaire, et seul un résumé est placé dans la conversation. Mais les sorties de moins de 30 000 caractères ne sont pas gérées.
Par exemple, une fois qu'un framework de tests a fini de s'exécuter, il imprime 400 lignes d'enregistrements de réussite, chaque ligne faisant quelques dizaines de caractères, le total ne dépassant pas 30 000, ce qui ne déclenche pas ce seuil.
Ainsi, ces 400 lignes restent intactes dans l'historique de la conversation et sont renvoyées à chaque tour suivant.
À ce sujet, l'article de blog d'Anthropic donne quelques méthodes pratiques pour réduire la taille.
1. Référencer les fichiers avec @.
N'entrez pas manuellement les chemins pour que Claude les trouve lui-même. La référence avec @ attache directement le fichier au message, économisant une opération de lecture.
Si vous ne donnez que le nom du fichier, Claude peut d'abord effectuer une recherche grep, ouvrir plusieurs fichiers pour voir lequel convient. Ensuite, toutes ces tentatives entreront dans l'historique de la conversation, augmentant inutilement les coûts.
2. Ajouter un drapeau de silence (quiet flag) aux commandes bruyantes.
Écrivez dans le fichier CLAUDE.md une ligne comme « run tests with npx vitest run --reporter=dot ». Désormais, chaque exécution de tests n'imprimera que quelques lignes de résultats sous forme de points, et non des centaines de lignes de détails. Une minute de configuration permet d'économiser des centaines de lignes de contexte dans chaque session future.
3. Isoler les tâches à grande sortie avec un sous-agent (subagent).
Le sous-agent s'exécute dans sa propre fenêtre de contexte indépendante. Une fois terminé, il ne renvoie que la réponse. Les fichiers lus et les sorties de commandes générés pendant le processus sont tous jetés. C'est idéal pour des tâches comme « va voir ce qu'il y a d'anormal dans les logs » ou « aide-moi à parcourir ce gros fichier ». Vous ne voulez que la conclusion, pas le processus.
Et la règle la plus importante.
4. Utilisez /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 la place 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 compressés en mille à trois mille.
De plus, l'article de blog mentionne une opération peu connue mais gratuite : /rewind.
Si les derniers tours ont dévié, /rewind supprime directement ces tours, sans toucher au cache précédent.
Gérer les tokens est aussi une compétence de développeur
En analysant toutes ces opérations, vous découvrirez une règle. Les personnes qui écrivent du code sont en train de développer un nouvel ensemble de compétences.
Cela n'a rien à voir avec les frameworks ou les langages, mais consiste à savoir quel modèle choisir, comment gérer le contexte, comment préserver le cache, et quel niveau d'intensité de raisonnement est approprié.
Ces capacités n'existaient pas il y a un an. Mais elles déterminent maintenant 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, le volume de fusions de code a été multiplié par 8 en un an, et les tests de référence sont accélérés de 52 fois. Avec une utilisation de l'IA aussi intense, si personne ne gérait les tokens, les coûts d'inférence pourraient à eux seuls dévorer le budget.
Sous cet angle, plutôt que de dire que cet article de blog parle de techniques d'économie, il serait plus juste de dire qu'il s'agit d'un nouvel instinct que les codeurs doivent développer à l'ère de l'IA —
savoir ce que consomme chacune de vos opérations, et savoir comment faire plus de travail avec le même budget.
Ceux qui le comprennent ne récoltent pas seulement quelques dollars de tokens.
Références :
https://claude.com/blog/maximizing-the-value-of-your-claude-code-sessions
Éditeur : Moïse
Cet article provient du compte public WeChat « New Zhiyuan », auteur : ASI Apocalypse
