Prompt caching : comment diviser le coût de vos LLM

Définition : le prompt caching (mise en cache de prompt) permet de réutiliser la partie déjà calculée d'un prompt au lieu de la recalculer à chaque appel. Concrètement, les éléments qui ne changent pas d'une requête à l'autre (instructions système, définitions d'outils, documents, exemples) sont mis en cache après un premier traitement, puis relus à une fraction du prix : souvent 0,1× le coût d'entrée, soit 90 % d'économie sur cette partie. Pour toute entreprise qui utilise des LLM à l'échelle (agents, assistants, RAG), c'est l'un des leviers les plus directs pour faire baisser la facture sans rien changer à la qualité des réponses.

D'abord, comprendre comment on paie un LLM

Avant le cache, il faut comprendre la structure de coût d'un appel LLM. Vous payez au token, et il y a deux compteurs :

• les tokens d'entrée : tout ce que vous envoyez au modèle (instructions système, outils, contexte, historique de conversation, question) ;
• les tokens de sortie : tout ce que le modèle génère en réponse.

Les tokens de sortie sont en général plusieurs fois plus chers que ceux d'entrée. On en déduit, à tort, que le coût se joue surtout sur la sortie. C'est faux dans la plupart des usages d'entreprise. Un agent qui relit un long prompt système, une dizaine de définitions d'outils et plusieurs documents à chaque tour de conversation envoie des dizaines de milliers de tokens d'entrée par appel, pour quelques centaines de tokens de sortie. Le coût se cache alors dans l'entrée, et surtout dans sa répétition.

C'est exactement ce que le prompt caching attaque : la partie de l'entrée que vous renvoyez encore et encore.

API ou abonnement : de quoi parle-t-on ?

Une précision importante avant d'aller plus loin : tout cet article concerne l'usage des LLM via une API, c'est-à-dire en payant au token, quand vous (ou votre prestataire) construisez un produit, un agent ou une automatisation. C'est là, et seulement là, que le prompt caching se pilote et se mesure.

Si vous utilisez un LLM à travers une application (Claude Code, Claude.ai, ChatGPT, Codex et les autres), vous n'avez rien à faire : le cache est géré automatiquement par le fournisseur, de façon invisible. Vous payez un abonnement forfaitaire, pas des tokens, et il n'y a aucune optimisation à votre charge.

Un point que peu de décideurs ont en tête : ces abonnements sont souvent subventionnés. Le prix mensuel est fixe, mais le coût réel de votre usage peut être bien supérieur. Les fournisseurs acceptent de perdre de l'argent sur leurs utilisateurs les plus actifs pour gagner des parts de marché : c'est la logique de la course à l'IA. Concrètement, un abonnement à quelques centaines d'euros par mois peut donner accès à un usage dont la valeur, facturée au tarif API, se compterait en milliers d'euros. Tant que vous restez dans l'application, c'est le fournisseur qui absorbe l'écart.

La bascule arrive dès que vous industrialisez un usage : un agent qui tourne en continu, un assistant intégré à vos outils, un traitement de documents à grande échelle. Là, vous repassez au paiement au token, sans forfait pour amortir les pics. C'est ce cas, le plus stratégique pour une entreprise, que couvre cet article.

Le prompt caching, en clair

Le principe est simple. Lorsqu'un LLM traite un prompt, il calcule une représentation interne de chaque token. Le prompt caching consiste à mémoriser ce calcul pour un préfixe donné, afin de pouvoir le réutiliser tel quel au prochain appel qui commence par le même préfixe.

Deux notions à retenir :

• L'écriture de cache (cache write) : le premier appel calcule le préfixe et le stocke. Il coûte autant, voire un peu plus cher qu'un appel normal.
• La lecture de cache (cache read, ou « cache hit ») : les appels suivants qui partagent ce préfixe le relisent au lieu de le recalculer. C'est là que se fait l'économie, massive.

La condition est stricte : le cache fonctionne par préfixe exact. Le système compare le début de votre prompt à ce qu'il a déjà vu ; dès qu'un caractère diffère, tout ce qui suit ce caractère doit être recalculé. D'où la règle d'or, sur laquelle nous reviendrons : le stable au début, le variable à la fin.

