Mise en cache des prompts chez OpenAI et Claude : fonctionnement, TTL, tarifs, pourquoi ça ne marche pas et comment vérifier

La mise en cache des prompts (prompt caching) réutilise le calcul effectué pour la partie d'une requête identique au début d'une requête précédente (le préfixe), afin que cette partie de l'entrée soit traitée moins cher et plus vite. L'API d'OpenAI comme l'API de Claude la proposent, mais la façon de l'activer, la durée de vie du cache, le prix d'une écriture en cache et la manière de vérifier qu'elle fonctionne diffèrent fortement d'un fournisseur à l'autre. Si vous concevez pour les deux avec les mêmes hypothèses, vous risquez d'obtenir un cache qui fonctionne d'un côté pendant que, de l'autre, vous payez l'écriture à chaque requête sans jamais obtenir de hit.

Cet article compare la mise en cache des prompts d'OpenAI et d'Anthropic à partir du texte original des pages « Prompt caching », « Prompt cache diagnostics » et « Pricing » d'OpenAI, et « Prompt caching », « Cache diagnostics », « Pricing » et « Rate limits » d'Anthropic. Il explique en quoi les deux spécifications diffèrent, comment obtenir des hits de cache et comment s'assurer qu'on les obtient. Tous les chiffres ont été vérifiés sur les pages originales le 3 octobre 2026. Pour une vue d'ensemble de la réduction des coûts d'API (choix du modèle, traitement par lots, maîtrise de la sortie, etc.), consultez notre article « Économiser sur les dépenses et les tokens d'IA ».

1. Qu'est-ce que la mise en cache des prompts : réutiliser un préfixe identique

Chaque fois qu'un modèle de langage lit son entrée, il calcule des valeurs intermédiaires pour chaque token (les tenseurs KV, c'est-à-dire clés et valeurs). La mise en cache des prompts conserve ces valeurs du début du prompt jusqu'à un certain point et saute le calcul lorsque la requête suivante commence exactement par les mêmes tokens. Le guide d'OpenAI précise que ce sont les valeurs KV qui sont stockées, et non les tokens eux-mêmes.

Le point clé : seule la partie identique depuis le tout début peut être réutilisée. Dans les deux requêtes ci-dessous, seuls les instructions et les documents sont réutilisables.

Requête 1 : [Instructions 5,000 tokens][Documents 20,000 tokens][Question A]
Requête 2 : [Instructions 5,000 tokens][Documents 20,000 tokens][Question B]
            └────────────── identique jusqu'ici ─────────────┘└ diffère  ┘
→ Les 25,000 tokens d'instructions + documents sont réutilisables

Requête 3 : [Date du jour][Instructions 5,000 tokens][Documents 20,000 tokens][Question C]
            └─ diffère ──┘
→ Même si le reste est identique, aucun token n'est réutilisable

La documentation des deux fournisseurs indique que la mise en cache ne modifie pas le contenu de la sortie. Elle ne stocke pas une réponse précédente pour la rejouer ; elle évite seulement le travail de lecture de l'entrée. C'est pourquoi elle reste utile dans des conversations où chaque question est différente, ou dans des agents qui lisent des documents différents à chaque fois, dès lors qu'il existe un préfixe commun (instructions, définitions d'outils, historique de conversation).

2. Mise en cache des prompts chez OpenAI et Anthropic : comparaison

