Cache de prompts OpenAI sur 12 heures : rentabiliser l’écriture à 2.5×

Utilisez le cache de prompts OpenAI de 12 heures pour un préfixe stable que votre agent réutilise après de longues pauses ; gardez le contenu variable de la session sur 30m ou hors des écritures en cache. Si l’autre option impose une nouvelle écriture 30m à chaque requête, une seule écriture 12h devient moins chère à la troisième requête au total, soit à la deuxième réutilisation, à condition que le préfixe corresponde toujours. Si 30m retrouve déjà le préfixe en cache à chaque requête, prolonger la durée augmente le coût sans réduire le tarif de lecture.

Combien coûtent 30m et 12h ?

L’option 12h prolonge l’accès au tarif d’entrée en cache, au prix d’une écriture deux fois plus chère que celle du cache par défaut. Le journal des modifications de l’API du 20 octobre 2026 a introduit cette option pour Responses ; le guide du cache de prompts décrit les règles suivantes pour GPT-5.6 et les modèles ultérieurs, vérifiées le 2026-10-24.

Type de facturation de l’entrée	Multiplicateur du tarif d’entrée ordinaire	GPT-6.1 Sol, USD pour 1M tokens
Entrée ordinaire	1×	$2.00
Écriture `30m`, par défaut	1.25×	$2.50
Écriture `12h`	2.5×	$5.00
Lecture du cache, quelle que soit la durée	0.1× sur la plupart des modèles ; 0.05× sur GPT-6.1 Sol	$0.10

Ce sont les tarifs totaux d’écriture. Un token facturé comme une écriture 12h coûte 2.5× le tarif d’entrée ordinaire ; le tarif ordinaire ne s’y ajoute pas.

La colonne en dollars utilise les tarifs Standard actuels d’OpenAI pour gpt-6.1-sol, avec des prompts ne dépassant pas 272K tokens d’entrée et sans supplément de traitement régional. La sortie coûte $10.00 pour 1M tokens. Les prompts plus longs, les autres niveaux de service et le traitement régional peuvent modifier les tarifs ; consultez les conditions tarifaires du modèle applicables avant d’utiliser les calculs ci-dessous.

Le préfixe réutilisable doit contenir au moins 1,024 tokens d’entrée visibles. Une requête volumineuse dont seul un court début reste inchangé ne rend pas automatiquement ce début admissible au cache.

Quand l’écriture plus chère devient-elle rentable ?

Comptez les écritures que la durée supérieure permet d’éviter. Notons B le coût d’entrée ordinaire de votre préfixe inchangé, n le nombre total de requêtes, r le multiplicateur de lecture et k le nombre d’écritures 30m, première écriture comprise.

En supposant que chaque écriture ou lecture réussie couvre tout ce préfixe, avec une écriture 12h suivie de lectures réussies :

12h cost = B × [2.5 + (n - 1) × r]
30m cost = B × [1.25 × k + (n - k) × r]
No-cache cost = B × n

Avec r = 0.1 comme avec r = 0.05, le cache de longue durée devient moins cher que l’entrée sans cache à n = 3. Face au cache par défaut, il devient moins cher lorsque k >= 3, tant que la politique 12h ne nécessite qu’une seule écriture. Il faut donc éviter deux écritures courtes supplémentaires après la première ; accumuler de nombreuses lectures réussies ne suffit pas.

Si les deux politiques écrivent une fois, puis trouvent le préfixe en cache à chaque requête, 12h conserve un surcoût de 1.25 × B. Les conversations interactives soutenues ont donc peu de raisons de payer l’écriture de longue durée, sauf si elles reprennent aussi après des pauses qui imposent de nouvelles écritures.

Une pause de plus de 30 minutes ouvre une possibilité d’économie, mais ne prouve pas que le préfixe sera absent du cache. OpenAI peut conserver les entrées au-delà de leur durée minimale, et une lecture 30m renouvelle la couverture pour au moins 30 minutes supplémentaires. Pour prévoir le coût d’une charge de travail existante, utilisez le nombre d’écritures réellement observé.

