Le prompt caching chez OpenAI, Claude et Gemini

Si vos prompts partagent un préfixe long et stable — une grande instruction système, un catalogue d'outils, un document sur lequel vous posez sans cesse des questions — le prompt caching permet au fournisseur d'éviter de retraiter ce préfixe et de le facturer à un tarif fortement réduit. OpenAI, Anthropic et Google offrent tous cette fonctionnalité, et le gain est le même partout : un coût d'entrée plus bas et un temps jusqu'au premier jeton plus rapide sur la portion mise en cache. Ce qui diffère, c'est qui décide de ce qui est mis en cache. OpenAI met en cache automatiquement par préfixe. Anthropic vous fait marquer les points de cache explicitement. Gemini met en cache implicitement par défaut et expose aussi un objet de cache explicite. Cet article cartographie les trois surfaces de contrôle, les champs d'usage que chacune renvoie, et comment structurer un prompt pour que le cache touche vraiment.

Dernière vérification : 2026-07-15. Les minimums par modèle, les TTL et les multiplicateurs de tarification changent ; confirmez auprès des pages de tarification et de caching liées de chaque fournisseur avant de vous fier à un chiffre précis.

La seule règle que les trois partagent : mettre en cache le préfixe, faire varier le suffixe

Chaque fournisseur met en cache un préfixe du prompt et fait la correspondance sur les octets exacts. La conséquence pratique est identique d'un fournisseur à l'autre : placez en premier les parties qui restent identiques, et en dernier les parties qui changent. Un prompt système, des exemples few-shot, des définitions d'outils et un grand document de référence appartiennent au sommet ; la question actuelle de l'utilisateur appartient au bas. Réordonnez-les et vous déplacez la frontière entre « cachable » et « non », et une seule modification précoce — même un horodatage injecté dans le message système — invalide tout ce qui suit. C'est le changement au plus fort levier que vous puissiez faire, et il est gratuit.

Le caching a aussi une taille minimale. Les prompts courts ne valent pas la peine d'être mis en cache et les fournisseurs ne le font tout simplement pas, si bien que la réduction n'apparaît qu'une fois que le préfixe mis en cache franchit un seuil qui varie selon le modèle. En dessous, vous payez le tarif d'entrée normal et voyez zéro jeton mis en cache.

OpenAI : automatique, basé sur le préfixe, orienté par prompt_cache_key

Le caching d'OpenAI est automatique — vous n'avez pas à vous inscrire. Le caching est activé automatiquement pour les prompts de 1024 jetons ou plus, et la correspondance fonctionne à partir du préfixe du prompt. Lorsqu'une requête réutilise un préfixe déjà mis en cache, les jetons réutilisés sont facturés au tarif réduit d'entrée mise en cache et apparaissent dans l'objet d'usage comme cached_tokens : sous usage.prompt_tokens_details sur Chat Completions, et sous usage.input_tokens_details sur l'API Responses. Les requêtes en dessous du seuil signalent cached_tokens à zéro.

Vous ne contrôlez pas le caching directement, mais vous pouvez influencer le routage avec prompt_cache_key. Des requêtes qui partagent un long préfixe commun mais proviennent d'utilisateurs ou de chemins différents peuvent atterrir sur des backends de cache différents ; définir le même prompt_cache_key sur des requêtes liées est combiné avec le hachage du préfixe pour les router ensemble et améliorer les taux de correspondance. Sur les modèles plus récents, cette clé est ce qui rend la correspondance fiable, et OpenAI suggère de garder un trafic modeste par clé plutôt que d'y déverser des milliers de requêtes par minute à travers une seule clé.

La rétention est contrôlable. Les modèles plus récents acceptent prompt_cache_options avec un ttl (30 minutes est la durée de vie minimale prise en charge et la valeur par défaut), tandis que les modèles antérieurs utilisent prompt_cache_retention, dont les entrées en mémoire restent généralement actives quelques minutes d'inactivité et peuvent être prolongées jusqu'à 24 heures. Sur les modèles les plus récents, les jetons écrits en cache sont signalés séparément comme cache_write_tokens et facturés à 1,25× le tarif d'entrée non mise en cache ; les modèles plus anciens n'ajoutent pas de frais d'écriture. Une passerelle transmet prompt_cache_key et prompt_cache_retention directement à l'amont, si bien que vous gardez les mêmes réglages derrière une seule URL de base.

Anthropic : un marqueur cache_control, automatique ou explicite

Anthropic ne met en cache que ce que couvre un marqueur cache_control, mais vous n'avez pas à placer chaque point de rupture à la main. Deux modes existent. Le caching automatique ajoute un unique champ cache_control au niveau supérieur de la requête ; le système place le point de rupture sur le dernier bloc cachable et le fait avancer à mesure que la conversation s'allonge, ce qui en fait le choix le plus simple pour les conversations à plusieurs tours. Les points de rupture explicites placent cache_control directement sur des blocs de contenu individuels afin de contrôler précisément ce qui est mis en cache. L'exemple ci-dessous utilise un point de rupture explicite sur un guide stable :

