Mise en cache des prompts GPT-6 : 90 % de réduction sur les lectures en cache et comment réellement exploiter le cache

Chaque boucle d'agent que vous exécutez renvoie le même préambule. Le prompt système, les définitions d'outils, la spécification OpenAPI, les conventions du dépôt. Le modèle a déjà vu ce préfixe une centaine de fois aujourd'hui, et vous avez payé le tarif d'entrée complet à chaque fois.

Essayez Apidog dès aujourd'hui

Quand on passe à l'échelle, l'addition devient assourdissante. OpenAI affirme que son chercheur médian dépense plus de 600 $ par jour en agents de codage, et que le 90ᵉ centile dépasse 7 000 $ par jour. Ce sont des personnes qui exécutent les outils internes d'un seul laboratoire, pas une API de production servant des clients.

En même temps que GPT-6 Sol et GPT-6 Luna, le 22 septembre 2026, OpenAI a livré une version de la mise en cache des prompts qui s'attaque exactement à ce problème. Les lectures d'entrée mises en cache bénéficient d'une remise de 90 %, les taux de succès sont plus élevés par défaut, deux des modifications qui cassaient le cache le plus souvent ne le cassent plus, vous pouvez placer des points d'arrêt explicites, et il existe désormais un Prompt Caching Dashboard ainsi qu'un outil de diagnostic pour voir ce qui se passe réellement. GitHub, qui l'utilise en production, rapporte plus de 50 % de jetons de prompt en moins nécessitant un traitement nouveau sur des milliards de requêtes.

Ce guide couvre ce qui a changé, ce que vaut la remise en argent réel, comment organiser un prompt pour que le cache soit réellement sollicité, et comment vérifier qu'il continue de l'être après que quelqu'un a refactorisé votre prompt système.

Ce qui a été livré

Changement	Ce que cela signifie pour votre code
Remise de 90 % sur les lectures d'entrée mises en cache	Le préfixe répété est facturé au dixième du tarif d'entrée
Taux de succès plus élevés par défaut	Les intégrations existantes en bénéficient en partie sans modification de code
Modifier l'effort de raisonnement ne casse plus le cache	Vous pouvez passer de low à max en cours de session et garder le préfixe chaud
Modifier la disponibilité des outils ne casse plus le cache	Ajoutez ou retirez un outil sans payer pour un préfixe froid
Points d'arrêt explicites	Vous décidez où se termine le préfixe mis en cache au lieu de deviner
Prompt Caching Dashboard et un outil de diagnostic	Le taux de succès devient quelque chose que vous mesurez, pas quelque chose que vous supposez

Les trois premiers points comptent le plus pour les agents. Le dernier compte le plus pour l'ingénieur qui doit expliquer la facture du mois dernier.

L'arithmétique

La mise en cache des prompts ne touche que les jetons d'entrée. Le tarif de sortie ne bouge pas, donc un agent qui rédige de longues réponses à partir d'un prompt court ne le remarquera presque pas. Un agent qui lit un grand contexte stable et émet un verdict court le remarquera beaucoup.

Voici ce que la remise fait aux tarifs publiés pour les deux nouveaux modèles :

Modèle	Entrée pour 1 M	Lecture en cache pour 1 M	Sortie pour 1 M	Contexte
GPT-6 Sol (gpt-6-sol)	$2.00	$0.20	$10.00	872k
GPT-6 Luna (gpt-6-luna)	$0.10	$0.01	$0.50	1M

La colonne des lectures en cache correspond à la remise de 90 % appliquée au tarif d'entrée publié. Vérifiez-la sur la page de tarification en direct avant de bâtir un budget dessus.

Prenons maintenant une charge de travail concrète. Disons que vous exécutez un agent de revue de code : 40 000 jetons de préfixe stable (prompt système, schémas d'outils, document OpenAPI du service, vos conventions d'API) plus environ 2 000 jetons de diff par exécution, 500 exécutions par jour.

	Sol, aucun succès de cache	Sol, préfixe mis en cache	Luna, aucun succès de cache	Luna, préfixe mis en cache
Jetons de préfixe par jour	20M à $2.00 = $40.00	20M à $0.20 = $4.00	20M à $0.10 = $2.00	20M à $0.01 = $0.20
Jetons frais par jour	1M à $2.00 = $2.00	1M à $2.00 = $2.00	1M à $0.10 = $0.10	1M à $0.10 = $0.10
Coût d'entrée quotidien	$42.00	$6.00	$2.10	$0.30

