Prompt caching : comment payer dix fois moins cher pour les mêmes tokens

Dans l’article précédent, je posais un constat : les abonnements flat fee à $20 ou $200 sont des prix de lancement, et la correction structurelle des coûts est déjà en marche. J’évoquais en conclusion l’Efficiency Engineering — la capacité à obtenir le même résultat au moindre coût de tokens, de temps et de capital — comme la compétence clé de l’utilisateur pro des prochaines années.

Voici le premier outil concret de cette discipline. Il s’appelle le prompt caching. Il est documenté officiellement par Anthropic. Il peut réduire jusqu’à 90% le coût des tokens d’entrée répétitifs. Et la plupart des développeurs qui paient plein tarif aujourd’hui ne savent pas qu’il existe, ou ne l’utilisent pas encore correctement.

Le problème : vous payez les mêmes tokens en boucle

Avant d’expliquer la solution, il faut comprendre précisément ce qui est facturé. L’API d’Anthropic facture les tokens d’entrée — c’est-à-dire tout ce que vous envoyez au modèle dans chaque requête : le system prompt, l’historique de conversation, les documents de contexte, les définitions d’outils, et enfin la question de l’utilisateur.

Sur Claude Opus 4.6, le token d’entrée coûte $5 par million. C’est le tarif de base, sans optimisation.

Le problème : dans la très grande majorité des applications réelles, une fraction importante de ces tokens d’entrée est strictement identique d’une requête à l’autre. Un system prompt de 5 000 tokens envoyé 500 fois par jour, c’est 2,5 millions de tokens d’entrée quotidiens qui contiennent le même texte répété 500 fois. Sur un mois, uniquement sur ce system prompt, la facture dépasse $375 sur Opus 4.6 — sans qu’une seule ligne de ce texte n’ait changé.

Ce phénomène est particulièrement visible dans trois contextes.

Claude Code et les fichiers de configuration longs. Comme je l’explique dans l’article sur CLAUDE.md, ce fichier est réinjecté dans le contexte à chaque nouvelle session. Un CLAUDE.md bien construit peut facilement atteindre 3 000 à 8 000 tokens. Sans caching, chaque session repaie ces tokens depuis zéro.

Les agents multi-tours. À chaque échange, l’historique de conversation s’allonge. Sans caching, la requête 10 envoie les 9 échanges précédents en intégralité. La requête 20 envoie les 19 précédents. Le coût croît de façon quasi-quadratique avec la longueur de la conversation. C’est précisément le profil des agents Claude Code en session longue — chaque appel accumule un contexte qui grossit sans que le développeur ne le voie directement.

Les pipelines RAG et les applications documentaires. Comme je l’ai analysé dans l’article sur le CAG, les documents sources — bases de connaissances, référentiels techniques, contrats — sont souvent identiques d’une requête à l’autre. Sans caching, chaque question d’un utilisateur rechargera l’intégralité du corpus. Le guide complet sur le RAG détaille la structure de ces pipelines — le caching s’insère naturellement à la frontière entre les documents stables et les questions variables.

Le prompt caching résout exactement ce problème.

Ce qu’est le prompt caching : le mécanisme en clair

L’analogie la plus juste est celle d’un serveur qui garde un plat préparé au chaud plutôt que de tout recuire à chaque commande. La première fois, il faut cuisiner. Les fois suivantes, on réchauffe — plus vite, moins cher.

Techniquement, le prompt caching fonctionne ainsi : lorsqu’Anthropic reçoit une requête avec le caching activé, le système calcule un hash cryptographique du préfixe de votre prompt et stocke la représentation KV cache (key-value cache, le format interne du modèle pour traiter le contexte) associée à ce préfixe. Lors des requêtes suivantes, si le préfixe est identique, le système retrouve ce hash, charge la représentation KV déjà calculée, et reprend le traitement à partir de là — sans recalculer l’attention sur tout ce qui précède. La documentation officielle du prompt caching détaille l’ensemble des paramètres disponibles.

Deux points importants sur ce qui est stocké : Anthropic ne stocke pas le texte brut de vos prompts, seulement le hash et la représentation KV. C’est une distinction importante pour les entreprises soumises à des contraintes de confidentialité ou de Zero Data Retention (ZDR).