Le 22 septembre 2026, OpenAI a annoncé des améliorations de la mise en cache pour GPT-6, et le mécanisme a changé pour GPT-5.6 et les modèles suivants (rétention de 30 minutes, points d'arrêt explicites, écritures en cache payantes, etc.). La colonne OpenAI du tableau ci-dessous décrit GPT-5.6 et suivants. Les différences pour GPT-5.5 et antérieurs sont présentées après le tableau.

Sources : OpenAI « Prompt caching », « Prompt cache diagnostics » ; Anthropic « Prompt caching », « Cache diagnostics », « Rate limits » (vérifiées le 3 octobre 2026)

GPT-5.5 et les modèles antérieurs n'ont que la mise en cache implicite, avec des points d'arrêt placés automatiquement à intervalles fixes, et sans surcoût pour l'écriture en cache. La rétention se règle avec prompt_cache_retention : selon le guide, in_memory dure « environ 5 à 10 minutes d'inactivité, jusqu'à 1 heure », et 24h « en général environ 30 minutes, jusqu'à 24 heures ». En passant à GPT-5.6 ou suivant, remplacez ce réglage par prompt_cache_options.ttl.

Les prix par token de chaque modèle figurent dans notre comparatif « Claude vs ChatGPT : comparatif des tarifs ». Pour les modèles GPT-6 (Astra, Sol, Luna), voir « notre article sur GPT-6 Sol et Luna », et pour les modèles actuels de tous les fournisseurs, « Dates de coupure des connaissances des modèles d'IA ».

3. Quand le cache fonctionne : préfixe, longueur minimale, TTL et portée

Le préfixe commun et l'ordre de la requête

Sur les deux plateformes, le cache ne fonctionne que si le préfixe jusqu'au point d'arrêt est strictement identique. Claude lit la requête depuis le début dans l'ordre tools → system → messages : modifier une seule définition d'outil invalide donc le cache du prompt système et de l'historique de conversation qui suivent. OpenAI explique de même que les définitions d'outils, le format de sortie (text.format), l'effort de raisonnement (reasoning.effort) et les réglages similaires font partie du préfixe.

En pratique, l'organisation est la même des deux côtés : d'abord ce qui ne change pas (définitions d'outils, instructions, documents), et à la fin ce qui change à chaque requête (dates, données propres à chaque utilisateur, question). Prolongez une conversation en ajoutant à la fin, sans réécrire l'historique.

Placer les points d'arrêt : automatique ou manuel

Le mode implicite d'OpenAI (GPT-5.6 et suivants) place un point d'arrêt à la fin du message éligible le plus récent (un message utilisateur, le dernier d'une série de résultats d'outils, etc.). En mode explicite uniquement, seuls les emplacements où vous ajoutez prompt_cache_breakpoint deviennent des points d'arrêt, et si vous n'en ajoutez aucun, le cache n'est pas utilisé et vous ne payez pas non plus d'écriture.

La mise en cache automatique de Claude, activée par un unique "cache_control": {"type": "ephemeral"} au niveau supérieur, place un point d'arrêt sur le dernier bloc pouvant être mis en cache et le fait avancer à mesure que la conversation s'allonge. Ajouter cache_control à des blocs précis vous permet de choisir vous-même les points d'arrêt.

// Claude : point d'arrêt à la fin du prompt système fixe (point d'arrêt explicite)
{
  "model": "claude-sonnet-5-5",
  "max_tokens": 1024,
  "system": [
    {
      "type": "text",
      "text": "Longues instructions et documents...",
      "cache_control": { "type": "ephemeral" }
    }
  ],
  "messages": [{ "role": "user", "content": "La question du jour..." }]
}

// OpenAI (Responses API) : point d'arrêt après les instructions fixes, mode explicite uniquement
{
  "model": "gpt-6.1-sol",
  "prompt_cache_options": { "mode": "explicit" },
  "input": [
    {
      "role": "developer",
      "content": [{
        "type": "input_text",
        "text": "Longues instructions et documents...",
        "prompt_cache_breakpoint": { "mode": "explicit" }
      }]
    },
    { "role": "user", "content": "La question du jour..." }
  ]
}

Longueur minimale : les préfixes courts ne sont pas mis en cache

Pour GPT-5.6 et suivants, le minimum d'OpenAI est de 1,024 tokens d'entrée visible (les instructions cachées qu'OpenAI ajoute en coulisses ne comptent pas). Chez Claude, cela dépend du modèle.

Source : Anthropic « Prompt caching », Cache limitations (vérifiée le 3 octobre 2026). Sur Bedrock, ce sont les valeurs de la documentation d'AWS qui s'appliquent.

Si un prompt Claude est sous le minimum, ajouter cache_control ne provoque pas d'erreur : le prompt n'est simplement pas mis en cache, sans avertissement. Dans ce cas, cache_creation_input_tokens et cache_read_input_tokens valent tous deux 0 dans usage. Le minimum change quand on change de modèle : un préfixe mis en cache sur le modèle précédent peut donc cesser de l'être (le guide d'OpenAI fait la même mise en garde).

TTL : attention au point de départ du décompte

Chez OpenAI (GPT-5.6 et suivants), le cache dure « au moins 30 minutes après la dernière écriture ou réutilisation, et peut persister plus longtemps ». Claude utilise 5 minutes par défaut, et choisir 1 heure fait passer l'écriture à 2x le prix d'entrée. Sur les deux plateformes, le TTL est renouvelé sans surcoût à chaque utilisation du cache.

Claude a un piège : le TTL est compté à partir du début de la requête, et non de la fin de la réponse. Dans l'exemple de la documentation, si une réponse met 4 minutes à être générée, la requête suivante doit démarrer dans la minute environ qui suit la fin de cette réponse pour toucher le cache de 5 minutes. Pour des agents qui produisent de longues sorties, 5 minutes, c'est plus court qu'il n'y paraît.

Portée du cache et emplacement

Le cache d'OpenAI est propre à chaque organisation et n'est pas partagé entre régions de traitement (réglages de résidence des données). Le guide précise aussi que le cache réside sur des machines individuelles et qu'au-delà d'environ 15 requêtes par minute, les requêtes peuvent être routées vers une autre machine. Depuis GPT-5.6, OpenAI gère le routage automatiquement, et prompt_cache_key est devenu un réglage facultatif servant à séparer les rapports de cache par client plutôt qu'un moyen d'augmenter le taux de hit (sur GPT-5.5 et antérieurs, utiliser la même clé pour diriger les requêtes vers la même machine avait de l'importance).

L'API Claude limite le cache à l'espace de travail. Au sein d'une même organisation, des espaces de travail différents ne partagent pas de cache, même pour des prompts identiques. Sur Bedrock et Google Cloud, la portée est l'organisation. Par ailleurs, le cache n'est disponible qu'une fois la première réponse commencée : si vous envoyez d'un coup de nombreuses requêtes parallèles avec le même préfixe, les autres deviennent elles aussi des écritures avant que la première ait écrit le cache.

4. Tarifs et seuil de rentabilité : combien de lectures pour que le cache soit rentable

Comme une écriture en cache coûte plus cher qu'une entrée normale, une entrée de cache écrite et jamais lue coûte plus cher que de ne pas utiliser de cache du tout. Soit w le multiplicateur d'écriture, r celui de lecture et n le nombre de lectures après l'écriture. Le nombre de lectures nécessaire pour être rentable découle de ces formules.

Avec cache    = w + n × r
Sans cache    = 1 + n          (envoyer le même préfixe n + 1 fois tel quel)
Rentable si   : n > (w − 1) ÷ (1 − r)

Multiplicateurs rapportés à un prix d'entrée de 1. Calculé à partir d'OpenAI « Prompt caching » et « Pricing » et d'Anthropic « Pricing » (vérifiées le 3 octobre 2026). Seul le préfixe est comparé ; la sortie et la question propre à chaque requête sont exclues.

Le guide d'OpenAI contient le même calcul pour un modèle à 0.1x : écrire une fois et lire une fois coûte 1.35x, contre 2x pour traiter deux fois sans cache. La page de tarifs d'Anthropic indique de même que le cache de 5 minutes est rentable après une lecture et celui d'1 heure après deux. Aussi bon marché que soit la lecture, un cache d'1 heure ne peut pas être rentable avec une seule lecture, car l'écriture à 2x pèse trop lourd.

Modèles au même prix d'entrée : l'intervalle entre requêtes inverse le résultat

Aux tarifs officiels du 3 octobre 2026, GPT-6.1 Sol et Claude Sonnet 5.5 facturent tous deux $2 par million de tokens d'entrée, et leur prix d'écriture à 5 minutes est le même, $2.50. Ce qui diffère, c'est le prix de lecture (Sol $0.10, Sonnet 5.5 $0.20) et le TTL. Nous avons calculé le coût du préfixe pour l'envoi, 10 fois, d'un préfixe de 100,000 tokens à différents intervalles.

Prix issus d'OpenAI « Pricing » (Standard, jusqu'à 272K) et d'Anthropic « Pricing » (toutes deux vérifiées le 3 octobre 2026). 100,000 tokens = 0.1 (en unités d'1 million de tokens). En cas de hit, la première requête est une écriture et les 9 autres sont des lectures ; en cas d'échec, les 10 sont des écritures. Chez OpenAI, un échec peut aussi venir du routage entre machines ou de facteurs similaires : les lignes avec hit sont donc des valeurs en conditions favorables.

Par exemple, GPT-6.1 Sol toutes les 3 minutes revient à « 0.1 × $2.50 (une écriture) + 0.1 × $0.10 × 9 lectures = $0.25 + $0.09 = $0.34 ». Le tableau montre trois choses.

• Avec des intervalles de 5 minutes ou moins, l'écart entre les deux est faible ($0.34 contre $0.43). Tout se joue sur le prix de lecture.
• Avec des intervalles de 5 à 30 minutes, le TTL de 30 minutes d'OpenAI l'emporte. Avec le TTL de 5 minutes de Claude, chaque requête devient une écriture et coûte $2.50, soit plus que sans cache. Passer à 1 heure fait descendre à $0.58.
• Quand l'intervalle dépasse le TTL, le cache fait perdre de l'argent. Toutes les 2 heures, l'option la moins chère est de ne pas utiliser de cache, à $2.00. Chez Claude, ne mettez pas cache_control ; chez OpenAI GPT-5.6 et suivants, utilisez le mode explicite uniquement sans point d'arrêt pour éviter les frais d'écriture.

En particulier, comme la mise en cache est activée par défaut chez OpenAI GPT-5.6 et suivants, rester en mode implicite peut signifier payer l'écriture même pour des entrées que vous n'enverrez plus jamais. Si votre charge envoie beaucoup d'entrées longues à usage unique, vérifiez cache_write_tokens dans usage et décidez s'il faut passer au mode explicite uniquement.

Comment le cache se combine avec les autres tarifs

• Batch : la grille tarifaire d'OpenAI comporte aussi des prix d'entrée en cache et d'écriture en cache pour Batch et Flex (GPT-6.1 Sol en Batch : $1 en entrée, $0.05 en lecture de cache, $1.25 en écriture de cache). Anthropic indique que les multiplicateurs de cache se cumulent avec la remise de 50 % du traitement par lots, mais comme les requêtes par lots sont traitées en parallèle et sans ordre particulier, elle qualifie les hits de cache de « best effort » (sans garantie).
• Entrées longues : chez OpenAI, lorsque l'entrée dépasse 272K tokens, les prix d'entrée, de lecture et d'écriture en cache doublent (les multiplicateurs restent identiques). Chez Anthropic, Claude 4.6 et les modèles suivants appliquent le même prix jusqu'à 1 million de tokens.
• Préchauffage : des deux côtés, l'écriture de préchauffage est facturée au prix normal d'écriture. Le max_tokens: 0 de Claude n'entraîne aucun frais de sortie.

5. Pourquoi la mise en cache des prompts ne fonctionne pas : causes fréquentes

En croisant les remarques des deux fournisseurs sur les pièges courants avec les listes de raisons que renvoient leurs diagnostics, les causes d'échec du cache se répartissent en trois grands groupes.

Problèmes fréquents chez OpenAI

• Pas de point d'arrêt juste après le préfixe commun : le mode implicite place le point d'arrêt à la fin du dernier message ; avec « instructions fixes + message utilisateur différent à chaque fois », la partie variable est donc écrite aussi et la requête suivante échoue. Placez un point d'arrêt explicite juste après la partie fixe.
• Passer au mode explicite uniquement en cours de route : ce mode ne cherche que les points d'arrêt que vous avez placés ; il ne touche donc pas les entrées de cache écrites en mode implicite.
• Ajouter du contenu au même message : si un message qui se terminait par « contenu A » devient « contenu A + contenu B », le point d'arrêt précédent se retrouve au milieu d'un message et le cache échoue. Ajoutez le nouveau contenu sous forme de nouveau message.
• Changer l'effort de raisonnement en cours de route : sur les modèles GPT-6, vous pouvez le modifier sans casser le cache en laissant tel quel le reasoning.effort de la requête et en ajoutant un configuration_update après l'entrée.
• Lancer une compaction (compression du contexte) : le préfixe change, donc le taux de hit baisse. Le guide note toutefois que le coût total peut quand même diminuer puisque l'entrée se réduit, et conseille de comparer le coût total.

Problèmes fréquents chez Claude

• Un point d'arrêt sur un bloc qui change à chaque fois : les écritures n'ont lieu qu'aux positions des points d'arrêt, et les lectures ne cherchent qu'en arrière des positions d'écriture antérieures. Si un point d'arrêt se trouve sur un bloc qui change à chaque fois, vous payez l'écriture à chaque fois sans jamais obtenir de hit. La mise en cache automatique place elle aussi son point d'arrêt sur le dernier bloc et tombe dans le même piège. Placez un point d'arrêt explicite sur le dernier bloc qui ne change pas.
• 20 blocs ou plus ajoutés en un seul tour : la recherche des écritures antérieures couvre jusqu'à 20 positions en arrière à partir d'un point d'arrêt. Si la conversation grossit beaucoup d'un coup, l'écriture antérieure sort de cette fenêtre. Gardez un point d'arrêt supplémentaire plus tôt dans le prompt.
• Réécrire le prompt système en cours de route : sur les modèles compatibles, vous pouvez ajouter des instructions sans casser le cache en laissant le system de niveau supérieur inchangé et en ajoutant dans messages un message avec "role": "system".
• Alterner entre le mode rapide (speed: "fast") et le mode standard : cela invalide les caches du système et de la conversation.

6. Comment vérifier les hits de cache : usage et diagnostic

Commencez par usage : input_tokens n'a pas le même sens

Sur les deux plateformes, le usage de la réponse indique combien a été lu depuis le cache et combien y a été écrit. Le point à surveiller : input_tokens a des sens opposés sur les deux plateformes.

Sources : OpenAI « Prompt caching », Monitor cache performance ; Anthropic « Prompt caching », Tracking cache performance (vérifiées le 3 octobre 2026)

Si vous divisez par l'input_tokens de Claude comme s'il s'agissait de l'entrée totale, le taux de hit comme le coût seront largement faussés. Quand vous réunissez les chiffres des deux fournisseurs dans un même tableau de bord, normalisez les totaux avec les formules ci-dessus avant de comparer. Le guide d'OpenAI recommande de calculer le « taux de hit en tokens » comme le total des tokens lus depuis le cache divisé par le total des tokens d'entrée, agrégé par utilisateur, par jour, etc.

Pour le coût, chez OpenAI c'est « (entrée − lectures − écritures) × prix + lectures × prix × 0.1 + écritures × prix × 1.25 », et chez Claude « input_tokens × prix + lectures × prix × 0.1 + écritures × prix × 1.25 (2 pour la part à 1 heure) » (remplacez le multiplicateur de lecture par 0.05 ou une autre valeur selon le modèle). OpenAI propose un « Prompt Caching Dashboard » sur sa page d'utilisation, et la documentation Rate limits d'Anthropic renvoie à la page Usage pour consulter le taux de hit du cache.

Que vérifier, dans l'ordre, quand les lectures sont à 0

1. Les écritures sont-elles aussi à 0 ? Chez Claude, si les deux sont à 0, le prompt est sous la longueur minimale ou cache_control manque. Chez OpenAI en mode explicite uniquement, il n'y a pas non plus d'écriture si vous n'avez placé aucun point d'arrêt.
2. Des écritures apparaissent-elles à chaque requête ? Le point d'arrêt est sur une position qui change à chaque fois, ou quelque chose dans le préfixe change à chaque fois. Utilisez le diagnostic décrit ci-dessous pour trouver ce qui a changé.
3. Combien de temps s'est écoulé depuis la requête précédente ? Vérifiez si l'on a dépassé les 5 minutes de Claude (temps de génération de la réponse compris) ou les 30 minutes d'OpenAI.

Diagnostic d'OpenAI : prompt_cache_diagnostics

Dans la Responses API d'OpenAI, sur les modèles compatibles à partir de GPT-5.6, passer l'ID d'une réponse précédente dans prompt_cache_options.comparison_response_id place le résultat de la comparaison entre cette requête et la requête actuelle dans prompt_cache_diagnostics. La documentation indique que cela ne coûte rien de plus et ne compte pas séparément dans les limites de débit.

// Ajouter une cible de comparaison à la deuxième requête
{
  "model": "gpt-6.1-sol",
  "input": [ ...même préfixe que la première requête..., { "role": "user", "content": "Question suivante" } ],
  "prompt_cache_options": { "comparison_response_id": "resp_(ID de la première réponse)" }
}

// Exemple renvoyé en cas d'échec (exemple de la documentation : un outil a été renommé)
{
  "prompt_cache_diagnostics": {
    "type": "cache_miss",
    "reason": "tools_changed",
    "comparison_reusable_tokens": 5629,
    "cache_missed_tokens": 5629
  }
}

type prend quatre valeurs : cache_hit, cache_miss, comparison_response_not_found (pas d'enregistrement de comparaison, ou expiré) et unavailable (pas de conclusion possible). En cas d'échec, reason est l'une de ces neuf valeurs.

Source : OpenAI « Prompt cache diagnostics », Fix a cache miss (vérifiée le 3 octobre 2026)

Diagnostic de Claude : diagnostics

Sur l'API Claude, il faut inclure un champ diagnostics dans chaque requête, car l'API ne conserve une empreinte de comparaison (hachages et nombres de tokens estimés) que pour les requêtes qui le contiennent. Au premier tour, passez "previous_message_id": null ; ensuite, passez l'id de la réponse précédente.

// À partir du deuxième tour
{
  "model": "claude-sonnet-5-5",
  "max_tokens": 1024,
  "cache_control": { "type": "ephemeral" },
  "diagnostics": { "previous_message_id": "msg_(id de la réponse précédente)" },
  "system": "...",
  "messages": [ ... ]
}

Si le diagnostics de la réponse vaut null, aucune différence n'a été trouvée (ou aucune comparaison n'a eu lieu) ; {"cache_miss_reason": null} signifie que la comparaison n'est pas encore terminée ; et si une raison est présente, elle indique le premier endroit où les requêtes divergent. Il y a six raisons : model_changed, system_changed, tools_changed, messages_changed, previous_message_not_found et unavailable. Les raisons *_changed sont accompagnées de cache_missed_input_tokens, une estimation de ce qui a été perdu.

La documentation de Claude recommande de lire le diagnostic avec cache_read_input_tokens.

Source : Anthropic « Cache diagnostics », Reading diagnostics alongside usage (vérifiée le 3 octobre 2026)

Les deux fonctions de diagnostic ont beaucoup en commun : toutes deux ne renvoient que la première différence trouvée ; après l'avoir corrigée, il faut donc comparer de nouveau. Les différences : le diagnostic de Claude ne fonctionne que sur l'API Claude (pas sur Amazon Bedrock, Google Cloud, Claude Platform on AWS ni Microsoft Foundry) et ne compare qu'avec des requêtes du même espace de travail. La documentation d'OpenAI ne décrit aucune étape pour marquer à l'avance la requête qui servira de comparaison. Chez Claude, si la requête précédente ne contenait pas elle aussi diagnostics, vous obtenez previous_message_not_found.

7. Chiffres de taux de hit : exemples des fournisseurs et données tierces

Les chiffres de taux de hit du cache qui circulent ont des significations très différentes selon qui les a publiés et dans quelles conditions. Les voici, séparés.

Chiffres des fournisseurs

• Exemples du guide d'OpenAI : une charge d'évaluation ponctuelle (un LLM utilisé comme évaluateur) avec un point d'arrêt explicite après une grille fixe a atteint un « taux de hit en tokens d'environ 70 % », et un agent qui appelle des outils de façon répétée a dépassé « 90 % ». Le guide prévient qu'il s'agit d'exemples de résultats possibles et que le plafond dépend de la charge.
• Commentaires de clients dans l'annonce d'OpenAI (22 septembre 2026) : l'équipe de Manus indique qu'après avoir revu le placement de ses points d'arrêt, son taux de hit sur les modèles d'OpenAI est passé « d'environ 85 % à plus de 90 % de façon constante » en moins d'une semaine. Un commentaire sur GitHub Copilot indique qu'au cours des derniers mois, la part de l'entrée à retraiter a baissé de plus de 50 % par rapport à sa référence antérieure. Il s'agit dans les deux cas de citations de clients publiées par OpenAI sur sa propre page, et non de mesures indépendantes.
• Anthropic : la documentation ne donne aucun chiffre réel de taux de hit. La page Rate limits contient un exemple chiffré, « avec un taux de hit de 80 %, une limite d'entrée de 2 millions de tokens par minute permet en pratique de traiter 10 millions de tokens par minute », mais c'est un calcul à partir d'une hypothèse, pas une mesure.

Données tierces : pas un verdict direct sur le meilleur

Requesty, un service qui route les requêtes vers plusieurs API d'IA, a agrégé les requêtes passées par sa propre passerelle et publié des taux de hit pour avril 2026 de 77 % pour Anthropic en direct (77.50 % dans le tableau) et de 36 % pour OpenAI (36.40 %) (« Prompt-cache hit rate per provider, April 2026 », mis à jour le 9 mai). À première vue, Claude semble obtenir plus de deux fois plus de hits, mais quatre raisons empêchent d'utiliser ces chiffres pour la comparaison de cet article.

1. Les données sont antérieures au changement d'OpenAI : OpenAI a introduit la rétention de 30 minutes et les points d'arrêt explicites le 22 septembre, et les données d'avril datent d'avant.
2. Les charges diffèrent : ce sont les résultats d'applications de différents utilisateurs envoyant des prompts différents à des intervalles différents via la passerelle, et non le même prompt envoyé aux deux fournisseurs. Chez Claude, seules les requêtes où les utilisateurs ont eux-mêmes ajouté cache_control sont comptées.
3. Le dénominateur : la page indique « cached_tokens ÷ input_tokens », mais comme expliqué en section 6, l'input_tokens de Claude exclut les tokens en cache. La page ne dit pas comment elle les a convertis.
4. La page se contredit : à un endroit, elle place Claude via Google Cloud (Vertex) à 24 %, et à un autre à 14 %.

Lors de notre recherche du 3 octobre 2026, nous n'avons trouvé aucune mesure tierce comparant les deux caches dans les mêmes conditions. Au bout du compte, le seul moyen de savoir si le cache fonctionne dans votre application est de le mesurer dans vos propres données d'utilisation. Calculez le taux de hit et le coût avec les formules de la section 6, et en cas d'échec, utilisez le diagnostic pour en trouver la cause.

Résumé

La mise en cache des prompts d'OpenAI et celle de Claude reposent sur la même idée : réutiliser le préfixe identique et facturer les lectures autour de 0.1x le prix d'entrée. La différence : chez OpenAI (GPT-5.6 et suivants), elle est activée par défaut, conserve le cache au moins 30 minutes et facture l'écriture 1.25x, tandis que Claude ne met en cache que si vous ajoutez cache_control, conserve le cache 5 minutes (avec une option d'1 heure) et facture l'écriture 1.25x (2x pour 1 heure).

