Claude Code Astuces pour économiser de l'argent : les ingénieurs économisent 300 millions de tokens par semaine grâce à la mise en cache, la clé est de ne pas interrompre

Claude Code longue conversation quota ? L’ingénieur Nate Herk révèle qu’il économise 300 millions de tokens par semaine grâce à un mécanisme de cache, avec un maximum de 91 millions par jour. La clé n’est pas combien de code on écrit, mais comment ne pas « interrompre » le cache, pour que la répétition de contexte ne coûte plus rien.
(Précédent : le projet open source badclaude pour accélérer Claude code, a reçu une notification de violation de droits de la part d’Anthropic)
(Complément d’informations : Claude Code ajoute une fonction de tâches planifiées dans le cloud ! Pas besoin d’allumer l’ordinateur, l’IA vérifie automatiquement PR, met à jour)

Table des matières

Toggle

• Le coût du cache n’est que de 10 %, 91 millions de tokens équivalent à 9 millions
• Architecture en trois couches : système, projet, conversation, empilées
• Piège le plus courant de « coupure » : changement de modèle et fenêtre d’1 heure
• Tableau de bord personnalisé de l’ingénieur : visualiser Cache Read et Create
• Astuces pratiques : Session Handoff plus économique que /compact

Beaucoup de développeurs utilisant Claude Code pour coder, la plus grande difficulté est souvent que la limite d’utilisation de tokens s’épuise rapidement comme de l’eau qui coule, et que les longues conversations deviennent presque un luxe.

Mais l’influenceur Nate Herk, qui partage souvent des astuces d’utilisation de l’IA sur la communauté, a révélé dans un tweet X que le vrai coût n’est pas la quantité de code, mais si le système exploite bien le mécanisme de prompt caching. Lui-même a économisé plus de 300 millions de tokens en une semaine, avec un maximum de 91 millions par jour : puisque le coût du cache de tokens est seulement 10 % de celui des tokens d’entrée classiques, cela revient à dépenser environ 9 millions de tokens par jour, ce qui est presque « gratuit » pour prolonger la durée de vie des sessions de programmation.

Cette semaine, j’ai économisé 300 millions de tokens, 91 millions par jour, plus de 300 millions en une semaine.

Je n’ai modifié aucun paramètre. C’est simplement le prompt caching qui fonctionne normalement en arrière-plan.

Mais en comprenant vraiment ce qu’est le cache, et comment éviter de « casser » le cache, ma conversation peut durer plus longtemps avec la même limite d’utilisation. Donc, voici un guide d’introduction 80/20 au prompt caching de Claude Code, sans entrer dans les détails profonds de l’API.

Le coût du cache de tokens n’est que de 10 % de celui des tokens d’entrée classiques. 91 millions de tokens en cache, cela coûte environ 9 millions de tokens facturés.

La TTL (temps de vie) du cache pour la version abonnement Claude est de 1 heure ; par défaut via API, c’est 5 minutes ; pour le sous-agent, c’est toujours 5 minutes.

Le cache se divise en trois couches : système, projet, conversation.

Changer de modèle en cours de conversation détruit le cache, y compris en activant le mode « opus plan ».

les agents de codage ont besoin de boîtes en verre maintenant

jianshuo/ccglass

111 étoiles sur github
créé hier
mit + javascript
proxy local + tableau de bord web pour claude code, codex, deepseek-tui, et kimi
affiche le prompt système complet, schémas d’outils, historique des messages, tokens/cache/coût, et… photo.twitter.com/Wot5SFV16N

— Beau Johnson (@BeauJohnson89) 24 mai 2026

Le coût du cache n’est que de 10 %, 91 millions de tokens équivalent à 900 000

Chaque token mis en cache coûte 10 % de celui d’un token d’entrée classique.

Donc, quand mon tableau de bord indique qu’un jour donné 91 millions de tokens ont été mis en cache, la facturation réelle correspond à environ 9 millions de tokens traités. C’est aussi pour cela qu’en utilisant Claude Code longtemps, on a l’impression que la conversation est « presque gratuite » en termes de prolongation.

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

Cache create : le coût unique pour écrire le contenu dans le cache. Il commence à jouer lors de la prochaine interaction.
Cache read : les tokens que Claude réutilise depuis le cache, comme votre CLAUDE.md, les définitions d’outils, les messages précédents, etc. Comparé à une nouvelle entrée, ce coût est 10 fois inférieur.

Si votre chiffre de Cache read est élevé, cela indique que vous exploitez efficacement le cache ; s’il est faible, cela signifie que vous payez à chaque fois pour le même contexte.

Thariq d’Anthropic a dit une phrase qui m’a marqué : « Nous surveillons en fait le taux de hit du prompt cache, et si ce taux est trop faible, une alerte est déclenchée, voire un incident de niveau SEV. »

Il a aussi écrit un très bon article sur X. Quand le taux de hit est élevé, quatre choses se produisent simultanément : Claude Code se sent plus rapide, le coût du service d’Anthropic baisse, votre quota d’abonnement dure plus longtemps, et la conversation de codage longue devient plus réaliste.

Mais si le taux de hit est faible, tout le monde en pâtit.

Architecture en trois couches : système, projet, conversation, empilées

Les deux parties ont en fait la même motivation : Anthropic veut que votre taux de hit soit élevé, et vous aussi. La seule chose qui peut ralentir, ce sont quelques habitudes apparemment insignifiantes mais qui reconstruisent silencieusement le cache.

Le cache dépend du « prefix matching », c’est-à-dire la « correspondance par préfixe ».

Pas besoin d’entrer dans des détails techniques complexes, il suffit de comprendre : dès que le contenu avant un certain point correspond exactement à ce qui est déjà en cache, Claude peut réutiliser ces tokens.