import anthropic
client = anthropic.Anthropic(base_url="https://your-gateway.example.com", api_key="AVE_GATEWAY_API_KEY")

client.messages.create(
    model="claude-opus-4-8",
    max_tokens=1024,
    system=[
        {"type": "text", "text": "You are a contract analyst."},
        {
            "type": "text",
            "text": LONG_STATIC_PLAYBOOK,        # the expensive, stable prefix
            "cache_control": {"type": "ephemeral"},
        },
    ],
    messages=[{"role": "user", "content": "Summarize the indemnity clause."}],
)

Vous pouvez définir jusqu'à 4 points de rupture de cache — le marqueur automatique de niveau supérieur en consomme un — afin de mettre en cache des sections qui changent à des fréquences différentes : un prompt système rarement modifié derrière un point, un document propre à la session derrière un autre. La longueur minimale cachable dépend du modèle ; beaucoup de modèles actuels, dont Claude Opus 4.8 et Sonnet 5, commencent à 1 024 jetons, tandis que certains niveaux en exigent 2 048 ou 4 096. Un prompt plus court que le minimum est traité silencieusement sans caching : aucune erreur, simplement aucune réduction.

La comptabilité d'usage est explicite et mérite une lecture attentive. Les réponses renvoient trois comptes séparés : cache_creation_input_tokens (jetons écrits dans une nouvelle entrée de cache), cache_read_input_tokens (jetons servis depuis le cache) et input_tokens (tout ce qui suit le dernier point de rupture). L'entrée totale est la somme des trois, et si les deux comptes de cache sont à zéro, rien n'a été mis en cache. La durée de vie par défaut du cache est de 5 minutes, rafraîchie gratuitement chaque fois que l'entrée est utilisée, si bien qu'un cache activement touché reste effectivement chaud ; une option "ttl": "1h" la prolonge à un coût d'écriture plus élevé. Les multiplicateurs de tarification sont publics : une écriture de cache de 5 minutes coûte 1,25× l'entrée de base, une écriture d'une heure coûte 2×, et chaque lecture de cache coûte 0,1× l'entrée de base. Cette réduction de 10× à la lecture est la raison de s'en donner la peine.

Gemini : implicite par défaut, explicite quand vous avez besoin de contrôle

Le défaut de Google est celui qui demande le moins de travail : le caching implicite est activé automatiquement pour Gemini 2.5 et les modèles plus récents, et les économies de coût sont répercutées automatiquement lorsqu'une requête touche le cache. Vous structurez le prompt avec le contenu commun en premier, envoyez des requêtes à préfixe similaire rapprochées dans le temps, et lisez le compte de jetons mis en cache dans les métadonnées d'usage. Des minimums s'appliquent ici aussi — les niveaux Flash et Pro actuels commencent à mettre en cache autour de quelques milliers de jetons, et la nouvelle génération exige un préfixe plus grand.

Lorsque vous avez besoin d'un caching garanti et d'un contrôle explicite de la durée de vie, l'API generateContent de Gemini offre un caching de contexte explicite via un objet CachedContent : vous téléversez le contenu une fois, recevez une poignée (handle), définissez un TTL et référencez la poignée lors des appels suivants. Le caching explicite garantit la réduction pour un contenu que vous savez réutiliser (un long PDF, une vidéo, un jeu d'instructions fixe) plutôt que de le laisser à l'heuristique implicite. Le compte de jetons mis en cache apparaît dans usageMetadata (comme cachedContentTokenCount sur generateContent), qu'une passerelle normalise dans le même champ de jetons mis en cache qu'elle signale pour les autres fournisseurs.

Ce qu'une passerelle peut et ne peut pas normaliser

Derrière un seul point de terminaison compatible OpenAI, une passerelle transmet les contrôles de caching que chaque fournisseur comprend et replie les champs d'usage disparates dans une forme comptable unique — cached_tokens pour les lectures, plus les comptes de création de cache — afin qu'une requête mise en cache apparaisse de la même façon dans vos journaux d'usage quel que soit l'amont. La passerelle applique aussi ses propres ratios de facturation configurables : un ratio de lecture qui facture l'entrée mise en cache sous le tarif normal, et un ratio de création de cache, fixé par défaut à 1,25×, pour les écritures, publiés par modèle sur la page publique de tarification.

Soyez explicite sur les limites, cependant. Les trois fournisseurs n'exposent pas les mêmes réglages, si bien que la normalisation est avec perte dans les deux sens :

• Le contrôle ne se mappe pas un-à-un. OpenAI met en cache par préfixe sans notion de points de rupture explicites, tandis qu'Anthropic exige un marqueur cache_control, automatique ou placé sur jusqu'à quatre points explicites, et ne possède pas de cache implicite de préfixe à la manière d'OpenAI ; un prompt_cache_key ne signifie rien pour Gemini. Le passthrough transmet ce qu'un amont prend en charge et ignore ce qu'il ne prend pas.
• La sémantique du TTL diffère. Le ttl d'OpenAI est une durée de vie minimale, celui d'Anthropic est une fenêtre fixe de 5 minutes (ou 1 heure) rafraîchie à l'usage, et le TTL explicite de Gemini est défini par objet de cache. « Une heure » ne signifie pas la même chose chez les trois.
• Le vocabulaire d'usage diffère. Anthropic sépare la création de cache de 5 minutes et de 1 heure ; OpenAI ne sépare lecture et écriture que sur les modèles plus récents ; Gemini signale un seul compte de contenu mis en cache. La passerelle mappe ceux-ci dans des champs communs mais ne peut pas inventer une distinction qu'un fournisseur n'a jamais signalée.