Cela représente environ 86 % de réduction sur la facture d'entrée avec Sol, pour une charge de travail dont la forme n'a pas changé du tout. La seule chose qui a changé est de savoir si le préfixe est resté identique octet pour octet entre les appels.

À mettre en regard : Claude Opus 5.5 affiche des lectures en cache à $0.20 par million contre $4.00 en entrée, avec des écritures de cache à $5.00 par million. Le prix de lecture tombe au même niveau que celui de Sol, et Anthropic facture une prime explicite pour écrire le cache. Le lancement d'OpenAI n'indique pas de tarif d'écriture de cache pour Sol ou Luna, ce qui constitue l'une des questions ouvertes à la fin de cet article. Si vous comparez des factures complètes plutôt que des chiffres isolés, notre analyse de la guerre des prix des modèles de septembre 2026 réunit les trois lancements dans un seul tableau.

Pourquoi les échecs de cache étaient généralement de votre faute

La mise en cache des prompts s'appuie sur un préfixe. Le cache est indexé sur la série initiale de jetons de votre requête, donc le premier octet qui diffère de l'appel précédent invalide tout ce qui suit. Un seul caractère au mauvais endroit vous coûte toute la remise sur les 40 000 jetons. Les coupables classiques, dans l'ordre approximatif de leur fréquence dans du code réel :

• Un horodatage, un ID de requête ou un ID de trace injecté dans le prompt système.
• Le nom de l'utilisateur, l'ID d'organisation ou la locale placés au-dessus des instructions statiques plutôt qu'en dessous.
• Le contexte récupéré inséré avant les définitions d'outils, de sorte que chaque nouvelle récupération décale tout le préfixe.
• Un tableau d'outils construit à partir d'un ensemble ou d'un dictionnaire, de sorte que l'ordre des clés JSON change d'un processus à l'autre.
• Des exemples few-shot permutés à chaque requête pour varier.

Deux autres éléments figuraient sur cette liste et n'y sont plus. Modifier l'effort de raisonnement ne casse plus le cache, donc un agent qui tourne en low sur les tours faciles et passe à max sur le tour difficile conserve son préfixe chaud pendant l'escalade. Modifier la disponibilité des outils ne le casse plus non plus, donc conditionner un outil dangereux à une vérification de permission ne force plus une lecture à froid de tout ce qui précède. Ces deux schémas sont extrêmement courants dans les frameworks d'agents et, jusqu'à présent, ils annulaient silencieusement le cache exactement sur les tours qui coûtaient le plus cher.

Organisez le [REDACTED PROMPT]

Cette discipline survivra à tous les changements de tarification à venir : triez votre contexte selon sa fréquence de changement, le plus stable en haut.

1. Les instructions système ou développeur, identiques pour chaque utilisateur.
2. Les schémas d'outils et de fonctions, sérialisés dans un ordre fixe.
3. Le matériel de référence long et partagé : le document OpenAPI, le guide de style, le schéma de base de données.
4. Le contexte par locataire ou par projet, qui change rarement.
5. Les fragments récupérés, qui changent à chaque requête.
6. Le tour de l'utilisateur et tout ce qui contient une horloge.

Les couches un à trois constituent votre cache. Si un horodatage doit figurer dans le prompt, placez-le dans le tour de l'utilisateur, pas dans le message système. Si votre liste d'outils est assemblée dynamiquement, triez-la et figez l'ordre des clés JSON pour que deux processus la sérialisent de façon identique.

from openai import OpenAI

client = OpenAI()

STATIC_PREFIX = [
    {"role": "developer", "content": SYSTEM_INSTRUCTIONS},   # never changes
    {"role": "developer", "content": OPENAPI_DOCUMENT},      # changes on deploy
]

response = client.responses.create(
    model="gpt-6-sol",
    reasoning={"effort": "low"},
    tools=SORTED_TOOL_SCHEMAS,
    prompt_cache_key="review-agent:v7",
    input=STATIC_PREFIX + [
        {"role": "user", "content": f"Review this diff:\n{diff}"},  # volatile, last
    ],
)

print(response.usage)

Les points d'arrêt explicites de cette version vous permettent de marquer où se termine ce préfixe mis en cache plutôt que de compter sur la plateforme pour le déduire. C'est particulièrement utile lorsque la couche quatre est volumineuse : un bloc par locataire, stable pour un client et différent pour le suivant, où vous voulez que la frontière soit tracée délibérément plutôt qu'au niveau du jeton choisi par l'heuristique.

Versionnez la clé de cache elle-même, comme dans review-agent:v7 ci-dessus. Lorsque vous modifiez le préfixe volontairement, incrémentez la version, et vous verrez la période froide dans vos métriques au lieu de vous demander pourquoi les coûts ont bondi.

