Le prompt caching peut réduire le coût des entrées répétées à une fraction du prix, mais Claude, OpenAI et Gemini le gèrent chacun différemment. Comparez points d’arrêt, durées de vie, frais d’écriture et tailles minimales, avec un exemple chiffré et les erreurs qui empêchent les succès de cache.
Chaque requête envoyée à un grand modèle de langage (LLM) commence par le même rituel coûteux. Le prompt système, les définitions d’outils, la documentation collée et les exemples few-shot sont tous relus, token par token, au plein tarif, alors que rien n’a changé depuis l’appel précédent. Le prompt caching met fin à ce gaspillage. Le fournisseur stocke la forme traitée de votre préfixe répété et facture une fraction du prix d’entrée normal lorsque la requête suivante le réutilise. Pensez à la mise en place d’un restaurant : le cuisinier hache les échalotes une fois avant le service, et chaque commande est ensuite assemblée à partir de contenants déjà prêts.
Claude, OpenAI et Gemini proposent tous cette idée, mais ils divergent sur presque tout le reste : qui décide de ce qui est mis en cache, combien de temps cela reste disponible, ce que coûte l’écriture et la taille qu’un prompt doit atteindre pour être éligible. Cet article met les trois en parallèle à partir des chiffres de leur documentation actuelle, afin de vous aider à choisir une configuration et à éviter les erreurs qui désactivent discrètement le cache.
Lorsqu’un modèle lit votre prompt, il effectue un travail réel pour chaque token avant de pouvoir écrire le premier mot de la réponse. Ce travail est identique à chaque fois que le début du prompt est identique. Le prompt caching permet au fournisseur de conserver le résultat de ce travail pendant une courte fenêtre et de le réutiliser : la partie répétée n’est traitée qu’une fois, puis facturée à prix réduit.
Imaginez un meuble à fiches. Le fournisseur range le préfixe traité sous une empreinte de son contenu exact. La requête suivante qui produit la même empreinte tire le tiroir au lieu de reconstruire son contenu depuis zéro.
Le cache fonctionne depuis le premier token. La partie mise en cache doit correspondre exactement, et sans interruption, au début de votre requête, et la première différence met fin à la correspondance. Tout ce qui suit ce point est traité et facturé au tarif habituel.
Cette seule règle guide tous les conseils des fournisseurs. Placez en haut le contenu qui ne change jamais, et repoussez tout ce qui change (la question de l’utilisateur, la date du jour, les extraits récupérés) en bas. Une bonne section haute contient généralement :
💡 Vérification rapide : si vous imprimiez deux requêtes et surligniez ce qu’elles ont en commun, la partie surlignée doit former un bloc continu qui commence au tout premier caractère. Un paragraphe commun au milieu ne compte pas.
Trois éléments s’améliorent lorsque le préfixe est réutilisé :
Les boucles d’agents, les questions-réponses sur des documents, les longs historiques de discussion et les classifieurs dotés d’une grille d’évaluation volumineuse en tirent le plus grand bénéfice. Un prompt qui change à chaque fois n’en retire rien.
Claude vous offre le contrôle le plus direct des trois. Vous décidez où se termine le préfixe pouvant être mis en cache, et vous décidez combien de temps il doit rester disponible.
Vous marquez un bloc de contenu avec cache_control de type ephemeral, et tout ce qui va du début de la requête jusqu’à ce bloc inclus devient le préfixe mis en cache. L’ordre est fixe : d’abord les outils, puis le système, puis les messages. Vous pouvez placer jusqu’à quatre points d’arrêt, et l’API renvoie une erreur 400 si vous en placez un cinquième au niveau des blocs.
Il existe aussi un mode automatique. Ajoutez un seul champ cache_control au niveau racine de la requête, et le système applique le point d’arrêt au dernier bloc pouvant être mis en cache, puis le déplace à mesure que la conversation s’allonge.
{
"model": "claude-opus-5-5",
"cache_control": { "type": "ephemeral" },
"system": "Long, stable instructions go here...",
"messages": [
{ "role": "user", "content": "Today's question" }
]
}
Un détail piège les longues sessions d’agents. Lorsque le système cherche une entrée correspondante antérieure, il ne vérifie que 20 positions au maximum en arrière à partir de chaque point d’arrêt. Si un tour ajoute de nombreux blocs, l’entrée précédente peut se trouver hors de cette fenêtre. La solution consiste alors à placer un second point d’arrêt plus tôt dans le prompt.
La durée de vie par défaut est de 5 minutes, et chaque succès réinitialise le minuteur sans frais. Si votre trafic arrive par rafales espacées, vous pouvez opter pour une heure avec "ttl": "1h", moyennant un tarif d’écriture plus élevé.
| Élément | Coefficient | Exemple Opus 5.5 (par million de tokens) |
|---|---|---|
| Entrée de base | 1x | $4,00 |
| Écriture en cache de 5 minutes | 1,25x | $5,00 |
| Écriture en cache d’une heure | 2x | $8,00 |
| Lecture du cache | 0,05x sur ce modèle | $0,20 |
La plupart des modèles Claude lisent depuis le cache à 0,1x du prix d’entrée de base. Les niveaux Opus 5.5 et Sonnet 5.5 lisent à 0,05x, et certains niveaux plus récents descendent encore plus bas.
Le seuil dépend du modèle, et il a beaucoup changé d’une génération à l’autre :
💡 Échec silencieux : un prompt plus court que le minimum est traité sans mise en cache, et aucune erreur n’est renvoyée. Le seul signe est un champ de cache qui reste à zéro.
L’histoire d’OpenAI se déroule en deux temps. Pendant longtemps, la mise en cache a été entièrement automatique. Avec GPT-5.6, elle a gagné des points d’arrêt et des frais d’écriture, ce qui la rapproche nettement de Claude.
Sur GPT-5.5 et GPT-5.5 Pro, le système place des points d’arrêt implicites à intervalles de 2 048 tokens, et la rétention se règle avec prompt_cache_retention, limitée à 24h. Les modèles antérieurs comme GPT 5.4, GPT 5.1, GPT 5 et GPT 4.1 prennent en charge à la fois la rétention in_memory, qui dure en général environ 5 à 10 minutes d’inactivité, et l’option étendue 24h.
Le tarif des tokens en cache dépend du modèle, mais il n’y a aucun frais d’écriture supplémentaire sur ces versions. Essayer la mise en cache ne coûte donc rien. Au pire, vous payez le tarif normal.
GPT-5.6 et les versions ultérieures ont modifié les règles, et la nouvelle configuration se rapproche de celle de Claude :
prompt_cache_options.mode réglé sur implicit, un point d’arrêt se place à la fin du dernier message éligible. Avec explicit, vous marquez vous-même chaque point d’arrêt à l’aide de prompt_cache_breakpoint.prompt_cache_options.ttl n’accepte qu’une valeur, 30m, qui est aussi la valeur par défaut.{
"model": "YOUR_GPT_5_6_MODEL",
"prompt_cache_options": { "mode": "explicit" },
"input": [
{
"role": "developer",
"content": [{
"type": "input_text",
"text": "Stable rubric and instructions...",
"prompt_cache_breakpoint": { "mode": "explicit" }
}]
},
{ "role": "user", "content": "The changing part of the request" }
]
}
Les trois niveaux actuels de la plateforme sont GPT 5.6 Terra, GPT 5.6 Luna et GPT 5.6 Sol. Consultez le tableau des tarifs en vigueur pour chaque niveau avant de budgétiser, car OpenAI annonce pour certains niveaux des tarifs de lecture en cache plus avantageux.
Google propose deux mécanismes distincts, qui se facturent différemment. L’un fonctionne de lui-même. L’autre est un objet que vous créez et gérez.
Le cache implicite est activé par défaut pour tous les modèles Gemini 2.5 et plus récents. Vous ne modifiez aucun code. Si une requête partage un préfixe commun avec une requête antérieure, elle peut bénéficier d’un succès de cache, et les économies sont répercutées automatiquement.
Les minimums sont de 2 048 tokens pour Gemini 2.5 Flash et 2.5 Pro, et de 4 096 tokens pour Gemini 3.5 Flash, ses frères Flash plus récents et Gemini 3.1 Pro. Les conseils de Google correspondent exactement à la règle du préfixe : placez le contenu volumineux et commun au début, et envoyez les requêtes au préfixe similaire rapprochées dans le temps.
Aucune garantie n’existe toutefois pour une requête donnée. Le cache implicite est opportuniste, et c’est pourquoi certaines équipes passent à la version explicite.
Avec la mise en cache explicite, vous créez un objet de cache, puis vous dirigez les requêtes vers lui.
cache = client.caches.create(
model="gemini-2.5-flash",
config=types.CreateCachedContentConfig(
system_instruction="Long, stable instructions...",
contents=[big_document],
ttl="3600s",
),
)
response = client.models.generate_content(
model="gemini-2.5-flash",
contents="Today's question",
config=types.GenerateContentConfig(cached_content=cache.name),
)
La durée de vie par défaut est d’une heure, et vous pouvez la régler avec ttl, par exemple "300s". Vous pouvez modifier ensuite le ttl ou le expire_time, mais rien d’autre dans le cache. La facturation comporte trois volets : les tokens réutilisés à tarif réduit, le stockage par token-heure tant que le cache existe, et le tarif normal pour tout ce qui se trouve hors du cache. Les caches explicites ont un minimum de 2 048 tokens sur les modèles 2.5 et de 4 096 sur la gamme 3.x. L’API Interactions ne prend en charge que le type implicite.
Google a publié des remises de réutilisation comprises entre 75 % et 90 % selon la génération du modèle. Vérifiez donc le chiffre de votre modèle sur la page tarifaire en vigueur.
| Caractéristique | Claude | OpenAI (GPT-5.6 et versions ultérieures) | Gemini |
|---|---|---|---|
| Mode d’activation | cache_control points d’arrêt, ou un champ unique au niveau racine pour le mode automatique | Implicite par défaut, ou points d’arrêt explicites | Implicite par défaut, plus des objets de cache explicites |
| Durée de vie | 5 minutes, ou 1 heure sur demande | 30 minutes | L’implicite n’est pas garanti. L’explicite dure 1 heure par défaut |
| Coût d’écriture | 1,25x pour 5 minutes, 2x pour 1 heure | 1,25x | Tarif d’entrée normal pour l’implicite. Stockage par token-heure pour l’explicite |
| Coût de lecture | 0,1x sur la plupart des modèles, 0,05x sur Opus 5.5 et Sonnet 5.5 | 0,1x | Tarif réduit, défini par modèle |
| Préfixe minimum | 512 à 4 096 tokens selon le modèle | 1 024 tokens visibles | 2 048 en 2.5, 4 096 sur les modèles plus récents |
| Contrôle | Jusqu’à 4 points d’arrêt | Mode implicite ou explicite | Objet de cache avec un TTL que vous définissez |
Utilisez les chiffres de Claude pour vérifier le seuil de rentabilité. Une seule écriture de 5 minutes à 1,25x, plus une lecture à 0,1x, coûte 1,35x. Deux appels sans cache coûtent 2x. Donc une seule réutilisation suffit déjà à rentabiliser l’écriture. L’écriture avec l’option de 1 heure coûte 2x : il faut donc deux lectures avant qu’elle ne devienne plus avantageuse que l’absence de cache.
Passons maintenant à plus grande échelle. Prenez un prompt système de 20 000 tokens envoyé 1 000 fois par jour, au tarif de base d’Opus 5.5 de $4 par million de tokens :
Les messages utilisateur et les sorties du modèle sont facturés de la même manière dans les deux cas, donc ce calcul isole l’économie sur le préfixe. Sur les anciens modèles d’OpenAI sans frais d’écriture, le calcul est encore plus simple. Sur Gemini, la voie explicite ajoute des heures de stockage à la facture : un cache qui reste inactif une grande partie de la journée peut donc coûter plus qu’il n’économise.
La plupart des configurations de cache qui échouent ne sont pas des problèmes du fournisseur. Elles viennent de trois habitudes.
Le bug classique est une ligne du type « Heure actuelle : 14:32:07 » près du début du prompt système. Le préfixe diffère à chaque requête, il ne peut donc jamais correspondre. Anthropic décrit le même piège : un point d’arrêt placé sur un bloc contenant un horodatage et un message utilisateur. Le cache ne se déclenche jamais, car aucune entrée n’a été écrite à une position antérieure. La solution consiste à déplacer le point d’arrêt sur le dernier bloc qui reste identique d’une requête à l’autre, et à placer la ligne qui change après lui.
L’ordre fait partie de l’empreinte. Mélanger les définitions d’outils, trier différemment une liste de documents récupérés ou sérialiser du JSON avec un nouvel ordre de champs produit un nouveau préfixe. Avec Claude, une modification à un niveau invalide ce niveau et tous ceux qui suivent : si vous modifiez une définition d’outil, les caches des outils, du système et des messages sont tous invalidés. Ajouter ou retirer des images invalide le cache des messages. Gardez les listes d’outils dans un ordre fixe et sérialisez-les toujours de la même manière.
Une durée de vie de 5 minutes n’aide pas une tâche qui envoie une requête toutes les dix minutes. Chaque appel paie le prix de l’écriture et ne profite jamais d’une lecture. Dans ce cas, vous disposez de trois options : passer à la durée de vie de 1 heure sur Claude, envoyer une requête de maintien en activité peu coûteuse avant que le minuteur n’expire, ou regrouper les tâches pour que les requêtes arrivent rapprochées.
💡 Règle empirique : adaptez la durée de vie du cache à l’écart entre les requêtes, et non à la longueur de la session.
Ne faites pas confiance à une configuration tant que la réponse ne confirme pas qu’elle fonctionne. Chaque fournisseur signale l’activité du cache dans le bloc d’usage de la réponse.
| Fournisseur | Où regarder |
|---|---|
| Claude | usage.cache_creation_input_tokens et usage.cache_read_input_tokens |
| OpenAI | usage.input_tokens_details.cached_tokens et, sur GPT-5.6 et versions ultérieures, cache_write_tokens |
| Gemini | Le nombre de tokens en cache dans usage_metadata |
Sur Claude, le champ input_tokens ne compte que les tokens situés après le dernier point d’arrêt, et non l’ensemble du prompt. Le total réel est cache_read_input_tokens + cache_creation_input_tokens + input_tokens. Calculez donc votre taux de succès à partir de cette somme.
Journalisez trois nombres par requête : les tokens du cache lus, les tokens écrits et les tokens facturés au plein tarif. Surveillez ensuite deux signaux. Un nombre de lectures qui reste à zéro après la deuxième requête identique signifie que le préfixe change ou se situe sous le minimum. Un nombre d’écritures qui grimpe à chaque requête signifie que la durée de vie expire avant l’arrivée de l’appel suivant.
Les paramètres de cache se gèrent dans l’API propre à chaque fournisseur, donc c’est dans votre code que vous les ajustez. Picasso IA est utile une étape plus tôt, lorsque vous décidez ce que doit dire le préfixe stable :
Un prompt figé est aussi un prompt stable, ce qui est exactement ce que recherche un cache.
Les photos de cet article ont toutes été réalisées avec P Image, chacune à partir d’un seul prompt descriptif portant sur l’objectif, la lumière et la texture. Vous pouvez faire de même en quelques minutes. Essayez Seedream 4.5 pour des détails 4K nets, Flux 2 Pro pour un réalisme photographique, Imagen 4 pour les scènes naturelles, ou Nano Banana Pro pour des résultats soignés.
Rédigez un prompt qui nomme le sujet, la lumière et l’objectif, lancez-le, puis modifiez un seul détail et relancez-le. La façon la plus rapide de prendre la mesure d’un modèle est de commencer à expérimenter avec vos propres images sur Picasso IA dès aujourd’hui.
Choisissez votre langue