Combien ça coûte vraiment : écriture vs lecture

Toute la rentabilité tient dans le rapport entre le prix d'une écriture et celui d'une lecture. Prenons le cas le plus explicite, celui d'Anthropic (Claude), dont les multiplicateurs sont stables et publics. Ils s'appliquent au prix d'entrée de base du modèle :

Le calcul de rentabilité est immédiat. Avec la durée de 5 minutes, une écriture (1,25×) suivie d'une seule relecture (0,1×) coûte 1,35×, contre 2× pour deux appels sans cache. Le cache est rentable dès la première réutilisation. Avec la durée d'une heure (écriture 2×), il faut deux relectures pour être gagnant, mais le cache reste « chaud » bien plus longtemps, ce qui est précieux pour des sessions étalées dans le temps.

Pour rendre ces multiplicateurs concrets, voici la grille appliquée aux modèles Claude (prix par million de tokens, à titre indicatif, d'après la documentation Anthropic) :

La dernière colonne est la plus parlante : sur Sonnet, relire un préfixe coûte 0,30 $ le million de tokens au lieu de 3 $. C'est ce facteur 10 qui transforme l'économie d'un cas d'usage répétitif.

Mettons des chiffres concrets, sur Sonnet 4.6 (entrée à 3 $/M, lecture à 0,30 $/M). Un agent de support s'appuie sur un préfixe stable de 30 000 tokens (prompt système détaillé, définitions d'outils, base de connaissances) et traite 2 000 conversations par jour. Sans cache, c'est 60 millions de tokens d'entrée par jour, soit 180 $ par jour rien que pour ce préfixe. Avec le cache, ce préfixe n'est écrit que quelques fois par jour (à 3,75 $/M), puis relu à 0,30 $/M le reste du temps : la facture tombe autour de 20 $ par jour. Sur l'année, on passe de l'ordre de 65 000 $ à environ 7 000 $ sur ce seul poste. C'est souvent la différence entre un cas d'usage rentable et un cas d'usage qu'on abandonne.

Chaque fournisseur a ses règles

