Vous envoyez le meme contexte de 50 000 tokens a chaque requete : un long system prompt, la documentation de votre application, des exemples few-shot, l'historique recent de la conversation. Sur 1 000 requetes par jour, c'est 50 millions de tokens d'entree facturees, soit environ 150 dollars par jour, soit 4 500 dollars par mois rien que pour le contexte que vous envoyez en boucle. Cette situation, courante en 2026, est exactement celle que le prompt caching resout. La technique, generalisee chez tous les providers majeurs, divise typiquement les couts d'entree par 5 a 10 sur les applications qui l'exploitent intelligemment. Pourtant, beaucoup d'equipes la sous-utilisent ou l'utilisent mal. Cet article explique comment fonctionne le prompt caching, comment l'implementer concretement, et quels patterns produisent les meilleurs gains reels.
Le principe technique
Le prompt caching exploite une observation simple : la plupart des appels LLM repetent une grande partie du contexte. Dans un agent conversationnel, le system prompt et le contexte applicatif restent identiques entre les requetes. Seule la question de l'utilisateur varie. Pourtant, sans cache, le modele recalcule tout pour chaque requete.
L'idee est de stocker le calcul interne (les representations vectorielles intermediaires) du contexte stable et de le reutiliser sur les requetes suivantes. Le modele commence le traitement deja "echauffe" sur la partie cachée et se concentre uniquement sur la partie variable.
Techniquement, le cache opere sur des prefixes. Vous declarez qu'une portion du prompt est stable (le prefix) et le provider stocke son etat de calcul. Tant que le prefix reste identique, la prochaine requete benefie du cache. Si le prefix change ne serait-ce que d'un caractere, le cache est invalide et le calcul reprend depuis le debut.
Implementation chez les providers
Les trois providers majeurs implementent le caching avec quelques nuances.
Anthropic Claude propose le caching depuis aout 2024. Le developpeur declare explicitement les blocs a cacher avec le marker cache_control: {"type": "ephemeral"}. Jusqu'a 4 marqueurs sont autorises par requete, ce qui permet un caching multi-niveaux. La duree de vie est de 5 minutes, prolongee a chaque hit. Le tarif des tokens caches est 90 % moins cher que le tarif normal d'entree (0,30 $ par million pour Sonnet vs 3 $).
OpenAI a introduit le caching automatique en octobre 2024. Pas de declaration explicite : le systeme detecte les prefixes communs entre requetes successives et cache automatiquement. Cette transparence est plus simple a utiliser mais offre moins de controle. Le tarif est 50 % moins cher pour les tokens caches.
Google Gemini supporte le caching via une API explicite. Le developpeur cree un cache via cachedContents.create() qui retourne un identifiant. Les requetes suivantes referencent cet identifiant. Le tarif est 75 % moins cher pour les tokens caches. La duree de vie est configurable jusqu'a plusieurs heures.
Ces variations philosophiques (explicite chez Anthropic et Google, implicite chez OpenAI) ont des consequences pratiques. L'explicite donne plus de controle et de predictibilite. L'implicite est plus simple a integrer mais offre moins de garanties.
Les patterns qui maximisent le gain
Quatre patterns d'utilisation produisent les meilleurs gains en 2026.
Le pattern conversationnel. Dans un agent qui conversation longtemps avec un utilisateur, le system prompt et l'historique stable forment un prefix qui grandit progressivement. Cacher ce prefix transforme le cout de chaque tour de conversation. Sur des conversations de 20+ tours, le gain peut atteindre 90 % sur les tokens d'entree.
Le pattern documentaire. Une application RAG envoie systematiquement les memes documents pour les requetes similaires. Cacher le bloc documentaire reduit drastiquement le cout. Pour un assistant qui consulte une documentation de 30 000 tokens partagee entre toutes les requetes, le gain est immediat et massif. Voir notre [guide RAG pour developpeurs](/rag-developpeurs-cursor-claude-code-codebase/) pour les patterns RAG.
Le pattern few-shot. Beaucoup de prompts contiennent des exemples d'entree-sortie pour guider le modele. Ces exemples representent souvent des milliers de tokens. Les cacher elimine leur cout sur toutes les requetes apres la premiere.
Le pattern outils. Les definitions des outils invocables par un agent (function calling) consomment des tokens significatifs. Pour un agent avec 20 outils complexes, les definitions peuvent representer 5 000 a 10 000 tokens. Les cacher est trivial et reduit le cout de chaque appel.
La discipline commune a ces patterns est la stabilite. Tout element variable (timestamps, identifiants utilisateur, donnees temps reel) doit etre place apres les blocs cachés. Une seule modification dans un bloc cache invalide tout ce qui le suit.
Le piege de la mauvaise structure
L'erreur la plus courante en 2026 est le placement aleatoire des blocs cachés. Un developpeur cache le system prompt et la documentation, mais place un timestamp variable au milieu. Le cache ne s'active jamais.
La regle d'or : le contenu mis en cache doit etre place avant tout contenu variable. Concretement, l'ordre du prompt doit etre system prompt -> outils -> documentation stable -> exemples few-shot -> historique conversationnel -> requete utilisateur. Les blocs cachés vont en debut, les blocs variables en fin.
L'autre piege est la sur-fragmentation. Avec Anthropic et ses 4 marqueurs, certains developpeurs cachent chaque petit bloc separement. Cette granularite n'apporte aucun benefice et complique la gestion. Un ou deux marqueurs bien places suffisent generalement.
Le troisieme piege est l'oubli des metadonnees. Le system prompt contient parfois des informations qui semblent stables mais qui changent en realite : date du jour, langue de l'utilisateur, parametres de personnalisation. Si ces elements changent par session ou par utilisateur, ils invalident le cache. La solution est de les sortir du bloc cache et de les passer en parametres separes.
Mesurer les gains reels
Le cout reel d'une application avec et sans caching ne se calcule pas en theorie : il se mesure en production. Plusieurs metriques meritent d'etre instrumentees.
Le taux de hit du cache mesure le pourcentage de tokens d'entree servis depuis le cache. Sur une application bien optimisee, ce taux atteint 80 a 95 %. En dessous de 50 %, il y a generalement un probleme de structuration des prompts.
Le ratio de cout effectif compare le cout factuel avec le cout sans cache (calcule comme si tous les tokens etaient en tarif plein). Cette metrique permet de quantifier l'economie reelle. Sur des applications conversationnelles avec long contexte, ce ratio peut descendre en dessous de 20 % du cout sans cache.
La duree moyenne des prefixes caches indique la stabilite des sessions. Un prefix qui n'est cache que pendant 30 secondes en moyenne (pas de hit avant invalidation) signale un probleme : trop de variabilite, trop de fragmentation, trop de TTL trop courts.
Notre [guide d'observabilite LLM](/observabilite-llm-langsmith-helicone-langfuse/) detaille les outils qui exposent ces metriques nativement.
Cas d'usage : RAG avec caching multi-niveaux
L'architecture RAG est l'un des cas d'usage ou le caching brille particulierement. Un pattern qui fonctionne en 2026 utilise plusieurs niveaux.
Niveau 1 : le system prompt et les definitions d'outils sont caches en permanence. Ces elements sont identiques pour toutes les requetes. Le cache est presque toujours hit.
Niveau 2 : la documentation generale est cachée par session utilisateur. Tant que l'utilisateur explore le meme domaine, le cache est hit. Quand l'utilisateur change de domaine, le cache s'invalide naturellement.
Niveau 3 : les chunks specifiques recuperes par le RAG ne sont generalement pas caches car ils varient a chaque requete. Cette decision est volontaire et accepted comme cout incompressible.
Cette structuration par niveau permet de maximiser le hit rate sur les blocs stables tout en preservant la flexibilite sur les blocs variables. Un assistant documentaire equipe de cette architecture voit ses couts d'entree baisser de 70 a 90 % par rapport a une implementation naive.
Cas d'usage : agent multi-tours
Les agents conversationnels longue durée (Claude Code, Cursor, assistants chat) sont le terrain ideal pour le caching avancé.
Le pattern qui fonctionne : a chaque tour de conversation, le marker de cache est place a la fin de l'historique conversationnel. Le tour suivant beneficie d'un cache qui inclut l'integralité de l'historique précédent. Cette accumulation produit des economies massives sur les longues conversations.
Concretement, sur une conversation de 50 tours avec 100 tokens par tour, sans cache vous facturez 50 fois la somme cumulative (1+2+3+...+50 = 1275 tokens-tours). Avec cache, vous facturez 50 tours de 100 tokens variables seulement, soit 5 000 tokens. La difference est d'un facteur 25 sur cet exemple.
Cette economie se materialise dans la pratique. Un developpeur qui utilise Claude Code 8 heures par jour passe de quelques dizaines de dollars de cout API quotidiens a quelques dollars seulement, pour une qualite identique.
Patterns de codage pour bien cacher
L'integration du caching dans le code applicatif demande discipline. Quelques patterns aident.
La separation systematique du contexte stable et variable. Ne pas concatener un timestamp dans le middle du system prompt. Construire le prompt en sections distinctes : system_prompt = stable_part + variable_part, et placer le marker de cache apres stable_part.
L'utilisation de templates. Plutot que de construire des prompts a la volee, definir des templates qui structurent l'ordre des blocs. Cette discipline force le placement coherent et evite les erreurs de structure.
La validation par tests. Un test automatise qui mesure le taux de hit du cache sur un scenario representatif detecte les regressions. Une modification de prompt qui casse le cache doit etre detecte avant deploiement.
Limites et compromis honnetes
Le prompt caching n'est pas une solution miracle. Plusieurs limites doivent etre comprises.
La duree de vie limitee est la limite la plus visible. Anthropic offre 5 minutes par defaut, prolongees a chaque hit. Si votre application a un trafic faible (moins d'une requete toutes les 5 minutes par utilisateur), le cache ne sert jamais. Pour ces cas, l'achat d'un cache "extended" (1h) chez certains providers ameliore la situation au prix d'une majoration tarifaire.
Le cout du miss merite attention. La premiere requete qui cache un prefix coute 25 % de plus qu'un appel standard chez Anthropic (cost de l'ecriture en cache). Si votre application a beaucoup de premieres requetes et peu de hits, le caching peut couter plus cher qu'il n'economise. La regle simple : il faut au moins 2-3 hits par cache write pour rentabiliser.
La complexite de debogage augmente. Quand un prompt produit des resultats inattendus, le cache complique la reproduction : vous ne savez pas si vous interagissez avec un prompt freshly calcule ou avec un cache pre-calcule. Les outils d'observabilite doivent expliciter cette information pour faciliter le debug.
L'integration dans la stack 2026
Le prompt caching n'est plus une optimisation avancee en 2026 : c'est une discipline de base pour toute application LLM serieuse. Les frameworks d'orchestration (LangChain, LlamaIndex) l'ont integré par defaut. Notre [comparatif LlamaIndex vs LangChain](/llamaindex-vs-langchain-framework-rag/) detaille leur support respectif.
Les developpeurs qui ne l'utilisent pas en 2026 paient typiquement 5 a 10 fois trop cher pour leurs applications LLM. Cette inefficacite n'est plus excusable : la documentation est complete, les exemples sont nombreux, l'integration prend quelques heures.
L'evolution attendue dans les prochains mois est l'automatisation. Les SDK majeurs commencent a appliquer le caching par defaut quand le pattern est detecte, ce qui reduit la friction. L'avantage du controle explicite (Anthropic) reste pour les cas avances ou la performance compte vraiment.
La discipline qui paie
Implementer correctement le prompt caching n'est pas difficile mais demande une discipline initiale. Structurer ses prompts. Mesurer ses hit rates. Iterer sur les patterns qui maximisent les gains. Cette rigueur represente un effort initial de quelques jours qui se rentabilise en quelques semaines pour toute application a usage non trivial.
Les organisations qui industrialisent le caching dans leurs applications LLM accumulent un avantage structurel : elles peuvent se permettre d'utiliser des contextes plus riches, des modeles plus puissants, des patterns plus sophistiques pour le meme budget. Cet avantage compose dans le temps et separe progressivement les applications LLM efficaces des autres.
Pour beaucoup d'equipes, le prompt caching est l'optimisation au plus fort levier qu'elles puissent implementer en 2026. Quelques heures d'investissement pour des economies de plusieurs milliers d'euros par mois. Ce ratio justifie d'en faire une priorite des le debut d'une nouvelle application LLM, et de le retrofit sur les applications existantes qui ne l'utilisent pas encore.