Côté tarifs, comme l'écriture coûte plus cher, un cache jamais lu est une perte. Les caches de 5 et 30 minutes sont rentables après une lecture, et le cache d'1 heure de Claude après deux. Avec des intervalles de 5 à 30 minutes entre requêtes, le TTL de 30 minutes d'OpenAI a l'avantage, et chez Claude, choisir 1 heure évite l'inversion. Si vos requêtes sont plus espacées que le TTL, se passer de cache revient moins cher.

Vérifiez le fonctionnement du cache en regardant les volumes de lecture et d'écriture dans usage. L'input_tokens de Claude ne couvre que ce qui suit le point d'arrêt : calculez d'abord le total, puis le taux de hit. En cas d'échec, le prompt_cache_diagnostics d'OpenAI et le diagnostics de Claude indiquent en quoi la requête diffère de la précédente. Pour d'autres moyens de réduire les coûts, voir « Économiser sur les dépenses et les tokens d'IA ».

FAQ

Q. Quel est le TTL de la mise en cache des prompts d'OpenAI ?

R. Pour GPT-5.6 et suivants, au moins 30 minutes après la dernière écriture ou réutilisation. Le réglage prompt_cache_options.ttl n'accepte que "30m", et le guide indique que le cache peut persister plus longtemps. Pour GPT-5.5 et antérieurs, on choisit avec prompt_cache_retention : in_memory dure environ 5 à 10 minutes d'inactivité (jusqu'à 1 heure) et 24h jusqu'à 24 heures.

Q. Peut-on prolonger le TTL de la mise en cache des prompts de Claude ?

R. Oui, "cache_control": {"type": "ephemeral", "ttl": "1h"} donne 1 heure. L'écriture coûte 2x le prix d'entrée, ce n'est donc rentable que si le cache est lu au moins deux fois. Si vous continuez à l'utiliser à moins de 5 minutes d'intervalle, le cache de 5 minutes est renouvelé gratuitement à chaque lecture. Les deux sont comptés à partir du début de la requête : le temps passé à générer une longue réponse entre donc dans le TTL.

Q. La mise en cache modifie-t-elle les réponses ?

R. Non. La documentation des deux fournisseurs indique que la mise en cache n'affecte pas la génération de la sortie. Ce qui est stocké, c'est le calcul intermédiaire issu de la lecture de l'entrée, pas la réponse elle-même. Comme sans cache, une même entrée ne produit pas toujours la même réponse.

Q. Peut-on vider le cache manuellement ?

R. Aucune des deux plateformes ne le permet. OpenAI indique que les entrées expirent selon le TTL et les réglages, et Anthropic qu'elles sont supprimées automatiquement après au moins 5 minutes sans utilisation (1 heure si vous avez choisi 1 heure). Si vous voulez remplacer le contenu du prompt, modifiez le préfixe : la requête suivante écrira une nouvelle entrée.

Sources

• Documentation de l'API OpenAI : Prompt caching
• Documentation de l'API OpenAI : Prompt cache diagnostics
• Documentation de l'API OpenAI : Pricing
• OpenAI : Better prompt caching for GPT-6 (22 septembre 2026)
• Documentation de Claude Platform : Prompt caching
• Documentation de Claude Platform : Cache diagnostics
• Documentation de Claude Platform : Pricing
• Documentation de Claude Platform : Rate limits
• Requesty : Prompt-cache hit rate per provider, April 2026

Toutes les sources ont été vérifiées dans leur version originale le 3 octobre 2026. Les prix, les TTL et les longueurs minimales peuvent changer à mesure que de nouveaux modèles sont ajoutés : vérifiez-les sur la page de tarifs de chaque fournisseur avant de vous y fier. Les calculs de coût de cet article sont de l'arithmétique à partir des prix officiels, et non des mesures obtenues en appelant nous-mêmes les API.