Vérifiez-le, ne le supposez pas

L'objet usage présent dans chaque réponse vous indique combien de jetons d'entrée ont été servis depuis le cache. Lisez-le, journalisez-le et déclenchez des alertes dessus. En voici une forme approximative :

usage = response.usage
cached = usage.input_tokens_details.cached_tokens
total_in = usage.input_tokens

print(f"cache hit rate: {cached / total_in:.0%}  billed fresh: {total_in - cached}")

Les noms de champs dans les extraits ci-dessus proviennent des structures actuelles de l'API OpenAI plutôt que de l'annonce de lancement, donc vérifiez-les dans la référence avant de livrer. Le principe ne change pas : la réponse vous dit la vérité, alors mettez ce chiffre sur un tableau de bord.

Le nouveau Prompt Caching Dashboard et l'outil de diagnostic offrent une vue au niveau du parc, et c'est là que vous repérerez le schéma rapporté par GitHub : plus de 50 % des jetons de prompt qui n'ont plus besoin d'un traitement nouveau sur des milliards de requêtes. Il s'agit d'une mesure à l'échelle de la plateforme, et le seul moyen de connaître votre propre chiffre est de le mesurer.

Le mode de défaillance est silencieux. Aucune erreur ne se produit quand le cache cesse de fonctionner. Un collègue ajoute un ID de requête au prompt système pour déboguer, le préfixe refroidit, et le seul signal est une ligne qui grimpe lentement sur la facture, trois semaines plus tard.

C'est ce qui en fait un test de non-régression, pas un problème de supervision. Traitez le point de terminaison du modèle comme n'importe quelle autre API dont vous dépendez : enregistrez la requête dans Apidog, vérifiez que usage.input_tokens_details.cached_tokens dépasse un seuil lors du deuxième appel d'un scénario, et exécutez-le selon un calendrier dans la CI. Deux appels successifs, un pour chauffer et un pour vérifier, constituent tout le test ; et une refactorisation du prompt qui tue le cache échoue alors sur la pull request au lieu d'échouer sur la facture.

La note de bas de page sur la latence

La mise en cache réduit le travail effectué avant le premier jeton, donc elle améliore généralement le temps jusqu'au premier jeton en plus du coût. N'attendez pas d'elle qu'elle sauve les modes de raisonnement.

Artificial Analysis, un tiers indépendant, mesure un temps jusqu'au premier jeton de 102,15 secondes pour GPT-6 Sol et de 124,23 secondes pour GPT-6 Luna sur leurs variantes de raisonnement « max ». Ce ne sont pas les chiffres que vous verrez avec un effort low, et ce ne sont pas des chiffres du fournisseur, alors considérez-les comme indicatifs. Le constat tient dans tous les cas : aucune remise de mise en cache ne transforme un budget de réflexion de deux minutes en échange interactif. Mesurez la latence pour chaque niveau d'effort avant de promettre un temps de réponse. Notre guide de l'API GPT-6 Astra détaille les niveaux d'effort.

Ce à quoi le lancement ne répond pas

Quatre points méritent d'être confirmés avant d'engager une conception sur cette base :

• Si les écritures de cache sont facturées sur Sol et Luna, et à quel tarif.
• Combien de temps un préfixe mis en cache survit sans trafic, et si les contrôles de rétention de l'époque GPT-5.6 sont repris sans changement.
• Si le tarif de lecture en cache de GPT-6 Astra est passé à la même remise de 90 %, étant donné que le matériel de lancement couvre les nouveaux modèles.
• Le nom exact du paramètre pour les points d'arrêt explicites, que l'annonce décrit par capacité plutôt que par champ.

Aucun d'eux ne bloque le travail d'organisation. L'ordonnancement « stable d'abord », une clé de cache versionnée et une assertion sur les jetons mis en cache sont payants quelle que soit la réponse.

La version courte

Triez votre prompt par volatilité et gardez l'horloge hors du message système. Versionnez la clé de cache pour que les changements volontaires soient visibles. Lisez cached_tokens sur chaque réponse et fixez un seuil plancher en CI. Faites monter l'effort de raisonnement et activez ou désactivez les outils librement désormais, car ni l'un ni l'autre ne vous coûte le préfixe. Pour en savoir plus sur le mécanisme lui-même, notre article explicatif sur le fonctionnement de la mise en cache des prompts couvre les fondamentaux.

La tarification de ces modèles bougera encore. C'est toujours le cas. La discipline d'organisation du prompt est la partie qui continue de rapporter après que le prochain lancement a réinitialisé tous les chiffres du tableau.