Considérez la passerelle comme l'endroit qui vous donne une seule vue de facturation et un seul chemin de passthrough, pas comme une couche qui fait se comporter à l'identique trois conceptions de caching différentes. En cas de doute, lisez l'usage brut que la passerelle enregistre et réconciliez-le avec la documentation propre du fournisseur.

Faire en sorte que le cache touche vraiment

Quatre habitudes décident si le caching aide ou ne fait rien en silence :

1. Placez le contenu stable en tête. Instructions, outils et matériel de référence d'abord ; le tour de l'utilisateur en dernier. C'est la seule règle qui compte le plus.
2. Gardez le préfixe stable au niveau des octets. Pas d'horodatages, d'identifiants de requête ni d'ordres d'outils mélangés dans la région mise en cache. Un octet modifié tôt invalide le reste.
3. Envoyez les requêtes liées rapprochées dans le temps. Les caches expirent ; regrouper des travaux similaires dans la fenêtre du TTL garde les entrées chaudes. Un cache inactif est un cache froid.
4. Vérifiez avec l'usage, pas au ressenti. Confirmez que cached_tokens (ou l'équivalent du fournisseur) est non nul avant de prétendre à une économie. Un caching que vous supposez mais ne mesurez jamais est une source courante de réductions de coût imaginaires.

Le prompt caching est l'élément au meilleur rendement du menu plus large du travail sur les coûts dans la réduction des coûts d'API LLM, et il se marie naturellement avec la gestion de la fenêtre de contexte des LLM : le même préfixe stable que vous mettez en cache est souvent le contexte que vous renverriez et refactureriez sinon à chaque tour.

FAQ

Le caching réduit-il aussi le coût des jetons de sortie ?

Non. Le caching s'applique uniquement aux jetons d'entrée (prompt) — le préfixe que le fournisseur peut réutiliser. Les jetons de sortie sont générés à neuf à chaque appel et facturés au tarif de sortie normal quel que soit l'état du cache. Si votre coût est dominé par de longues générations plutôt que par de longs prompts, le caching déplace le mauvais nombre ; regardez plutôt la longueur de sortie et le choix du modèle.

Si les comptes de lecture et d'écriture de cache sont tous les deux à zéro, le caching a-t-il échoué ?

Cela signifie que rien n'a été mis en cache pour cette requête — généralement parce que le préfixe était en dessous de la taille cachable minimale du modèle, que le préfixe a changé depuis le dernier appel, ou (pour les schémas explicites) que vous n'avez pas marqué de point de rupture. Les fournisseurs ne renvoient pas d'erreur sur un prompt non cachable ; ils le facturent simplement au tarif d'entrée standard. Lisez les champs d'usage pour confirmer plutôt que de supposer une correspondance.

Une correspondance de cache est-elle garantie si je renvoie exactement le même préfixe ?

Non. Les caches sont au mieux (best-effort) et bornés dans le temps. Les entrées expirent après leur TTL, et une correspondance dépend aussi du routage — c'est pourquoi OpenAI expose prompt_cache_key pour diriger les requêtes liées vers le même backend. Concevez le caching comme une optimisation qui aide généralement, pas comme une garantie sur laquelle vous pouvez facturer.

Une seule requête de passerelle peut-elle utiliser le caching d'OpenAI, d'Anthropic et de Gemini de façon interchangeable ?

Vous pouvez envoyer les contrôles de caching à travers un seul point de terminaison, mais chacun n'est compris que par son propre amont : cache_control atteint Anthropic, prompt_cache_key atteint OpenAI, une poignée CachedContent explicite atteint Gemini. La passerelle normalise l'usage signalé dans des champs communs ; elle ne peut pas faire honorer par un fournisseur la directive de caching d'un autre.

Mesurez un véritable avant/après

Choisissez votre prompt le plus répétitif — celui avec le plus grand préfixe fixe — et exécutez-le deux fois à travers votre passerelle en moins d'une minute. Au premier appel, le préfixe est écrit en cache ; au second, il devrait être lu depuis le cache. Consultez vos journaux d'usage et confirmez que la seconde requête signale un nombre non nul de jetons mis en cache et un coût d'entrée inférieur à celui de la première. Cette paire avant/après, sur votre propre trafic, révèle l'économie réelle bien mieux que n'importe quel multiplicateur publié.

Références

• OpenAI : Prompt caching
• Anthropic : Prompt caching
• Google Gemini : Context caching
• Tarification de l'API OpenAI
• Tarification d'Anthropic