Une nouvelle conversation commence généralement ainsi :

Selon le fichier Claude Code, une nouvelle session se déroule ainsi :

Premier tour : pas de cache. Le prompt système, le contexte du projet (CLAUDE.md, mémoire, règles), et votre premier message sont traités de nouveau, puis écrits dans le cache.

Deuxième tour : tout le contenu du premier tour est maintenant en cache. Claude ne doit traiter que votre nouvelle réponse et le message suivant. Le coût de cette étape est beaucoup plus faible.

Troisième tour : même logique. La conversation précédente reste en cache, seul le dernier échange doit être traité à nouveau.

Piège le plus courant de « coupure » : changement de modèle et fenêtre d’1 heure

Le cache peut être divisé en trois couches :

D’après l’article de Thariq sur X :

Couche système (System layer) : inclut les instructions de base, définitions d’outils (read, write, bash, grep, glob) et le style de sortie. C’est le cache global.

Couche projet (Project layer) : inclut CLAUDE.md, mémoire, règles du projet. Elle est en cache spécifique au projet.

Couche conversation : inclut réponses et messages, qui s’accumulent à chaque tour.

Si en cours de conversation, le contenu de la couche système ou du projet change, tout doit être re-cache depuis le début. C’est l’opération la plus « coûteuse ». Imaginez : vous en êtes à la 16e réponse, et soudain vous modifiez le prompt système ou faites une pause d’une heure, alors tout le token depuis la première réponse doit être retraité.

C’est là où on se trompe souvent.

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

Tableau de bord personnalisé : visualiser Cache Read et Create

API Claude : TTL par défaut de 5 minutes. Vous pouvez payer plus pour le porter à 1 heure.
Tout plan de sous-agent : toujours 5 minutes.

Chat web Claude.ai : aucune documentation officielle claire. Peut-être comme la version abonnement, mais je n’ai pas encore confirmé.

Il y a quelques mois, beaucoup se plaignaient que leur quota Claude était consommé trop vite. Certains pensaient que Anthropic avait discrètement réduit le TTL de 1 heure à 5 minutes sans prévenir. Mais ce n’est pas le cas, le TTL de Claude Code reste à 1 heure.

Le problème vient du fait que les fichiers de Claude Code et API sont séparés, et ce sont deux choses totalement différentes, ce qui cause beaucoup de confusion.

Si vous exécutez beaucoup de workflows avec Sub-agent ou utilisez directement l’API, alors 5 minutes est important. Mais pour 95 % des utilisateurs de Claude Code, la seule chose à surveiller est la fenêtre de 1 heure.

Voici ce que je trouve vraiment utile dans l’usage quotidien.

Si vous avez dépassé une heure d’inactivité, le contenu précédent a probablement expiré du cache. La prochaine fois, votre message reconstruira le cache. Dans ce cas, il vaut mieux faire une transition claire, puis commencer une nouvelle session, ce qui coûte généralement moins cher.

/compact ou /clear détruisent le cache, autant en profiter pour le reconstruire vraiment à ce moment-là.

Astuces pratiques : Session Handoff plus économique que /compact

J’ai créé une compétence de « session Handoff » pour remplacer /compact. Elle résume ce que nous avons déjà fait, ce qu’il reste à décider, quels fichiers sont prioritaires, et où continuer. Ensuite, je lance /clear, je colle ce résumé, et la conversation peut continuer comme si rien n’avait été interrompu.

L’ordre /compact peut parfois être lent. La méthode Handoff, elle, se termine en moins d’une minute.

Le mécanisme de cache sur Claude.ai n’est pas très documenté officiellement, mais Projects semble utiliser une optimisation différente des conversations classiques. Donc, si vous souhaitez coller de gros fichiers, il vaut mieux les mettre dans le projet, plutôt que dans la conversation.

Plusieurs choses peuvent entraîner une reconstruction totale du cache sans avertissement :

Changement de modèle : le cache dépend du « prefix matching », et chaque modèle a son propre cache. En changeant de modèle, la prochaine requête ne trouvera aucun cache correspondant, et devra tout relire.

Mode « Opus plan » : cette configuration utilise Opus en phase de planification, puis Sonnet en phase d’exécution. Je l’avais recommandé dans des vidéos sur l’optimisation des tokens, et c’est pour une bonne raison. Mais il faut comprendre que chaque changement de plan revient à changer de modèle, donc à reconstruire le cache. Sur le long terme, cela aide à prolonger la limite de conversation, mais il faut connaître ce qui se passe en dessous.

Modifier CLAUDE.md en cours de conversation est possible : cela ne prend pas effet immédiatement, il faut attendre le prochain redémarrage. Le cache en cours d’utilisation n’est pas affecté.

L’image ci-dessus provient d’un tableau de bord de tokens.

https://github.com/nateherkai/token-dashboard
Voici un dépôt GitHub très simple. Tu donnes le lien à Claude Code, qui le déploie localement, et il lit tous tes anciens échanges, au lieu de repartir de zéro. Tu peux voir chaque jour input, output, cache create et cache read.

Attention : ce tableau de bord ne compile que les tokens locaux. Si tu passes d’un PC fixe à un portable, les chiffres ne seront pas identiques. Chaque appareil a sa propre statistique.

La mise en cache du prompt est un sujet très profond. L’article de Thariq est plus complet, si tu veux tout voir, ça vaut le coup de le lire.

Mais pas besoin de tout comprendre pour en profiter. Il suffit de maîtriser l’essentiel 80/20 : le cache de tokens coûte 10 fois moins cher que les tokens classiques ; TTL de Claude Code est de 1 heure ; changer de modèle détruit le cache ; faire une transition claire entre tâches est souvent plus rentable que de laisser une vieille conversation « expirer » puis continuer.