Il y a quelques semaines, j’ai publié un article expliquant pourquoi 99 % de ce que vous envoyez à Claude est déjà en cache. Tenseurs KV, VRAM, SSDs locaux — toute la machinerie interne. Mais je n’ai pas abordé la partie la plus douloureuse : la facture.
Parce que le prompt caching est l’une de ces choses qui semblent géniales jusqu’à ce que vous examiniez les chiffres de près. Et là, vous vous rendez compte qu’on vous fait payer pour économiser.
Le paradoxe du coût
Prenons des chiffres avec Claude Sonnet :
| Concept | Prix par million de tokens |
|---|---|
| Entrée normale | $3,00 |
| Écriture en cache | $3,75 (1,25x) |
| Lecture en cache | $0,30 (0,10x) |
Attention à ça : écrire en cache coûte 25 % de plus que de traiter l’entrée sans cache. Vous payez un supplément pour le privilège de rendre la prochaine fois moins cher.
C’est comme payer une adhésion chez Costco. La cotisation annuelle fait mal, mais si vous achetez suffisamment, ça devient rentable.
Le problème, c’est que “suffisant” dépend de combien de fois vous allez lire ce cache avant qu’il expire.
Quand vous perdez de l’argent
Imaginez que vous envoyez un prompt de 100K tokens avec cache_control. Première requête :
100 000 tokens × $3,75/M = $0,375 (écriture en cache)
Si vous aviez envoyé ça sans cache :
100 000 tokens × $3,00/M = $0,300 (entrée normale)
Vous avez payé $0,075 de plus. 25 % en plus. Vous avez perdu de l’argent.
Maintenant, deuxième requête avec les mêmes 100K tokens de préfixe :
100 000 tokens × $0,30/M = $0,030 (lecture en cache)
Comparé à :
100 000 tokens × $3,00/M = $0,300 (entrée normale sans cache)
Vous avez économisé $0,27. En deux requêtes, vous avez récupéré les $0,075 supplémentaires de l’écriture et vous êtes en positif.
Le point d’équilibre est à 1,4 lectures. Traduction simplifiée : si vous allez utiliser ce préfixe au moins deux fois dans les 5 prochaines minutes, le cache est rentable.
Pourquoi avec Claude Code c’est évident
Lors d’une session Claude Code, chaque message que vous envoyez inclut le system prompt, les outils, et tout l’historique de la conversation. Message après message. Sans cache, vous paieriez $3,00/M pour les mêmes 150K tokens de contexte chaque fois que vous écrivez “change la couleur de ce bouton”.
Personne ne peut payer ça.
Avec le prompt caching, vous payez l’écriture une seule fois puis lisez à $0,30/M pendant toute la conversation. Sur une session de 50 messages avec 150K de contexte accumulé, la différence est énorme :
Sans cache : 50 × 150 000 × $3,00/M = $22,50
Avec cache : 1 × 150 000 × $3,75/M + 49 × 150 000 × $0,30/M = $2,77
De $22,50 à $2,77. Une réduction de 88 %. C’est pourquoi Anthropic active le cache par défaut dans Claude Code. Ne pas le faire serait économiquement invivable.
Ce qui est contre-intuitif : la lecture en cache fait exploser votre compteur de tokens
Et voici la partie qui perturbe tout le monde.
Quand vous ouvrez votre tableau de bord d’utilisation et voyez cacheReadInputTokens: 4.241.579.174, votre cerveau dit : “j’ai consommé quatre milliards de tokens”. Et techniquement, c’est vrai : votre compte a traité ces tokens. Mais pas comme vous pensez.
Une lecture en cache ne recalculera pas les tenseurs KV. Elle les lit en mémoire. Cela coûte énormément moins cher à Anthropic qu’une entrée normale, et c’est pourquoi ils le facturent avec une réduction de 90 %.
Mais le chiffre est géant comparé à tout le reste. Mes données réelles d’un mois :
cacheReadInputTokens: 4.241.579.174 (99,5 %)
cacheCreationInputTokens: 196.596.243 (4,6 %)
inputTokens: 1.293.019 (0,03 %)
outputTokens: 2.517.666 (0,06 %)
99,5 % des tokens qui passent par mon compte sont des lectures en cache. Si Anthropic décidait de facturer les lectures en cache au prix normal de l’entrée, ma facture serait multipliée par 10. Littéralement.
Cela a une conséquence pratique : quand vous comparez votre consommation à celle des autres, cacheReadInputTokens est la métrique la plus inutile que vous pouvez trouver. Quelqu’un qui fait 200 sessions courtes et quelqu’un qui fait 10 sessions longues peuvent avoir des lectures en cache radicalement différentes avec le même coût réel.
Les trois leviers que vous pouvez contrôler
Si vous utilisez l’API directement (pas avec Claude Code, où Anthropic gère le cache pour vous), il y a trois choses que vous pouvez faire pour optimiser :
1. Structurez votre prompt du plus stable au moins stable
Le cache fonctionne par préfixe. Si vous modifiez quelque chose au début, cela invalide tout ce qui vient après. C’est la règle d’or :
[System prompt — ne change jamais]
[Définitions des outils — change rarement]
[Documents de référence — change de temps en temps]
[Historique de conversation — grandit à chaque message]
[Dernier message de l’utilisateur — toujours nouveau]
Si vous mettez le message de l’utilisateur avant les documents de référence, vous invalidez le cache des documents à chaque fois. Une bidouille qui vous coûte de l’argent à chaque requête.
2. Utilisez les breakpoints de cache intelligemment
Anthropic vous donne jusqu’à 4 breakpoints (cache_control) par requête. La tentation est d’en mettre un dans chaque bloc. Mais chaque breakpoint force une écriture en cache même si le contenu est identique à celui déjà mis en cache.
Mon recommandation : un breakpoint à la fin du system prompt et un autre à la fin de l’historique de conversation. Deux points d’ancrage, pas quatre.
3. Respectez le minimum cacheable
Le cache ne fonctionne que si le bloc contient au moins 1 024 tokens (2 048 pour Opus). Si votre system prompt fait 500 tokens, il ne sera pas mis en cache. Vous pouvez le vérifier en regardant la réponse de l’API : si cache_read_input_tokens est 0, le bloc n’a pas atteint le minimum.
Ce que vous ne pouvez pas contrôler (et ne devrait pas vous inquiéter)
La validité du cache est de 5 minutes en VRAM (standard tier). Si votre utilisateur met 6 minutes à répondre, il y a une cache miss et tout est recalculé. Vous ne pouvez rien y faire sans payer le extended cache (1 heure de validité, mais au double du prix de l’entrée).
Pour des conversations interactives — quelqu’un parlant avec votre bot — 5 minutes suffisent généralement. Pour les processus batch avec des pauses longues entre requêtes, envisagez le extended cache si les prompts sont longs. Faites le calcul : est-ce que le double de l’écriture est amorti par les lectures ?
L’effet psychologique
Il y a un effet secondaire que personne ne mentionne : le cache vous incite à faire plus de requêtes, pas moins. Parce que vous savez que chaque requête supplémentaire coûte une fraction de la première.
C’est le même mécanisme que les forfaits illimités pour les données mobiles. Quand vous êtes passé de payer au Mo à une offre illimitée, vous avez commencé à utiliser plus de données. Pas parce que vous en aviez besoin, mais parce que le coût marginal était nul.
Avec le prompt caching, le coût marginal d’une requête supplémentaire (si le contexte est déjà mis en cache) est presque uniquement le coût de la sortie. Et cela change votre comportement. Vous commencez à itérer plus rapidement. À poser des questions plus courtes. À utiliser le modèle comme un rubber duck sous stéroïdes.
Est-ce que c’est mauvais ? Cela dépend. Si vous avez un plafond de dépenses ou un quota comme Claude Max, cela peut être un piège : le coût par requête baisse, mais le nombre de requêtes augmente. Et le quota est mesuré en consommation totale, pas en coût marginal.
En résumé
Le prompt caching est l’une de ces optimisations qui fonctionnent exactement à l’opposé de ce que votre intuition attend :
- Vous payez plus au début (l’écriture coûte 1,25x).
- Vous payez beaucoup moins après (la lecture coûte 0,10x).
- Le point d’équilibre est ridiculement bas (1,4 lectures).
- Les chiffres de consommation sont trompeusement énormes (99 % de vos tokens sont des lectures en cache bon marché).
- L’ordre de votre prompt compte plus que vous le pensez (préfixe stable = plus de cache).
Si vous utilisez l’API d’Anthropic et que vous n’utilisez pas le prompt caching, vous jetez de l’argent par la fenêtre. Si vous l’utilisez déjà et ne comprenez pas votre facture, maintenant vous savez pourquoi : le cache vous facture le double pour vous faire économiser 90 %. Et une fois les calculs faits, c’est la meilleure affaire qui soit.
Articles connexes : Si vous voulez comprendre la machinerie interne (tenseurs KV, VRAM, hachage par préfixe), lisez Pourquoi 99 % de ce que vous envoyez à Claude est déjà en cache. Et si vous êtes intéressé par la manière dont j’estime mon quota sans accès à l’API, Tokamak : estimer le quota de Claude sans API.