Les trois grands écosystèmes que nous utilisons (Anthropic, OpenAI et l'agrégateur OpenRouter) ne traitent pas le cache de la même manière. La différence majeure : chez certains il est automatique, chez d'autres il faut le déclencher explicitement.

Quelques points à connaître, vérifiés dans les documentations officielles :

• Anthropic demande de poser des points de cache (cache_control) dans la requête, jusqu'à quatre, et impose un minimum d'environ 1 024 à 4 096 tokens selon le modèle : en dessous, rien n'est mis en cache. C'est l'approche la plus fine, qui permet même de combiner des durées de 5 minutes et d'1 heure dans un même prompt. Bon réflexe : la durée du cache se réinitialise gratuitement à chaque lecture, donc un cache souvent sollicité reste vivant.
• OpenAI met en cache automatiquement, sans frais d'écriture, dès 1 024 tokens (par paliers de 128). Vous ne payez jamais l'écriture, seulement la lecture, moins chère. Le paramètre optionnel prompt_cache_key aide à augmenter le taux de réussite du cache (un client cité passe de 60 à 87 % dans la documentation OpenAI).
• OpenRouter sert d'aiguilleur entre des dizaines de fournisseurs. Il applique les règles de chacun (cache automatique pour OpenAI ou DeepSeek, points de cache explicites pour Anthropic) et utilise un routage collant : après un appel mis en cache, vos requêtes suivantes sont renvoyées vers le même fournisseur pour garder le cache chaud, et uniquement quand la lecture est moins chère que le prix normal (voir les bonnes pratiques OpenRouter).

On voit la philosophie de chacun : OpenAI vise la simplicité (zéro configuration, écriture gratuite, mais lecture un peu moins remisée selon le modèle), là où Anthropic vise le contrôle (points de cache explicites, durées mixables, lecture à 0,1×). Le schéma ci-dessous, tiré de la documentation Anthropic, illustre cette granularité : on peut placer des blocs en cache 1 heure avant des blocs 5 minutes, chaque point de cache étant lu ou réécrit indépendamment selon ce qui a changé.

Le tableau ci-dessus donne des ordres de grandeur, mais les prix exacts évoluent : vérifiez toujours la grille tarifaire à jour du fournisseur avant de chiffrer un projet.

Là où le cache fait la vraie différence

Le prompt caching n'a d'intérêt que si un même préfixe est réutilisé dans la fenêtre de vie du cache. Une requête unique et isolée n'en profite pas. En revanche, il est décisif pour les usages les plus courants en entreprise :

Le point commun : un gros bloc stable réutilisé souvent. Plus ce bloc est volumineux et plus il est répété, plus le cache rapporte. Pour les agents connectés à vos systèmes via le MCP, où les définitions d'outils gonflent vite le prompt, c'est presque indispensable. Pour situer ces usages sur vos propres scénarios, partez de nos cas d'usage de l'IA en entreprise.

Les pièges qui annulent vos économies

La plupart des déceptions viennent d'erreurs simples qui font manquer le cache en silence : aucune erreur n'est levée, mais vous payez le prix plein. Les plus fréquentes :

• Glisser une donnée variable au début du prompt : la date du jour, l'heure, un nom d'utilisateur ou un identifiant de session dans le prompt système. Le préfixe change à chaque appel, donc le cache ne tombe jamais. Mettez ces éléments à la fin.
• Un JSON non trié : si l'ordre des clés de vos définitions d'outils varie d'un appel à l'autre, le préfixe diffère. Sérialisez de façon déterministe (clés triées).
• Changer le jeu d'outils ou de modèle : modifier la liste des outils, ou basculer de modèle, invalide le cache. Les caches sont aussi cloisonnés par modèle et par organisation.
• Un préfixe trop court : sous le minimum (souvent 1 024 tokens), rien n'est mis en cache, même si vous le demandez.

Diagnostiquer un cache qui ne prend pas

Première vérification, gratuite : inspectez l'objet usage de la réponse. Anthropic y expose cache_read_input_tokens (lu, payé ~0,1×) et cache_creation_input_tokens (écrit) ; OpenAI et OpenRouter exposent cached_tokens dans prompt_tokens_details. Si ces compteurs restent à zéro sur des appels au préfixe identique, un invalidateur silencieux est à l'œuvre.

Le souci, c'est que ces compteurs vous disent que le cache n'a pas pris, jamais pourquoi. Anthropic a justement publié un outil de diagnostic de cache (en beta) qui répond à cette question. En lui passant l'identifiant de la réponse précédente, l'API compare les deux requêtes et pointe le premier endroit où le préfixe a divergé, sous la forme d'un champ cache_miss_reason :

C'est exactement ce qui transforme un « le cache ne marche pas » flou en une cause précise et corrigeable. Pour une entreprise, c'est la différence entre payer le prix plein sans le savoir pendant des semaines et repérer la fuite en une requête.

Au-delà du coût : latence et confidentialité

Réduire le coût n'est pas le seul gain. Relire un préfixe au lieu de le recalculer accélère aussi la réponse : OpenAI annonce jusqu'à 80 % de latence en moins sur les prompts longs mis en cache. Pour un assistant en contact avec des utilisateurs, c'est un effet directement perceptible sur l'expérience.

Côté confidentialité, le cache « en mémoire » d'OpenAI n'écrit rien sur disque et reste compatible avec un mode rétention zéro : il n'y a pas d'arbitrage entre cache et confidentialité des données. Si ce sujet vous concerne, nous le détaillons dans notre article sur le ZDR (Zero Data Retention). À noter aussi : les tokens mis en cache comptent toujours dans vos limites de débit (TPM) ; le cache fait économiser de l'argent et du temps, pas du quota.

Comment nous aidons

Optimiser le coût d'un système LLM, ce n'est pas un réglage isolé : c'est une démarche. Structurer les prompts pour rendre le préfixe cacheable, choisir le bon fournisseur et la bonne durée de cache, instrumenter les compteurs pour vérifier le taux de réussite, et arbitrer entre modèles selon le cas d'usage. C'est précisément ce que nous faisons chez SprintOS, selon une méthode structurée : déployer des systèmes IA non seulement performants, mais rentables et mesurés sur vos volumes réels. Pour en parler, faites le point avec un expert ou testez votre cas d'usage avec SprintAI.

Questions fréquentes

C'est quoi le prompt caching ?

Le prompt caching (mise en cache de prompt) permet de réutiliser la partie déjà calculée d'un prompt (instructions système, outils, documents) au lieu de la recalculer à chaque appel. La lecture du cache coûte beaucoup moins cher que le traitement initial, souvent 0,1× le prix d'entrée chez Anthropic, soit 90 % d'économie sur la partie réutilisée.

Combien le prompt caching fait-il économiser ?

Sur la partie répétée d'un prompt, la lecture en cache coûte 0,1× le prix d'entrée chez Anthropic et DeepSeek (90 % d'économie), 0,25× à 0,5× chez OpenAI selon le modèle (jusqu'à 90 % sur les modèles GPT-5). L'économie réelle dépend de la part de votre prompt qui est stable et du nombre de fois où elle est réutilisée.

Quelle différence entre tokens d'entrée et de sortie ?

Un LLM facture les tokens d'entrée (ce que vous envoyez : instructions, contexte, question) et les tokens de sortie (ce qu'il génère). Les tokens de sortie sont en général plusieurs fois plus chers. Le prompt caching agit uniquement sur les tokens d'entrée, là où se cache souvent l'essentiel du coût des agents et du RAG.