Pour une estimation concrète, prenez un préfixe de 10,000 tokens sur GPT-6.1 Sol aux tarifs Standard : B = $0.02 et r = 0.05. Envoyez 12 requêtes, une par heure de l’heure 0 à l’heure 11, en gardant le préfixe inchangé.

Comportement du cache supposé	Coût d’entrée du préfixe sur les 12 requêtes
Sans cache : 12 entrées ordinaires	$0.240
`30m` : les 12 requêtes nécessitent une écriture	$0.300
`12h` : une écriture et 11 lectures	$0.061
`30m` : une écriture et 11 lectures	$0.036

Les deux lignes 30m montrent pourquoi l’intervalle entre requêtes ne suffit pas à déterminer l’économie. La ligne où chaque requête écrit repose sur une hypothèse, pas sur un résultat inévitable avec des appels espacés d’une heure. Ces estimations excluent les suffixes variables, les tokens de sortie et les éventuels frais d’outils ; elles ne correspondent pas à des factures réelles.

Pourquoi appliquer 12h à toute la requête peut coûter plus cher

Le réglage prompt_cache_options.ttl: "12h" au niveau de la requête s’applique aussi au point de coupure implicite, c’est-à-dire à la limite de cache ajoutée automatiquement. Avec le réglage par défaut mode: "implicit", le nouveau contenu admissible de la conversation peut donc entraîner une écriture à 2.5× à chaque tour, même si l’ancien préfixe est lu à bas prix.

Pour un agent qui accumule des résultats d’outils et des messages utilisateur, ce suffixe croissant peut coûter plus que les économies réalisées sur le début stable. Un taux élevé de lectures réussies depuis le cache ne suffit pas à montrer que la politique est économique.

Choisissez l’une de ces configurations :

Documents partagés stables et contexte de session réutilisable : définissez 30m par défaut pour la requête et remplacez cette valeur par 12h à la fin des documents partagés.
Contenu stable et questions utilisées une seule fois : utilisez mode: "explicit" et placez la question variable après le dernier point de coupure explicite.
Conversation dont le contexte récent sera bientôt réutilisé : conservez mode: "implicit" avec 30m par défaut pour la requête, ainsi qu’un point de coupure 12h sur le préfixe partagé.

Un point de coupure couvre tout le préfixe qui le précède. Pour une requête sans cache préalable, avec un point de coupure 12h à 2,000 tokens et un point de coupure 30m à 5,000, la facturation attribue 2,000 tokens aux écritures de longue durée et 3,000 aux écritures de courte durée. Placez plutôt un point de coupure 12h à la limite suivante de 5,000 tokens, et les 5,000 tokens seront facturés au tarif d’écriture de longue durée. Chaque token est facturé une seule fois, selon la plus longue durée de cache sélectionnée qui le couvre.

Deux changements de durée comptent également. Passer d’une couverture 30m encore valide à 12h entraîne une nouvelle écriture de longue durée, sans crédit pour l’écriture précédente. Lorsqu’une requête 30m lit un préfixe encore couvert par 12h, ces tokens sont facturés au tarif de lecture, sans redémarrer un délai de 12 heures ni ajouter de frais d’écriture. Ces règles de chevauchement et de durée justifient de choisir la politique avant de charger un grand préfixe dans le cache.

Configurer 12h et 30m dans une même requête Responses

Utilisez 30m par défaut pour la requête et des points de coupure explicites pour séparer les références partagées, le contexte de la session et la question actuelle. Cet exemple appelle directement l’API Responses d’OpenAI et affiche le texte généré ainsi que les données d’utilisation nécessaires au contrôle de la facturation.

Il vous faut Bash, curl, jq et une clé API OpenAI donnant accès à gpt-6.1-sol. Préparez les fichiers suivants dans le répertoire courant :