La durée de vie du cache est de 5 minutes par défaut. Le cache est automatiquement rafraîchi — sans coût supplémentaire — à chaque lecture. Si votre usage est suffisamment dense pour que chaque requête intervienne dans les 5 minutes suivant la précédente, le cache reste vivant indéfiniment. Une option à 1 heure existe à coût supérieur pour les flux moins fréquents — j’y reviens plus bas.

La hiérarchie tools → system → messages

Le cache suit une hiérarchie stricte dans l’ordre de traitement des blocs de la requête : tools (définitions d’outils), puis system (instructions système), puis messages (historique de conversation). Cette hiérarchie est fondamentale parce qu’elle détermine ce qui invalide quoi.

Une modification des définitions d’outils (tools) invalide le cache à tous les niveaux en cascade — tools, system et messages. Une modification du system prompt invalide system et messages, mais pas tools. Une modification dans les messages n’invalide que la couche messages. La règle est simple : tout ce qui vient avant dans la hiérarchie est invalidé si la couche supérieure change.

Pour visualiser concrètement comment structurer une requête optimisée, voici la disposition idéale des blocs :

┌─────────────────────────────────────────────────────┐
│  tools  (définitions d'outils — changent rarement)  │
│                               cache_control ◄────── breakpoint #1 (TTL 1h)
├─────────────────────────────────────────────────────┤
│  system  (instructions, personnalité, règles)       │
│                               cache_control ◄────── breakpoint #2 (TTL 5min)
├─────────────────────────────────────────────────────┤
│  messages[0..N-1]  (historique de conversation)     │
│                               cache_control ◄────── breakpoint #3 (automatique)
├─────────────────────────────────────────────────────┤
│  messages[N]  (nouvelle question utilisateur)       │
│                          ← pas de cache, change à chaque requête
└─────────────────────────────────────────────────────┘

Les tools et le system prompt, qui ne changent quasiment jamais, sont placés en premier et mis en cache avec un TTL long. L’historique de conversation, qui s’allonge à chaque tour, est mis en cache automatiquement. La question de l’utilisateur, unique à chaque requête, n’est jamais mise en cache.

Le pricing expliqué : les trois types de tokens

Le prompt caching introduit une structure tarifaire à trois niveaux qu’il faut comprendre précisément pour calculer son ROI réel.

Cache write (écriture) : la première fois qu’un préfixe est mis en cache, les tokens correspondants sont facturés 1,25× le tarif d’entrée de base pour un TTL de 5 minutes, ou 2× pour un TTL d’1 heure. On paie donc légèrement plus cher la première requête pour économiser sur toutes les suivantes.

Cache read (lecture) : toutes les requêtes suivantes qui trouvent un cache hit ne paient que 0,10× le tarif d’entrée de base — soit 10% du prix normal.

Tokens non-cachés : les tokens situés après le dernier breakpoint de cache (typiquement la question de l’utilisateur) sont facturés au tarif d’entrée normal.

Sur Opus 4.6, le tableau complet est le suivant (source : documentation officielle Anthropic) :

Le calcul du point de rentabilité

La question pratique est : à partir de combien de lectures un cache est-il rentable ?

En TTL 5 minutes : le write coûte 1,25× le tarif normal. Chaque read coûte 0,10×. Le delta entre un read et un write standard est de 0,90× par lecture. Le surcoût du write par rapport au standard est de 0,25×. Le point de rentabilité est donc à 1 read après le write initial — dès la deuxième requête avec le même préfixe, vous êtes en économie nette.

Un détail que beaucoup manquent : chaque read rafraîchit le TTL gratuitement. En flux dense — requêtes espacées de moins de 5 minutes — le write n’est payé qu’une seule fois par session, puis le cache se maintient indéfiniment tant que l’activité continue. L’amortissement est instantané : dans un pipeline actif, le surcoût du write initial est négligeable face aux centaines de reads qui suivent sans écriture supplémentaire.

En pratique, voici ce que ça donne sur un system prompt de 10 000 tokens sur Opus 4.6, avec 100 requêtes par jour sur 30 jours :

• Sans caching : 10 000 × 100 × 30 × $5/MTok = $150/mois
• Avec caching : 1 write ($0,0625) + 2 999 reads (2 999 × 10 000 × $0,50/MTok) = $15,06/mois
• Économie : 90%, soit $134,94/mois sur ce seul élément

L’économie s’améliore encore si le cache reste vivant en continu (beaucoup de requêtes rapprochées) et si les tokens cachés représentent une grande proportion de chaque requête.

Le gain de latence : l’argument que personne ne cite

Le prompt caching est presque exclusivement présenté comme un outil de réduction des coûts. C’est réducteur. Son impact sur la latence — et plus précisément sur le TTFT (time-to-first-token), le temps avant que le modèle commence à générer sa réponse — est tout aussi significatif, voire plus perceptible en production.

Pourquoi ? Parce que le TTFT est directement proportionnel à la quantité de tokens d’entrée que le modèle doit traiter. Sans caching, sur un contexte de 30 000 tokens (un CLAUDE.md long, un historique de conversation dense, des documents RAG), le modèle doit calculer l’attention sur l’intégralité du contexte avant de produire le premier token. Avec caching, il repart du point où le KV cache s’arrête — c’est-à-dire qu’il ne traite réellement que les quelques dizaines ou centaines de tokens nouveaux.

En pratique, sur des contextes de 20 000 tokens et plus, le gain de TTFT est typiquement d’un facteur 2 à 5. Sur des contextes très longs (100 000 tokens et au-delà), le gain peut dépasser un facteur 10. Anthropic confirme cette amélioration dans sa documentation, sans publier de benchmarks précis — les chiffres varient selon le modèle, la longueur du contexte et la charge des serveurs.

Ce gain de latence a des implications concrètes dans plusieurs scénarios :

Les interfaces conversationnelles. Un utilisateur attend la première réponse : 800ms contre 4 secondes fait une différence perceptible sur l’expérience. Le caching transforme le ressenti d’une application, pas seulement sa facture.

Les agents à chaîne longue. Un agent qui effectue 15 appels API successifs sur un contexte de 50 000 tokens cumule le gain de latence à chaque étape. La réduction du temps total d’exécution peut être dramatique.

Les applications temps-réel. Streaming ou non, le TTFT conditionne la réactivité perçue. Pour les outils intégrés dans un workflow de développement — comme Claude Code — chaque milliseconde économisée est une friction de moins dans la boucle d’itération.

L’argument financier suffit souvent à justifier l’implémentation du caching. L’argument latence le rend incontournable.

Les deux modes d’activation

Anthropic propose deux approches complémentaires pour activer le caching.

Le caching automatique : une seule ligne

C’est le mode recommandé pour démarrer et pour les conversations multi-tours. Il suffit d’ajouter un champ cache_control au niveau racine de la requête :

curl https://api.anthropic.com/v1/messages \
  -H "content-type: application/json" \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -d '{
    "model": "claude-opus-4-6",
    "max_tokens": 1024,
    "cache_control": {"type": "ephemeral"},
    "system": "Vous êtes un assistant spécialisé en droit fiscal français...",
    "messages": [
      {"role": "user", "content": "Quelle est la règle de TVA sur les services numériques ?"}
    ]
  }'
