Note de l'éditeur : Beaucoup d'utilisateurs de Claude Code ont l'impression que la consommation de tokens est trop rapide et que les conversations longues épuisent facilement le quota. Toutefois, du point de vue des ingénieurs d'Anthropic, ce qui influence réellement le coût, ce n'est pas la quantité de code que vous écrivez, mais si le système réutilise continuellement les contextes déjà traités.

Le point central de cet article est de savoir comment économiser des tokens grâce à un mécanisme de cache. L'auteur a réutilisé plus de 300 millions de tokens par cache en une semaine, avec un volume quotidien de cache atteignant 91 millions. Étant donné que le coût des tokens mis en cache est seulement de 10 % celui des tokens d'entrée ordinaires, cela signifie que les 91 millions de tokens mis en cache équivalent en fait à environ 9 millions de tokens ordinaires facturés. La capacité de Claude Code à gérer des conversations longues semble plus « durable » non pas parce que le modèle fonctionne gratuitement, mais parce que de nombreux contextes répétitifs ont été avec succès réutilisés.

La clé du cache de l'invite consiste à « ne pas interrompre le cache ». Claude Code met en cache par niveaux les invites système, les définitions d'outils, CLAUDE.md, les règles du projet et l'historique des conversations ; tant que le préfixe des demandes suivantes reste identique, Claude peut lire directement le cache au lieu de traiter à nouveau l'ensemble du contexte. Anthropic surveille également en interne le taux de réutilisation du cache d'invite, car il influence non seulement les quotas utilisateurs, mais aussi directement les coûts de service du modèle et son efficacité opérationnelle.

Pour les utilisateurs ordinaires, il n'est pas nécessaire de comprendre tous les détails sous-jacents ; il suffit de maîtriser quelques habitudes clés : ne laissez pas la session inactivée plus d'une heure ; effectuez un bon transfert de session lors du changement de tâche ; évitez de changer fréquemment de modèle ; placez les grands documents dans les Projets plutôt que de les coller à plusieurs reprises dans la conversation.

Cet article présente moins une astuce pour économiser des tokens que一套 méthode d'utilisation de Claude Code plus proche de la pensée ingénieur : traiter le contexte comme une gestion d'actifs, réutiliser continuellement le cache et éviter les calculs répétitifs dans les conversations longues.

The following is the original text:

J'ai économisé 300 millions de tokens cette semaine, soit 91 millions en un seul jour, dépassant 300 millions pour la semaine.

Je n'ai modifié aucun paramètre. Il s'agit simplement du cache de prompt qui fonctionne normalement en arrière-plan.

Mais une fois que j’ai vraiment compris ce qu’est le cache et comment éviter de le « rompre », mes sessions durent bien plus longtemps avec le même quota d’utilisation. Voici donc un guide d’introduction 80/20 sur le cache de prompts Claude Code, sans entrer dans les détails techniques au niveau de l’API.

TL;DR

Le coût des tokens mis en cache est de seulement 10 % du coût des tokens d'entrée ordinaires. 91 millions de tokens mis en cache équivalent à environ 9 millions de tokens facturés.

La TTL du cache pour la version abonnée de Claude Code est de 1 heure ; par défaut, l'API est de 5 minutes ; les sous-agents sont toujours de 5 minutes.

Le cache est divisé en trois niveaux : niveau système, niveau projet, niveau conversation.

Changer de modèle au milieu d'une session détruit le cache, y compris le mode « opus plan ».

Comment sont calculés les frais de cache ?

Chaque token mis en cache coûte 10 % du coût d'un token d'entrée normal.

Ainsi, lorsque mon tableau de bord indique qu’un jour 91 millions de tokens ont été servis depuis le cache, la facturation réelle équivaut environ au traitement de 9 millions de tokens. C’est pourquoi, comparé à l’absence de cache, l’utilisation prolongée de Claude Code donne l’impression que les sessions sont presque « gratuites » étendues.

Deux chiffres sur le tableau de bord méritent une attention particulière :