shared-context.md : des consignes d’ingénierie et des références utiles, réutilisées tout au long de la journée, contenant au moins 1,024 tokens d’entrée visibles.
session-context.md : le contexte du déploiement ou de la pull request en cours, que vous comptez réutiliser pendant cette session.

Ne modifiez aucun des deux fichiers entre les deux appels de l’exemple. Lorsque read attend une saisie, collez votre clé API et appuyez sur Entrée ; le terminal ne l’affichera pas. L’authentification suit le guide de démarrage de l’API OpenAI.

set -o pipefail
read -rs OPENAI_API_KEY && export OPENAI_API_KEY

cache_request() {
  jq -n \
    --rawfile shared ./shared-context.md \
    --rawfile session ./session-context.md \
    --arg question "$1" \
    '{
  model: "gpt-6.1-sol",
  service_tier: "default",
  reasoning: {effort: "low"},
  prompt_cache_options: {mode: "explicit", ttl: "30m"},
  input: [
    {
      role: "developer",
      content: [{
        type: "input_text",
        text: $shared,
        prompt_cache_breakpoint: {mode: "explicit", ttl: "12h"}
      }]
    },
    {
      role: "user",
      content: [
        {
          type: "input_text",
          text: $session,
          prompt_cache_breakpoint: {mode: "explicit"}
        },
        {type: "input_text", text: $question}
      ]
    }
  ]
}' |
  curl --silent --show-error --fail-with-body \
    https://api.openai.com/v1/responses \
    -H "Authorization: Bearer $OPENAI_API_KEY" \
    -H "Content-Type: application/json" \
    --data-binary @- |
  jq '{id, status, service_tier,
  text: ([.output[]? | .content[]? |
    select(.type == "output_text") | .text] | join("\n")),
  usage, error}'
}

cache_request "Which deployment risks need review? Answer briefly." &&
cache_request "Which test should run first? Answer briefly."

Le premier bloc de contenu remplace la valeur par défaut de la requête par "ttl": "12h". Le bloc de session ne définit pas son propre TTL et hérite de "30m". Comme la requête utilise uniquement des points de coupure explicites, la question finale n’entraîne pas de frais d’écriture en cache ; elle reste facturée au tarif d’entrée ordinaire.

Pour un préfixe admissible qui n’est pas encore en cache, la première réponse terminée devrait signaler des écritures de longue durée dans usage.input_tokens_details.cache_write_tokens_details.ttl_12h_tokens. La deuxième devrait afficher cached_tokens > 0 sans nouvelle écriture de longue durée, tant que le préfixe et sa couverture restent valides. Le champ text renvoyé contient la réponse exploitable. Répéter immédiatement l’appel permet de contrôler la correspondance et la comptabilisation ; évaluez les économies après de longues pauses avec les intervalles réels de votre production.

Si vous obtenez 400 invalid_request_error, vérifiez les valeurs exactes du TTL, le modèle choisi et l’endpoint Responses. Si les deux appels renvoient zéro token en cache, vérifiez d’abord la longueur du préfixe, puis comparez les fichiers, le modèle, les réglages et la position des points de coupure. Des modifications avant le point de coupure partagé, notamment dans les définitions d’outils lorsque vous en ajoutez, peuvent empêcher la réutilisation.

Pour mesurer une référence sans cache, conservez mode: "explicit" et retirez tous les prompt_cache_breakpoint. Le schéma officiel des requêtes précise que le mode explicite sans marqueurs n’utilise pas le cache de prompts.

Reconstituer les frais d’entrée à partir de usage

Traitez l’entrée ordinaire, les lectures du cache et les deux catégories d’écriture comme des ensembles distincts. Le nombre total de tokens écrits, cache_write_tokens, contient déjà les composantes ttl_30m_tokens et ttl_12h_tokens ; facturer les trois reviendrait à compter les écritures deux fois. Les tokens facturés lors d’un passage à 12h appartiennent aux écritures et sont exclus de cached_tokens.

L’exemple de comptabilisation d’OpenAI se présente ainsi :