Langage du code : PHP (php)

Le système applique automatiquement le breakpoint de cache sur le dernier bloc cacheable de la requête, et fait avancer ce breakpoint à chaque nouveau tour de conversation. Le comportement sur trois requêtes successives est le suivant :

Aucune gestion manuelle des marqueurs n’est nécessaire : le système déplace le breakpoint à chaque tour.

Note de compatibilité SDK. Le cache_control au niveau racine est la méthode recommandée dans la documentation actuelle (API directe et Azure AI Foundry). Si vous utilisez un SDK dans une version qui ne supporte pas encore ce flag racine — certaines versions beta Python ou TypeScript peuvent avoir un comportement différent — la méthode de repli la plus sûre est de placer un cache_control explicite sur le dernier bloc assistant stable de votre historique. Le comportement est équivalent, simplement géré manuellement. Vérifiez la version de votre SDK et les notes de release correspondantes avant de déployer en production.

Note sur les system prompts vides. Si votre architecture n’utilise pas de system dédié — tout étant injecté directement dans les messages — le caching automatique peut avoir un comportement erratique sur le premier tour de conversation, car il n’a pas de bloc stable antérieur auquel s’ancrer. La bonne pratique est de toujours inclure au minimum un bloc system de base, même minimaliste ("Vous êtes un assistant utile et précis."), qui servira d’ancrage stable pour le breakpoint automatique. C’est aussi une bonne pratique de conception indépendamment du caching : un system prompt explicite améliore la cohérence du comportement du modèle.