Cache create : coût unique engendré lors de l'écriture du contenu dans le cache. Il commencera à prendre effet lors de la prochaine conversation.
Cache read : Tokens réutilisés à partir du cache par Claude, tels que votre CLAUDE.md, les définitions d'outils, les messages précédents, etc. Coûte 10 fois moins cher que de les traiter à nouveau comme entrée.

Si votre chiffre de Cache read est élevé, cela signifie que vous utilisez efficacement le cache ; s'il est faible, cela signifie que vous payez à répétition pour les mêmes contextes.

Thariq d'Anthropic a dit une chose qui m'a beaucoup marqué : « Nous surveillons réellement le taux de命中 du cache de prompt ; dès que ce taux est trop bas, un alerte est déclenchée, voire une incident de niveau SEV est déclaré. »

Il a également écrit un excellent article X. Lorsque le taux de命中 du cache est élevé, quatre choses se produisent simultanément : Claude Code semble plus réactif, les coûts des services d'Anthropic diminuent, votre quota d'abonnement semble plus durable, et les sessions de codage prolongées deviennent plus réalistes.

Mais si le taux de précision est très faible, tout le monde en subira les conséquences.

Ainsi, les incitations des deux parties sont en réalité alignées : Anthropic souhaite que votre taux de命中 de cache soit plus élevé, et vous aussi. Ce qui ralentit réellement le processus, ce sont simplement quelques habitudes apparemment mineures qui réinitialisent discrètement le cache.

Comment le cache augmente-t-il à chaque conversation ?

The cache relies on prefix matching, also known as "prefix matching".

Sans entrer dans des détails techniques trop poussés, il suffit de comprendre ceci : tant que le contenu précédemment présent à un emplacement donné est exactement identique au contenu mis en cache, Claude peut réutiliser ces tokens mis en cache.

Une toute nouvelle session, qui se déroule à peu près ainsi :

Selon la documentation de Claude Code, une nouvelle session fonctionne généralement ainsi :

Première conversation : aucun cache n'existe encore. Le prompt système, le contexte de votre projet (par exemple, CLAUDE.md, mémoire, règles) ainsi que votre premier message seront tous retraités et écrits dans le cache.

Deuxième conversation : tout le contenu de la première conversation est désormais mis en cache. Claude n'a besoin de traiter que votre nouvelle réponse et le message suivant. Ce tour coûtera beaucoup moins cher.

Troisième conversation : même logique. Les conversations précédentes restent en cache ; seule la dernière interaction doit être traitée à nouveau.

Le cache lui-même peut être divisé en trois niveaux :

Article de Thariq sur X :

Couche système (System layer) : inclut les instructions de base, les définitions d'outils (read, write, bash, grep, glob) et le style de sortie. Cette couche est mise en cache globalement.

Couche projet (Project layer) : inclut CLAUDE.md, memory, règles du projet. Cette couche est mise en cache par projet.

Couche de conversation : inclut les réponses et les messages, qui augmentent à chaque tour de conversation.

Si tout changement intervient au niveau du système ou du projet au cours de la session, tout le contenu doit être recaché depuis le début. Il s'agit de l'opération la plus « coûteuse ». Imaginez ceci : vous êtes déjà à la 16e message, lorsque soudainement le prompt système est modifié ou que la session est interrompue pendant une heure — tous les tokens depuis le premier message doivent alors être traités à nouveau.

Confusion entre 1 heure et 5 minutes

C'est l'endroit le plus facile à mal comprendre.

Abonnement Claude Code : TTL par défaut de 1 heure.

Claude API : la TTL par défaut est de 5 minutes. Vous pouvez payer un coût plus élevé pour la porter à 1 heure.
Sub-agent sous tout plan : toujours 5 minutes.

Chat web sur Claude.ai : aucune documentation officielle n'est disponible. Il est possible que ce soit identique à la version abonnée, mais je n'ai pas encore confirmé.

Il y a quelques mois, de nombreux utilisateurs se sont plaints du fait que les quotas d'abonnement Claude étaient consommés trop rapidement. À l'époque, certains pensaient qu'Anthropic avait réduit discrètement la TTL de 1 heure à 5 minutes sans en informer les utilisateurs. Mais ce n'était pas le cas : la TTL de Claude Code reste toujours de 1 heure.

