Ce que le prompt caching coûte vraiment
Et pourquoi ton taux de hit est probablement à 20 %

Si ta facture LLM contient du Anthropic et que tu n'as pas manuellement instrumenté ton taux de cache hit, tu laisses presque certainement 3-5× de réduction de coût sur la table. Ce n'est pas une supposition. C'est ce qu'on voit sur chaque équipe qu'on audite.

Le prompt caching est le plus gros levier de coût de l'API Anthropic. Bien utilisé, il fait passer tes tokens input répétés du plein tarif à 10 % du plein tarif, une remise de 90 % sur la portion de ton prompt qui ne change pas. Mal utilisé, ce qui est le cas de la plupart des équipes, tu payes le prix affiché et tu te demandes pourquoi ta facture est si grosse.

Voici comment ça marche vraiment, pourquoi ton taux de hit est pire que ce que tu crois, et les changements précis qui font passer le hit rate de 20 % à 90 %.

Comment le prompt caching marche vraiment

Quand tu marques une section de ton prompt comme cacheable, Anthropic hashe cette section et stocke sa représentation interne côté serveur pendant 5 minutes. Si exactement le même prefix réapparaît dans les 5 minutes, le modèle ne retraite pas ces tokens depuis zéro, il charge l'état en cache et continue à partir de là.

Le pricing change radicalement :

• Écriture du cache : 1,25× le prix input normal (prime one-time de 25 %)
• Lecture du cache : 0,1× le prix input normal (remise de 90 %)
• TTL du cache : 5 minutes (extensible à 1 heure moyennant frais)

Donc le premier appel paye un peu plus, et chaque appel suivant dans les 5 minutes paye 10 % du coût input sur la portion cachée. Si tu fais beaucoup d'appels avec le même system prompt, le calcul est brutal en ta faveur.

Sauf qu'il y a un piège : les cache hits n'arrivent que si le prefix est identique octet-par-octet. C'est là que la plupart des équipes se plantent.

Pourquoi ton hit rate est pire que ce que tu crois

Trois patterns cassent le caching en silence :

1. Tu mets des champs dynamiques en haut

L'erreur la plus courante. Ton system prompt ressemble probablement à ça :

Tu es un assistant pour Acme Corp.
Utilisateur courant : user_abc123
Date courante : 2026-04-23 14:17:02
Session : sess_9f8a...