Pour un TTL d’1 heure en automatique :

{ "cache_control": { "type": "ephemeral", "ttl": "1h" } }
Langage du code : JSON / JSON avec commentaires (json)

Les breakpoints explicites : le contrôle fin

Pour les cas où différentes sections du prompt changent à des fréquences différentes, les breakpoints explicites offrent un contrôle granulaire. On place cache_control directement sur les blocs individuels :

import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-opus-4-6",
    max_tokens=1024,
    system=[
        {
            "type": "text",
            "text": "Vous êtes un assistant juridique expert en droit des sociétés français.",
            "cache_control": {"type": "ephemeral"}  # System prompt : mis en cache
        }
    ],
    messages=[
        {
            "role": "user",
            "content": [
                {
                    "type": "text",
                    "text": "[Contenu du contrat : 15 000 tokens de clauses contractuelles...]",
                    "cache_control": {"type": "ephemeral"}  # Document : mis en cache
                },
                {
                    "type": "text",
                    "text": "Quelles sont les clauses de résiliation dans ce contrat ?"
                    # Question : non mis en cache, change à chaque requête
                }
            ]
        }
    ]
)
Langage du code : PHP (php)

Dans cet exemple, le system prompt et le document sont mis en cache séparément. Si le document change (nouveau contrat) mais que le system prompt reste identique, seul le cache du document est invalidé — celui du system prompt reste valide.

On peut définir jusqu’à 4 breakpoints explicites par requête. Les deux modes — automatique et explicite — peuvent être combinés, mais le breakpoint automatique utilise alors l’un des 4 slots disponibles.

La fenêtre de 20 blocs : le piège le plus vicieux

C’est le mécanisme le moins bien documenté et celui qui génère le plus de surprises en production. Il faut le comprendre précisément.

Lorsque vous définissez un breakpoint de cache explicite, le système cherche les hits en remontant en arrière depuis ce breakpoint — mais seulement sur les 20 blocs précédents. Au-delà de 20 blocs sans hit, il arrête de chercher.

Prenons un exemple concret : une conversation de 30 blocs de contenu, avec un seul cache_control sur le bloc 30.

• Cas 1 — aucun changement avant la requête 31 : le système vérifie le bloc 30, trouve un hit, ne traite que le bloc 31. ✓
• Cas 2 — vous modifiez le bloc 25 : le système remonte de 30 → 29 → … → 25 (pas de hit) → 24 (hit). Le cache tient jusqu’au bloc 24, seuls les blocs 25-30 sont retraités. ✓
• Cas 3 — vous modifiez le bloc 5 : le système remonte de 30 → 29 → … → 11 (20e vérification). Arrêt. Le bloc 5 est hors fenêtre. Aucun hit, tout est retraité. ✗

La solution dans le cas 3 est de placer un breakpoint explicite sur ou avant le bloc 5. Le système vérifierait alors ce breakpoint indépendamment, trouverait un hit en 4, et limiterait le retraitement aux blocs 5 à 30.

Règle pratique : pour toute conversation ou prompt dépassant 20 blocs de contenu, placez des breakpoints intermédiaires — a minima un au niveau du system prompt et un juste avant le contenu susceptible de changer.

Ce qui invalide le cache silencieusement

C’est là que beaucoup de développeurs perdent des économies sans le savoir. Les modifications suivantes invalident le cache, souvent de façon contre-intuitive :

Deux pièges méritent une attention particulière.

Le toggle web search. Si votre application active ou désactive la recherche web entre les requêtes d’un même utilisateur, elle invalide le cache system à chaque bascule. Pour les applications mixtes (certaines requêtes avec search, d’autres sans), ce comportement peut annuler une grande partie des économies attendues.