Le prompt caching est-il automatique ?

Cela dépend du fournisseur. Chez OpenAI, DeepSeek, Grok ou Gemini 2.5, il est automatique : aucune configuration. Chez Anthropic, il faut le déclencher en plaçant des points de cache (cache_control) dans la requête. OpenRouter unifie les deux approches et garde votre cache « chaud » via un routage cohérent.

Combien de temps un prompt reste-t-il en cache ?

Chez Anthropic, 5 minutes par défaut (option 1 heure), et le minuteur se réinitialise à chaque réutilisation. Chez OpenAI, le cache vit de 5 à 10 minutes d'inactivité, jusqu'à 1 heure au maximum, avec une option de rétention étendue. Le cache n'est donc utile que si le même préfixe est réutilisé dans cette fenêtre.

Quels pièges annulent les économies du prompt caching ?

Le principal est de glisser une donnée variable au début du prompt : date du jour, nom d'utilisateur, identifiant de session ou JSON non trié. Le moindre changement dans le préfixe invalide tout le cache en aval. La règle est de mettre tout ce qui est stable au début et tout ce qui change à la fin.

Comment vérifier que le prompt caching fonctionne ?

Inspectez l'objet usage de la réponse : cache_read_input_tokens chez Anthropic, cached_tokens (dans prompt_tokens_details) chez OpenAI. S'ils restent à zéro sur des préfixes identiques, le cache ne prend pas. Anthropic propose en plus un outil de diagnostic de cache (en beta) qui compare deux requêtes et indique précisément ce qui a divergé : le modèle, le prompt système, les outils ou les messages.

Le prompt caching concerne-t-il ChatGPT, Claude.ai ou Claude Code ?

Non, pas directement. Ces applications gèrent le cache automatiquement et vous payez un abonnement forfaitaire, pas des tokens : il n'y a rien à optimiser de votre côté. Le prompt caching se pilote quand vous utilisez un LLM via son API, au token, pour construire un produit, un agent ou une automatisation. Ces abonnements grand public sont d'ailleurs souvent subventionnés : le coût réel de l'usage peut dépasser largement le prix payé.

En résumé

Le prompt caching est l'un des rares leviers qui réduit le coût d'un LLM sans toucher à la qualité des réponses : on réutilise la partie stable du prompt au lieu de la repayer à chaque appel, pour 50 à 90 % d'économie sur cette partie selon le fournisseur. Il se mérite : un prompt bien structuré (le stable au début, le variable à la fin), le bon fournisseur, la bonne durée, et des compteurs qu'on surveille. Pour les usages à fort volume (agents, RAG, assistants), c'est la différence entre une IA qui impressionne en démonstration et une IA rentable en production. C'est ce travail d'ingénierie du coût que nous menons avec les PME et ETI françaises.