Ton job est d'aider les utilisateurs avec :
- Questions de compte
- Facturation
- Problèmes techniques
[... 1 500 tokens d'instructions ...]

Chaque champ au-dessus des instructions est dynamique. User ID, timestamp, session ID. Dès qu'un de ces champs change, le hash change, le cache s'invalide, et tu payes plein tarif pour les 2 000 tokens suivants.

Fix : mets les champs dynamiques à la fin du message, ou dans un message user séparé. Mets les instructions stables en premier.

Ton job est d'aider les utilisateurs avec :
- Questions de compte
[... 1 500 tokens d'instructions stables ...]

---
Utilisateur courant : user_abc123
Date courante : 2026-04-23 14:17:02
Session : sess_9f8a...

Maintenant les premiers 1 500 tokens cachent. À la seconde requête avec les mêmes instructions, tu payes 0,30 $/M au lieu de 3 $/M sur ces tokens.

2. Tu bumpes tes versions de prompt à la légère

Les équipes itèrent sur les prompts constamment. Chaque nouvelle version invalide chaque prefix caché. Si tu shippes un changement de prompt trois fois par jour, ton cache ne vit jamais assez longtemps pour être utile.

Fix : batch les changements de prompt en releases hebdomadaires. Entre les releases, le prefix est stable et peut cacher. Si tu es en mode itération rapide, accepte que le caching ne t'aidera pas, mais alors désactive-le pour ne pas payer la prime d'écriture pour rien.

3. Tu n'as pas posé de cache breakpoints

L'API Anthropic te laisse marquer jusqu'à quatre cache breakpoints par requête. Si tu n'en poses aucun, seul le system prompt cache. Mais tu as probablement plus de contenu statique : exemples few-shot, définitions d'outils, un snippet de knowledge base. Tout ça peut cacher aussi, si tu le marques.

messages = [
    {"role": "system", "content": SYSTEM_PROMPT, "cache_control": {"type": "ephemeral"}},
    {"role": "user", "content": KNOWLEDGE_BASE, "cache_control": {"type": "ephemeral"}},
    {"role": "user", "content": FEW_SHOTS, "cache_control": {"type": "ephemeral"}},
    {"role": "user", "content": current_question},
]

Quatre cache breakpoints. Tous stables entre requêtes. Seul current_question n'est pas caché. Ton coût input effectif par requête s'effondre.

Mesurer ton vrai hit rate

Anthropic renvoie les stats de cache dans chaque réponse API. Elles ressemblent à :

{
  "usage": {
    "input_tokens": 52,
    "cache_creation_input_tokens": 0,
    "cache_read_input_tokens": 2100,
    "output_tokens": 180
  }
}

Trois chiffres que tu devrais tracker :

• input_tokens, input non caché
• cache_creation_input_tokens, payé 1,25× pour écrire le cache
• cache_read_input_tokens, payé 0,1× pour lire le cache

Ton hit rate c'est :

hit_rate = cache_read_tokens / (cache_read_tokens + cache_creation_tokens + input_non_cache)

Si tu ne logges pas ces trois champs par requête, tu pilotes à l'aveugle.

Un hit rate sain sur un chatbot ou un agent avec un system prompt stable devrait être 85-95 %. Si le tien est sous 70 %, un des trois patterns ci-dessus te mord. S'il est sous 30 %, les trois probablement.

Ce qu'un hit rate de 90 % donne en dollars

Faisons le calcul sur un cas concret : un bot de support client, Sonnet 4.6, 5 000 conversations par jour, 4 tours par conversation, system prompt de 2 000 tokens, bloc few-shot de 500 tokens, message utilisateur de 300 tokens par tour.

Sans caching :

• Tokens input par appel : 2 800 (system + few-shots + user)
• Coût input journalier : 5 000 × 4 × 2 800 × 3 $/M = 168 $/jour

Avec caching à 30 % hit rate (typique) :

• Portion cachée : 0,3 × 2 500 tokens (system + few-shots) × 0,30 $/M = 0,00023 $ par appel
• Portion non cachée : 0,7 × 2 500 + 300 = 2 050 tokens × 3 $/M = 0,00615 $ par appel
• Journalier : 5 000 × 4 × 0,00638 $ = 127 $/jour

Avec caching à 90 % hit rate (ce que tu devrais avoir) :

• Portion cachée : 0,9 × 2 500 × 0,30 $/M = 0,000675 $ par appel
• Portion non cachée : 0,1 × 2 500 + 300 = 550 tokens × 3 $/M = 0,00165 $ par appel
• Journalier : 5 000 × 4 × 0,00232 $ = 46 $/jour

Soit 81 $/jour économisés, ou 2 430 $/mois, juste en passant de 30 % à 90 % de cache hit. Sans réécriture de code au-delà du réordonnancement de prompt et de l'ajout de breakpoints.

Les pièges que personne te signale

Quelques edge cases bizarres qu'on a rencontrés :

La taille du system prompt compte. Anthropic ne cache que si la section marquée fait >1024 tokens. Les petits system prompts ne sont jamais cachés même si tu les marques. Si ton system prompt fait 800 tokens, pad-le à 1 100 avec des instructions stables, ou accepte qu'il ne cachera pas.

Les définitions d'outils sont cacheables mais faciles à casser. Si tu génères tes tool schemas dynamiquement (commun avec MCP ou plugins), l'ordre des clés JSON compte pour le hashing. Trie tes clés alphabétiquement ou tu auras des cache misses par drift d'ordre.

Les 5 minutes de TTL sont réelles. Le trafic sporadique (un chatbot qui tire une fois toutes les 10 minutes) ratera chaque cache. Pour les endpoints à faible volume, envisage le TTL d'1 heure (coûte 2× la prime d'écriture mais vit 12× plus longtemps), breakeven autour de 6 cache reads par heure.

Le cache est par région. Si Anthropic fait du failover vers une autre région en cours de session, tu perds le cache. Pas fréquent, mais ça explique les bursts mystérieux de cache misses quand tu vois des incidents provider.

Ce qu'il faut faire lundi matin

Trois actions, par ordre de ROI :

1. Logge les stats cache sur chaque réponse. Si tu ne vois pas ces trois champs dans tes métriques aujourd'hui, tu ne peux pas optimiser en aveugle. C'est un fix de 15 minutes.
2. Réordonne ton system prompt pour mettre les champs dynamiques en dernier. Ça seul fait souvent passer le hit rate de 30 % à 75 %.
3. Marque des cache breakpoints explicites sur les exemples few-shot, les tool defs, et les gros blocs de contexte stable.

Si tu fais ces trois choses, ta facture Anthropic baisse probablement de 40-60 % cette semaine, sans aucun changement côté utilisateur.

Cet article est le deep-dive compagnon de Les maths cachées du pricing LLM, où le cache raté est l'item n°4 dans la liste des six multiplicateurs cachés.