L’ordre des clés JSON en tool use. Certains langages randomisent l’ordre des clés lors de la sérialisation JSON (notamment Swift et Go). Si les définitions de vos outils produisent un JSON avec des clés dans un ordre différent d’une requête à l’autre, le hash change et le cache rate systématiquement. La solution est de forcer un ordre stable lors de la sérialisation.

Les tokens minimum : attention aux petits prompts

Le prompt caching ne s’applique pas en dessous d’un seuil minimum de tokens selon le modèle. Même si cache_control est présent, la requête est traitée normalement sans caching si ce seuil n’est pas atteint.

Ces seuils sont ceux publiés dans la documentation Anthropic au moment de la rédaction de cet article. Ils peuvent évoluer avec les nouvelles versions de modèles — vérifiez la page de documentation officielle avant de dimensionner votre implémentation.

Un system prompt de 800 tokens sur Opus 4.6 ne sera jamais mis en cache quoi qu’il arrive — le seuil de 4 096 tokens n’est pas atteint et cache_control est silencieusement ignoré, sans erreur retournée. Pour ces cas, deux options : enrichir le system prompt (souvent justifié — des instructions plus détaillées améliorent la qualité) ou utiliser Sonnet 4.5 dont le seuil de 1 024 tokens est plus accessible.

Le TTL d’1 heure : quand l’utiliser

Le TTL d’1 heure coûte 2× le tarif d’entrée standard pour l’écriture (contre 1,25× pour 5 minutes). Il est rentable dans des scénarios spécifiques.

Les agents à long cycle. Si votre agent met régulièrement plus de 5 minutes entre deux requêtes — parce qu’il attend un retour utilisateur, qu’il effectue des opérations longues, ou qu’il s’agit d’un flux à faible fréquence — le cache de 5 minutes expirera. Avec un TTL d’1 heure, le cache reste valide et la prochaine requête bénéficie d’un hit.

Les sessions utilisateur espacées. Un utilisateur qui pose une question, réfléchit 10 minutes, puis relance une conversation : le cache de 5 minutes est expiré, celui d’1 heure tient.

Les flux de faible fréquence avec latence critique. Le cache réduit le time-to-first-token pour les longs contextes. Si la latence compte et que les requêtes sont espacées de plus de 5 minutes, le TTL d’1 heure maintient cet avantage.

Pour les flux denses (requêtes toutes les 1 à 2 minutes), le TTL de 5 minutes est suffisant et moins coûteux : chaque lecture rafraîchit le cache gratuitement.

On peut mélanger les deux TTL dans une même requête, avec une contrainte : les blocs à TTL long doivent apparaître avant les blocs à TTL court dans la hiérarchie du prompt.

Note Bedrock / Vertex AI. Le TTL d’1 heure est disponible sur l’API Claude directe depuis son lancement. Sur Amazon Bedrock et Google Vertex AI, le support est arrivé plus tard — courant janvier-février 2026 selon les providers. Si vous opérez en environnement corporate via ces plateformes et que votre implémentation date d’avant cette période, vérifiez que le TTL étendu est bien disponible dans votre région et version de l’API avant de l’activer.

Comment vérifier que le cache fonctionne

La réponse de l’API inclut un objet usage qui détaille exactement ce qui a été lu depuis le cache, ce qui a été écrit, et ce qui a été traité normalement :

{
  "usage": {
    "input_tokens": 47,
    "cache_creation_input_tokens": 10000,
    "cache_read_input_tokens": 0,
    "output_tokens": 312
  }
}
Langage du code : JSON / JSON avec commentaires (json)

Sur la première requête, cache_creation_input_tokens est non nul (le système écrit le cache) et cache_read_input_tokens vaut 0. Sur les requêtes suivantes avec le même préfixe, c’est l’inverse : cache_read_input_tokens est non nul et cache_creation_input_tokens vaut 0.

Pour calculer le total réel de tokens d’entrée traités :

total_input = cache_read_input_tokens + cache_creation_input_tokens + input_tokens

Note importante : input_tokens dans la réponse représente uniquement les tokens après le dernier breakpoint — c’est-à-dire la partie non-cacheable de la requête (typiquement la question de l’utilisateur). Ce n’est pas le total des tokens d’entrée. Cette distinction compte pour la gestion des rate limits : les tokens lus depuis le cache ne sont pas décomptés du rate limit.