Le problème est que la documentation de Claude Code et de l'API est séparée, alors que ces deux éléments sont totalement différents, ce qui a causé beaucoup de confusion.

Si vous exécutez massivement des flux de travail Sub-agent ou utilisez directement l'API, alors ce chiffre de 5 minutes est important. Mais pour 95 % des utilisateurs de Claude Code, ce qui compte vraiment, c'est la fenêtre d'une heure.

Trois habitudes qui couvrent 95 % des utilisateurs

Ce qui suit, c'est ce que je considère comme les parties véritablement utiles dans l'utilisation quotidienne.

Si vous êtes inactif depuis plus d'une heure, le contenu précédent a généralement expiré dans le cache. Votre prochain message reconstruira le cache. Dans ce cas, il est souvent moins coûteux de faire un transfert clair et de démarrer une nouvelle session plutôt que de tenter de reprendre une ancienne session déjà « refroidie ».

/compact ou /clear détruisent déjà le cache, donc autant réinitialiser véritablement à ce stade.

J’ai créé une compétence de transfert de session pour remplacer /compact. Elle résume ce que nous avons accompli, les décisions en suspens, les documents les plus importants et d’où il faut reprendre ensuite. Ensuite, j’exécute /clear et colle ce résumé pour pouvoir reprendre comme si rien n’avait été interrompu.

La commande compact est parfois également lente. Ce skill de transfert prend généralement moins d'une minute à s'exécuter.

Le mécanisme de cache sur Claude.ai n'est pas officiellement décrit en détail, mais les Projets utilisent clairement une optimisation différente des conversations ordinaires. Par conséquent, si vous devez coller un document volumineux, il est préférable de le placer dans un Projet plutôt que de le saisir directement dans la conversation.

Quelles opérations détruisent discrètement le cache ?

Plusieurs événements peuvent réinitialiser complètement le cache sans notification évidente.

Changer de modèle : en raison de la dépendance au cache basée sur la correspondance de préfixe, chaque modèle possède son propre cache. Dès que vous changez de modèle, la prochaine requête lira à nouveau l'historique complet sans aucune correspondance dans le cache.

Mode « Opus plan » : ce paramètre utilise Opus pendant la phase de planification et Sonnet pendant la phase d'exécution. Je l'ai recommandé dans certaines vidéos d'optimisation de jetons, et il y a une raison à cela. Toutefois, il est important de comprendre que chaque changement de plan correspond à un changement de modèle, ce qui implique la reconstruction du cache. À long terme, cela aide toujours à prolonger le quota de session, mais vous devez comprendre ce qui se passe en coulisses.

Il est possible de modifier CLAUDE.md en cours de session : cette modification ne prendra effet qu'au prochain redémarrage. Ainsi, le cache en cours d'exécution ne sera pas affecté.

Les captures d'écran que j'ai présentées précédemment proviennent d'un tableau de bord de token.

C'est un dépôt GitHub très simple. Vous donnez le lien à Claude Code, qui le déploie localement sur localhost ; il lit alors toutes vos sessions précédentes au lieu de commencer à zéro. Dès le départ, vous voyez les données quotidiennes d'input, d'output, de création de cache et de lecture de cache.

Cependant, il convient de noter que ce tableau de bord recense les données Token sur l'appareil local. Si vous passez d'un ordinateur de bureau à un ordinateur portable, les chiffres ne seront pas exactement les mêmes. Chaque appareil possède son propre ensemble de vues statistiques.

Résumé

Le caching des invites est quelque chose qui peut être étudié en profondeur. L'article de Thariq le couvre de manière plus complète ; si vous voulez avoir une vue d'ensemble, il vaut la peine de le lire.

Mais vous n'avez pas besoin de comprendre tous les détails pour en tirer profit. Il vous suffit de maîtriser les 80/20 les plus cruciaux : les jetons mis en cache coûtent 10 fois moins cher que les jetons classiques ; le TTL de Claude Code est d'une heure ; changer de modèle détruit le cache ; effectuer une transition claire entre les tâches est généralement plus avantageux que de continuer à utiliser une ancienne session jusqu'à son expiration.