Limites et points critiques
- Le cache ne fonctionne que sur les préfixes — si vous insérez une variable au milieu, tout ce qui suit n'est pas caché.
- TTL court (5 minutes par défaut chez Anthropic, rafraîchie à chaque utilisation) : sur des requêtes espacées de plus de 5 minutes, le cache expire avant d'être réutilisé ; l'option 1 heure coûte plus cher à l'écriture (2 fois le prix d'entrée).
- Toute modification du préfixe mis en cache (instructions, documents) crée une nouvelle entrée, facturée au prix d'écriture.
- Le taux de réussite du cache dépend du motif d'usage : des requêtes rares ou très variables en profitent peu.
- Les champs d'usage renvoyés par l'API diffèrent selon l'éditeur : chez Anthropic, la réponse distingue cache_read_input_tokens et cache_creation_input_tokens, ce qui permet de suivre le taux de réussite.
Évolution probable (12-24 mois)
- Des durées de vie plus longues (l'option 1 heure d'Anthropic) rendent le cache utile sur des charges moins régulières.
- Une standardisation des API de caching entre éditeurs faciliterait le multi-vendor ; elle n'existe pas à ce jour.
- Le cache de plans d'exécution d'agents (Agentic Plan Caching) est une piste de recherche pour les agents qui répètent les mêmes tâches.
- Les éditeurs ajustent régulièrement durées et tarifs du cache : relire leurs pages officielles avant de budgéter.
Questions fréquentes
Qu'est-ce que le prompt caching en LLM ?+
Le prompt caching est un mécanisme qui sauvegarde le résultat du calcul d'un préfixe de prompt (instructions, contexte) pour le réutiliser sur les requêtes suivantes sans le recalculer. Chez Anthropic, l'écriture dans le cache coûte plus que l'entrée standard (1,25 fois pour la durée de 5 minutes, 2 fois pour 1 heure) et la lecture beaucoup moins (0,1 fois le prix d'entrée pour la plupart des modèles, 0,05 fois pour Claude Opus 5.5 et Sonnet 5.5), d'après platform.claude.com lu le 24/10/2026. Google propose aussi du caching (implicite par défaut sur Gemini 2.5 et plus récents). Pour les autres fournisseurs, voir leur documentation officielle.
À quoi sert le prompt caching ?+
À réduire le coût des LLM en production sur les use cases avec contexte stable : agents conversationnels (system prompt + historique), RAG avec instructions répétées, traitement batch sur documents avec template fixe, pipelines d'extraction. Le gain dépend de la part du prompt qui est stable et de la fréquence des requêtes (voir l'exemple chiffré plus bas dans la page et la FAQ sur le coût).
Différence entre prompt caching et RAG ?+
Le prompt caching cache des tokens d'input pour économiser sur la facturation LLM. Le RAG cache des embeddings dans une base vectorielle pour ne pas recalculer la recherche sémantique. Les deux sont complémentaires : un RAG mature 2026 utilise les deux — cache vectoriel pour le retrieval, prompt caching pour le contexte injecté qui ne change pas. Le prompt caching ne résout pas les hallucinations, le RAG ne résout pas le coût du LLM, donc on combine.
Comment activer le prompt caching en pratique ?+
Sur Anthropic Claude : ajouter cache_control: {type: 'ephemeral'} sur le bloc de contenu à cacher (system prompt, documents) ; durée de vie de 5 minutes par défaut, 1 heure avec ttl: '1h' (platform.claude.com, lu le 24/10/2026). Sur Gemini : le caching implicite est activé par défaut pour Gemini 2.5 et plus récents, le caching explicite passe par l'API generateContent (ai.google.dev, lu le 24/10/2026). Pour OpenAI et Mistral, suivre leur documentation officielle. Structurer son prompt avec la partie stable au début (instructions, contexte) et la variable à la fin (question utilisateur) est critique : le cache fonctionne uniquement sur les préfixes.
Combien coûte le prompt caching et combien fait-il économiser ?+
Chez Anthropic (platform.claude.com, lu le 24/10/2026) : écriture à 1,25 fois le prix d'entrée pour 5 minutes et 2 fois pour 1 heure, lecture à 0,1 fois (0,05 fois pour Claude Opus 5.5 et Sonnet 5.5). Notre calcul à partir du tarif public de Claude Sonnet 5.5 (2 $/M en entrée, écriture 5 min 2,50 $/M, lecture 0,10 $/M, claude.com/pricing lu le 24/10/2026) pour un agent à 1 000 requêtes/jour avec 8 000 tokens de system prompt stable : sans cache, 1 000 × 8 000 = 8M tokens × 2 $/M = 16 $/jour ; avec cache, 8 000 × 2,50 $/M = 0,02 $ pour l'écriture, puis 999 × 8 000 = 7,992M tokens × 0,10 $/M ≈ 0,80 $ en lecture, soit environ 0,82 $/jour. Le calcul suppose que le cache reste actif entre les requêtes et ignore la partie variable du prompt et la sortie. Chez Google, le caching de Gemini 2.5 Pro est à 0,125 $/M et celui de Gemini 2.5 Flash à 0,03 $/M, plus un stockage de 4,50 $ et 1,00 $ par million de tokens et par heure (ai.google.dev/gemini-api/docs/pricing, lu le 24/10/2026, tarif des prompts jusqu'à 200k tokens pour 2.5 Pro). OpenAI : voir ses tarifs officiels sur openai.com/api/pricing.
Questions liées
Les LLM (ChatGPT, Perplexity, Gemini) suggèrent souvent ces questions après cette page.
- Anthropic vs OpenAI : quel prompt caching est le plus économique ?
- Comment structurer son prompt pour maximiser le cache hit rate ?
- Le prompt caching fonctionne-t-il avec un RAG ?
- Quels sont les use cases où le prompt caching ne vaut pas le coup ?
- Comment monitorer son cache hit rate en production ?
Le prompt caching est une fonctionnalité qui permet de réutiliser une partie déjà calculée d’un prompt long sans la repayer au prix plein. Concrètement : si votre prompt contient un long contexte (documents, instructions), vous payez ces tokens une première fois, puis sur les requêtes suivantes ces tokens sont lus dans le cache à un prix réduit (chez Anthropic, 0,1 fois le prix d’entrée pour la plupart des modèles).
En pratique
Cas typique : un agent customer support a un prompt système de 8 000 tokens (FAQ, politiques, ton de marque). Pour 1 000 requêtes/jour, notre calcul à partir du tarif public de Claude Sonnet 5.5 lu le 24/10/2026 sur claude.com/pricing (entrée 2 $/M, écriture 5 min 2,50 $/M, lecture 0,10 $/M) :
Sans cache :
- 1 000 × 8 000 tokens × 2 $/M = 16 $/jour.
Avec cache (Anthropic) :
- 1ère requête : 8 000 tokens × 2,50 $/M (écriture) = 0,02 $.
- 999 requêtes suivantes : 999 × 8 000 tokens × 0,10 $/M ≈ 0,80 $.
- Total ≈ 0,82 $/jour, en supposant que le cache reste actif entre les requêtes, sans compter la partie variable du prompt ni la sortie.
L’économie réelle dépend de la part stable du prompt, de la fréquence des requêtes et du modèle choisi.
Disponibilité 2026
- Anthropic Claude : prompt caching natif, durée de vie de 5 min par défaut ou 1 h en option, marquage explicite via
cache_control(doc, lue le 24/10/2026). - Google Gemini : caching implicite activé par défaut pour Gemini 2.5 et plus récents, caching explicite via l’API generateContent (doc, lue le 24/10/2026).
- OpenAI, Mistral, Bedrock, Azure OpenAI : voir la documentation et les tarifs officiels de chaque fournisseur (par exemple OpenAI).
Bonnes pratiques
- Structurer les prompts : mettre la partie stable (instructions, contexte) AU DÉBUT, la partie variable (question utilisateur) à la FIN. Le cache ne marche que sur les préfixes.
- Identifier les prompts à fort volume : agents conversationnels, RAG avec contexte fixe, traitement batch.
- Mesurer : chez Anthropic, la réponse distingue
cache_read_input_tokensetcache_creation_input_tokens. Surveillez le taux de réussite du cache. - TTL : la durée de 5 minutes est rafraîchie à chaque utilisation du cache ; elle suffit tant que les requêtes sont rapprochées. Pour des requêtes plus espacées, l’option 1 heure existe mais son écriture coûte 2 fois le prix d’entrée.
Caching vs APC (Agentic Plan Caching)
Prompt caching cache des tokens. L’Agentic Plan Caching cache des plans d’exécution d’agents. Si l’agent a déjà résolu une tâche similaire, on rejoue le plan au lieu de raisonner from scratch. Le gain dépend de la répétitivité des tâches de l’agent.
Pour aller plus loin
- Token — définition — l’unité de coût.
- LLM — définition — fonctionnement général.
- Tokenization — définition — comment les tokens sont comptés.