Pour le TTL d’1 heure, la réponse inclut un objet supplémentaire détaillant les écritures par durée :

{
  "usage": {
    "cache_creation": {
      "ephemeral_5m_input_tokens": 456,
      "ephemeral_1h_input_tokens": 100
    }
  }
}
Langage du code : JSON / JSON avec commentaires (json)

Les cas d’usage où le gain est maximal

Claude Code avec CLAUDE.md et MEMORY.md

C’est probablement le cas d’usage le plus immédiatement rentable pour les développeurs qui utilisent Claude Code intensivement. Comme je le détaille dans les articles sur CLAUDE.md et MEMORY.md, ces fichiers peuvent atteindre plusieurs milliers de tokens. Avec un TTL d’1 heure — adapté à des sessions de travail qui s’étalent sur la durée — ces fichiers ne sont traités qu’une fois par heure au lieu d’une fois par session ou par requête.

Les applications avec system prompt riche

Tout chatbot, assistant métier ou outil spécialisé qui injecte un system prompt de plus de 1 000 tokens bénéficie immédiatement du caching. L’activation automatique avec une seule ligne de configuration suffit. Aucune refonte architecturale n’est nécessaire. C’est aussi le cas des Skills Claude — des system prompts spécialisés réutilisés à chaque appel — pour lesquels le caching est particulièrement rentable.

Les pipelines RAG et CAG

Dans une architecture RAG ou CAG, les documents sources sont souvent stables sur de longues périodes. Les mettre en cache avec un TTL d’1 heure ou les re-cacher à chaque requête (TTL 5 min, rafraîchi à chaque hit) permet de ne payer le traitement de ces documents qu’une fois, quelle que soit la fréquence des questions posées par les utilisateurs.

La règle d’or : dans un pipeline RAG, le cache se place après les documents sources et avant la question de l’utilisateur. Les documents sont stables, la question change à chaque requête.

Les agents multi-tours intensifs

Pour les agents qui enchaînent de nombreux appels API avec accumulation d’historique, le caching automatique est fait pour ce cas. L’historique croissant est automatiquement mis en cache, et seul le nouveau contenu (dernière réponse + nouvelle requête utilisateur) est traité à plein tarif à chaque tour.

Thinking blocks et extended thinking

Une subtilité documentée mais peu connue : les thinking blocks (utilisés avec l’extended thinking) ne peuvent pas être marqués directement avec cache_control, mais ils sont mis en cache automatiquement lorsqu’ils apparaissent dans les tours assistant précédents d’une conversation. Ils comptent comme des tokens d’entrée lors des lectures depuis le cache — à prendre en compte dans les calculs de coût pour les workflows d’extended thinking intensifs.

L’invalidation a cependant un comportement spécifique : si un bloc utilisateur non-tool-result est ajouté à une conversation contenant des thinking blocks, tous les thinking blocks précédents sont supprimés du contexte et le cache correspondant est invalidé.

Limitations et disponibilité

Disponibilité plateforme. Le caching automatique est disponible sur l’API Claude directe et Azure AI Foundry (preview). Le support sur Amazon Bedrock et Google Vertex AI est annoncé mais pas encore déployé. Si vous opérez via ces plateformes, vérifiez la disponibilité au moment où vous lisez cet article.

Isolation workspace. Depuis le 5 février 2026, les caches sont isolés par workspace au sein d’une même organisation — un changement de politique lié au repricing structurel déclenché par le lancement de Claude Opus 4.6. Si vous utilisez plusieurs workspaces (par exemple, un par client ou par environnement), chaque workspace maintient son propre cache — il n’y a pas de partage entre eux. Les organisations différentes ne partagent jamais de cache, même pour des prompts identiques.

Requêtes concurrentes. Un cache n’est disponible qu’après le début de la première réponse. Si vous lancez plusieurs requêtes en parallèle avec le même préfixe, seule la première écrira le cache — les autres ne bénéficieront pas d’un hit. Pour les workflows parallèles, attendez la première réponse avant de lancer les suivantes si vous souhaitez exploiter le cache.