{
  "usage": {
    "input_tokens": 12000,
    "input_tokens_details": {
      "cached_tokens": 4000,
      "cache_write_tokens": 7000,
      "cache_write_tokens_details": {
        "ttl_30m_tokens": 3000,
        "ttl_12h_tokens": 4000
      }
    }
  }
}

Notons I la valeur de input_tokens, R celle de cached_tokens, et W30 et W12 les deux nombres de tokens écrits par TTL. Calculez l’entrée ordinaire avec U = I - R - W30 - W12 ; elle représente ici 1,000 tokens.

Pour un tarif d’entrée ordinaire P en USD pour 1M tokens et un multiplicateur de lecture du cache r :

Input cost = P × (U + r × R + 1.25 × W30 + 2.5 × W12) / 1,000,000

L’exemple hypothétique de la documentation, avec P = $1 et r = 0.1, donne :

(1000 + 4000 × 0.1 + 3000 × 1.25 + 4000 × 2.5) / 1000000 = $0.01515

Pour la même utilisation aux tarifs Standard de GPT-6.1 Sol, remplacez les valeurs par P = $2 et r = 0.05 : les frais d’entrée sont de $0.02990. Ajoutez séparément la sortie et les autres frais applicables. Ce calcul isole la facturation de l’entrée ; il n’estime pas le coût total d’une tâche de programmation achevée.

Consignez l’ID de la réponse, l’heure, le modèle, le service_tier réellement utilisé et ces nombres de tokens. Si un client omet la ventilation par TTL, examinez le JSON brut avant de calculer les coûts avec plusieurs durées ; l’absence de compteurs ne prouve pas qu’il n’y a aucune écriture. Additionnez les frais en dollars sur une journée représentative au lieu de choisir une politique à partir d’un seul pourcentage d’accès réussis au cache.

Enfin, 12h définit une durée minimale d’admissibilité au tarif de lecture du cache. Ce réglage ne fixe pas de date de suppression, ne modifie pas la politique de conservation maximale des données et ne garantit pas une latence plus faible à chaque requête.

Quelles différences avec Codex, Work et Anthropic ?

Distinguez la facturation de l’API des quotas des produits utilisés après connexion à un compte. Dans sa publication du 21 octobre 2026, Tibo Sottiaux a décrit comme permanent le cache des utilisateurs connectés à Codex et Work, en affirmant que le cache serait utilisé lors de la reprise d’anciennes conversations. Cette déclaration concerne les sessions de ces produits ; elle ne définit pas de TTL pour l’API et ne rend pas un abonnement illimité.

La documentation officielle des tarifs de Codex précise séparément que la facturation en crédits Codex ne prévoit pas de frais d’écriture en cache distincts, tandis que l’utilisation avec une clé API suit les tarifs de l’API. Si vous utilisez Codex avec une clé API, prévoyez votre budget selon les règles de l’API, sans y appliquer une promesse concernant les sessions connectées du produit.

Pour Claude, les options documentées au 2026-10-24 sont un cache de 5 minutes par défaut, avec des écritures à 1.25×, et un cache facultatif de 1 heure, avec des écritures à 2×. Les réductions de lecture varient selon le modèle : Claude Opus 5.5 et Sonnet 5.5 utilisent 0.05× ; les autres tarifs figurent dans la grille tarifaire d’Anthropic. Les lectures réussies renouvellent la durée sans nouvelle majoration d’écriture, et les requêtes à TTL mixtes imposent de placer les blocs de longue durée avant ceux de courte durée.

Pour des pauses répétées de plusieurs heures, testez d’abord la politique 12h d’OpenAI sur le préfixe stable si votre application utilise déjà un modèle compatible. Pour une session active en continu, commencez par le cache de plus courte durée. Comparer les fournisseurs exige leurs tarifs de base réels, le volume de sortie et le comportement observé du cache ; les durées et les multiplicateurs d’écriture ne suffisent pas à déterminer qui termine la tâche au moindre coût.