Contenu non-cacheable. Les blocs de type thinking ne peuvent pas être marqués explicitement. Les sous-blocs de citations ne peuvent pas être mis en cache directement (cacher le bloc document parent). Les blocs texte vides ne sont pas mis en cache.

Combiner caching et Batch API : l’optimisation la plus sous-exploitée de 2026

Les multiplicateurs de pricing se cumulent. La Batch API offre 50% de réduction sur les tokens d’entrée et de sortie. Le caching réduit le coût des reads à 10% du tarif standard. Combinés, ils donnent le résultat suivant sur Opus 4.6 :

$0,25 par million de tokens d’entrée sur le modèle le plus puissant d’Anthropic. Soit 5% du tarif normal.

Ce n’est pas une curiosité théorique. C’est probablement l’optimisation la plus sous-exploitée en 2026, particulièrement adaptée aux cas d’usage bulk où un même contexte de référence est réutilisé massivement :

• Data labeling : même grille de critères, milliers de données à classifier
• Knowledge base indexing : même system prompt d’extraction, corpus de documents stables
• Bulk code review : même prompt de revue, centaines de fichiers à analyser
• Génération de fiches produits : même template et règles métier, catalogue entier à traiter

La seule contrainte : la Batch API est asynchrone — les résultats sont retournés en différé (typiquement sous 24h). Pour tous les traitements non-temps-réel, c’est le régime tarifaire optimal. C’est d’ailleurs la combinaison que j’utilise dans ma stack IA 2026 pour les traitements lourds non-urgents.

L’essentiel en pratique

Le prompt caching n’est pas une optimisation de confort. C’est la mesure à prendre en premier, avant de réfléchir à changer de modèle ou de plan tarifaire. Elle s’active en une ligne pour les cas simples, elle est documentée officiellement, et son ROI est mesurable directement dans les champs usage de chaque réponse.

Pour résumer les règles opérationnelles :

• Commencer par le caching automatique (cache_control au niveau racine) pour toutes les conversations multi-tours.
• Passer aux breakpoints explicites dès que différentes sections du prompt ont des cycles de vie différents.
• Placer le contenu stable en premier dans le prompt (tools, system, documents) et le contenu variable (question utilisateur) en dernier.
• Pour les prompts de plus de 20 blocs, ajouter des breakpoints intermédiaires pour rester dans la fenêtre de lookback.
• Surveiller cache_read_input_tokens et cache_creation_input_tokens dans les réponses pour valider que le cache fonctionne.
• Choisir le TTL d’1 heure uniquement si les requêtes sont espacées de plus de 5 minutes et que la latence compte.
• Ne jamais toggler la web search ou les citations dynamiquement si ce n’est pas indispensable — ces toggles invalident le cache system.

Check-list : votre prompt est-il optimisé ?

À garder dans votre documentation interne ou à afficher à côté de votre éditeur.

• [ ] Ordre : mes blocs stables (tools → system → documents) sont bien en début de requête, avant tout contenu variable.
• [ ] System prompt présent : j’ai toujours un bloc system explicite, même minimal — pas de requête sans ancrage système.
• [ ] Stabilité JSON : mes définitions d’outils sont sérialisées avec des clés dans un ordre déterministe (pas de randomisation Swift/Go).
• [ ] Volume suffisant : le bloc à cacher dépasse bien le seuil minimum du modèle (4 096 tokens sur Opus 4.6/Haiku 4.5, 2 048 sur Sonnet 4.6, 1 024 sur Sonnet 4.5).
• [ ] Fenêtre de lookback : j’ai un breakpoint au moins tous les 20 blocs de contenu pour ne pas sortir de la fenêtre de vérification.
• [ ] TTL adapté : si mon flux est espacé de plus de 5 minutes, j’ai activé le TTL 1h sur les blocs concernés.
• [ ] Validation active : je surveille cache_read_input_tokens dans les réponses pour confirmer que les hits se produisent bien.
• [ ] Pas de toggle intempestif : je ne change pas dynamiquement web_search, citations ou tool_choice entre les requêtes d’une même session si je peux l’éviter.

L’IA est déjà une commodité. Ce qui ne l’est pas, c’est la capacité à l’utiliser sans se laisser dépouiller par elle. Le prompt caching est la première ligne de défense.