Guide des coûts GPT-5.6 : prompt caching à -90 %, reasoning effort

GPT-5.6 déplace les deux leviers de coût en même temps : l’input caché tombe à 10 % du tarif d’entrée (contre 50 % de réduction sur la 5.x), et comme le reasoning est activé par défaut, ne pas envoyer reasoning_effort a coûté 1,5x plus cher que de le fixer à none sur notre matrice de 50 appels, pour des réponses identiques. Côté entrée, vous pouvez maintenant fixer explicitement jusqu’à quatre cache breakpoints ; côté sortie, le bouton effort décide de la quantité de réflexion que vous payez. Nous avons mesuré les deux leviers à travers le gateway sur les modèles du jour J : Sol (5 $/30 $ par 1M de tokens in/out), Terra (2,50 $/15 $) et Luna (1 $/6 $), chaque tarif confirmé face au compteur usage.cost en direct.

TL;DR

• L’input caché est facturé à 10 % du tarif d’entrée, soit 0,10 $/0,25 $/0,50 $ par 1M mesurés selon les tiers ; la 5.x n’accordait que 50 % de réduction.
• Les breakpoints permettent une réutilisation partielle : modifier le bloc après un marqueur n’a refacturé que 1 210 tokens sur 2 431.
• Les préfixes de moins de 1 024 tokens ne sont jamais cachés et les répétitions peuvent rater sans le signaler ; prévoyez des taux de hit inférieurs à 100 %.
• Les écritures en cache sont facturées à 1,25x sur les tokens écrits ; une écriture jamais relue coûte plus cher que l’absence de cache.
• Omettre reasoning_effort a coûté 1,5x plus cher que none sur une matrice de 4 tâches, pour des réponses identiques ; fixez-le explicitement.

Mesuré le 10/07/2026 via le gateway Synthorai (chat completions compatibles OpenAI), un jour après l’annonce de la famille par OpenAI. Les trois modèles sont en ligne ; les nouveaux paramètres de caching passent tels quels.

Trois tiers, une génération

Le schéma de nommage change : le chiffre désigne la génération, et Sol, Terra et Luna sont des tiers de capacité qui remplacent les suffixes pro/mini/nano. Les trois partagent une fenêtre de contexte de 1M de tokens et 128K de sortie max. Tous les tarifs ci-dessous se réconcilient exactement avec le usage.cost mesuré sur des comptes de tokens connus, y compris la colonne cachée :

Sol est le modèle phare et le successeur à prix identique de gpt-5.5 : la grille tarifaire est la même, à 5 $/30 $. Terra et Luna sont les tiers réduits de la même génération, à la moitié et au cinquième du prix de Sol, prenant les places qu’occupaient les suffixes mini et nano. Pour le comptage des tokens, les trois ne font qu’un : tous ont renvoyé des comptes identiques sur chaque échantillon envoyé.

Le fonctionnement du caching 5.6, d’après la doc

Le caching de GPT reposait auparavant sur un seul comportement : l’API détectait toute seule les préfixes répétés de 1 024 tokens ou plus, et facturait la part mise en cache à moitié prix. C’est précisément pour ça que notre comparatif des providers rangeait la colonne GPT dans « entièrement automatique ». Le guide du caching 5.6 remplace ce modèle par une conception à deux modes :

{
  "model": "gpt-5.6-luna",
  "prompt_cache_options": { "mode": "explicit", "ttl": "30m" },
  "prompt_cache_key": "tenant-42",
  "messages": [
    {
      "role": "system",
      "content": [
        {
          "type": "text",
          "text": "...stable system prompt, 1024+ tokens...",
          "prompt_cache_breakpoint": { "mode": "explicit" }
        }
      ]
    },
    { "role": "user", "content": "the varying part" }
  ]
}

Les règles importantes, résumées à partir du guide :

• Un breakpoint marque la fin d’un préfixe mis en cache, ce qui couvre le bloc concerné et tout ce qui le précède. Le mode implicit (par défaut) place toujours automatiquement un breakpoint sur le dernier message ; le mode explicit ne met en cache que ce que vous marquez.
• Quatre écritures de cache par requête, et le breakpoint auto du mode implicite en consomme une. Il reste donc trois emplacements pour les marqueurs explicites en mode par défaut, et quatre en mode explicite. Les breakpoints des tours de conversation précédents sont en lecture seule sur les requêtes suivantes.
• Le seuil des 1 024 tokens reste en place : un préfixe marqué en dessous de ce seuil n’est pas mis en cache.
• ttl: "30m" est une durée de vie minimale garantie, pas un plafond (« au moins 30 minutes… peut être conservé plus longtemps »). Ce paramètre remplace prompt_cache_retention, qui est déprécié sur 5.6, et donc l’ancienne option de rétention étendue 24h disparaît avec lui.
• prompt_cache_key est le moyen d’obtenir un matching fiable : le guide recommande une clé stable par tenant ou par session pour router les répétitions vers le même cache, avec une limite souple d’environ 15 requêtes par minute et par clé. Les caches sont cantonnés à votre organisation.
• Les écritures de cache sont facturées à 1,25x le tarif d’entrée sur 5.6+, et reportées dans le nouveau champ usage.prompt_tokens_details.cache_write_tokens. Les écritures étaient gratuites sur 5.x et avant.

GPT-5.5 et les versions antérieures rejettent les nouveaux paramètres avec un 400 propre (prompt_cache_options is not supported on this model) : mettez donc en place un gating par version pour tout déploiement.

Si cette conception vous semble familière, c’est normal : les marqueurs sur les blocs de contenu, les quatre breakpoints, le surcoût sur les écritures et l’historique glissant en lecture seule, c’est exactement la forme qu’a toujours eue le cache_control de Claude. La différence, c’est le TTL : le plancher garanti de 30 minutes d’OpenAI vaut 6x les 5 minutes par défaut de Claude.

Ce que dit le compteur

La doc énonce des promesses ; voici ce que le compteur du gateway a effectivement renvoyé, sonde par sonde. Les enregistrements bruts complets sont dans le journal d’exécution ; chaque coût ci-dessous se réconcilie au chiffre près avec les tarifs par palier.

Trois de ces lignes méritent d’être détaillées.

La réutilisation partielle est réelle, et c’est la raison d’adopter les breakpoints. Avec un bloc A stable et une queue B remplacée, le compteur n’a refacturé que la queue : 1 212 tokens relus au tarif cache, 1 210 écrits pour le nouveau B à la prime d’écriture, sur un prompt de 2 431 tokens, et le total se réconcilie au chiffre près avec la grille tarifaire. C’est le comportement de préfixe en couches (system prompt, puis tools, puis documents, chacun marqué) autour duquel les utilisateurs de Claude structurent leurs prompts, et que le mode automatique de GPT ne pouvait jamais garantir. Une note : sur les répétitions complètes, la longueur correspondante retombe parfois sous la marque (1 897 sur une écriture de 2 422 tokens dans une sonde), donc prévoyez votre budget sur le tarif réduit, pas sur des correspondances exactes.

Le plancher et les échecs silencieux sont les pièges opérationnels. Un bloc marqué de 621 tokens n’a rien mis en cache, deux fois, sans erreur ni indice d’usage au-delà des zéros ; si votre « préfixe stable » est un court prompt système, vous payez plein tarif et rien ne vous en avertit. Et un échec peut survenir sans écriture, à plein tarif, tout aussi silencieusement. Le taux de succès est une distribution, pas une promesse, quel que soit le chemin emprunté par vos requêtes : lisez cached_tokens en production et alertez dessus, comme le fait notre audit de cache en cinq minutes.

La prime d’écriture est réelle, et elle change le seuil de rentabilité. Les tokens écrits sont facturés exactement à 1,25x le tarif d’input sur les trois paliers (Luna facture les écritures à 1,25 $ le million, Terra à 3,125 $, Sol à 6,25 $), se réconciliant au chiffre près sur chaque sonde de notre dernière exécution. Cette prime ne se rentabilise qu’une fois le préfixe relu : une écriture qui ne récolte jamais de hit coûte 25 % de plus que ne rien mettre en cache, le même piège qu’on avait mesuré sur la prime d’écriture de Claude dans le post LangChain. Marquez les préfixes dont vous savez qu’ils se répéteront, pas tout ce qui semble stable.

Le plancher de 30 minutes a tenu aussi loin que nous l’avons sondé. Une relecture avec clé 15 minutes après l’écriture est revenue entièrement en cache (1 313 tokens sur 1 313, se réconciliant au taux de 10 %), bien au-delà de l’ancien horizon en mémoire de 5 à 10 minutes, et un second sondage avec clé au même intervalle a reproduit le résultat. Nous n’avons pas sondé les 30 minutes complètes.

Le même workload sur GPT-5.5, pour comparer

La bonne base de comparaison, c’est le prix identique : Sol reprend exactement la grille tarifaire de gpt-5.5 (5 $/30 $), donc c’est le successeur direct, avec Terra et Luna comme paliers réduits en dessous. Même prix affiché, conditions de cache très différentes :

À prix affiché identique, les conditions de mise en cache constituent l’amélioration. Un préfixe de 3 000 tokens coûte $0.0075 par appel sur 5.5 lorsque son cache automatique décide de faire un hit, et $0.0015 sur Sol à chaud, soit 5x moins sur la part mise en cache. Le changement plus profond concerne le contrôle et la visibilité : les hits de 5.5 dépendent d’une détection de préfixe opaque que vous ne pouvez ni déclencher ni déboguer, tandis que 5.6 vous permet de marquer exactement ce qui doit être mis en cache, de router les répétitions avec une prompt_cache_key, et d’observer chaque écriture apparaître dans usage. Un miss se manifeste désormais par un zéro dans un champ que vous avez créé, et non par un silence. Le chemin de réduction se cumule par-dessus : si 5.5 sur-servait la charge de travail, Terra divise par deux toute la grille tarifaire et Luna la divise par cinq, et le même préfixe à chaud tombe à $0.00075 et $0.0003. La seule chose que 5.5 conserve, c’est la rétention optionnelle de 24 heures ; si votre trafic est un batch quotidien sur un préfixe géant, ce compromis joue en sens inverse. Et notez que le second levier joue en sens inverse lors de la migration : 5.6 raisonne par défaut, donc une charge de travail 5.5 transférée sans épingler reasoning_effort accumule de nouvelles dépenses de sortie sur la même grille tarifaire.

Le second levier : l’effort de raisonnement

Le cache pilote ce que vous payez à l’entrée ; reasoning_effort pilote le côté sortie, parce que les tokens de raisonnement sont facturés au tarif de sortie et, contrairement à votre préfixe, ne peuvent jamais être mis en cache. GPT-5.6 accepte les valeurs de none à xhigh sur tous les tiers. L’annonce de lancement introduit aussi un effort max pour Sol ; via les chat completions, il n’existe pas (400: 'reasoning_effort' does not support 'max' with this model, aussi bien sur Sol que sur Terra), donc xhigh est le plafond réel sur le chemin API qu’utilisent les gateways et les SDK.

On a fait tourner une matrice de 50 appels : quatre types de tâches (classer un avis, extraire un champ d’une ligne de log, un problème arithmétique à plusieurs étapes, une petite tâche de génération de code) sur les six réglages, de none à xhigh plus le paramètre omis, sur Terra et Luna avec un contrôle ponctuel sur Sol. Les 50 réponses étaient correctes, à chaque réglage. Ce qui variait, c’est la facture. Ce sont des appels à sortie courte (quelques dizaines de tokens visibles), donc quelques dizaines de tokens de raisonnement au tarif de sortie dominent le total ; la colonne du ratio compare le coût de l’appel entier :

Trois constats. Premièrement, 5.6 est adaptatif tout seul : sur les deux tâches triviales, aucun réglage n’a dépensé le moindre token de raisonnement, donc le bouton est gratuit dans ce cas. Deuxièmement, sur les tâches qui semblent mériter réflexion (math, code), le réglage par défaut raisonne même quand ça n’apporte rien : omettre le paramètre a coûté de 2,5x à 3,5x le prix de none sur les tâches math et code de Luna et la tâche math de Terra (la tâche code de Terra n’a dépensé aucun token par défaut, par hasard) pour les mêmes réponses correctes, et 1,5x de plus au total sur toute la grille Terra + Luna. Troisièmement, les réglages intermédiaires (pas montrés dans le tableau) sont du bruit, pas une molette : la tâche math de Terra a dépensé 19 tokens de raisonnement à low, zéro à medium, 21 à high, et de nouveau zéro à xhigh, et la tâche code de Luna a dépensé 101 tokens à xhigh contre 41 à high. Les noms sont des intentions, pas des budgets : le même comportement qu’on a mesuré sur GLM 5.2.

Envoyez reasoning_effort explicitement à chaque appel, avec none par défaut pour la classification, l’extraction, le routage et les transformations courtes. Ne relevez le réglage sur un point d’appel précis que lorsque vos évals montrent que le réglage supérieur change le résultat, pas parce que la tâche vous paraît difficile. Nos quatre types de tâches sont des charges API à sortie courte ; un vrai travail multi-étapes difficile peut justifier sa dépense de raisonnement, mais laissez les mesures le dire.

Les deux leviers se cumulent. Une fois un préfixe chaud, le côté entrée d’un appel Luna coûte un dixième du prix catalogue, et le raisonnement par défaut devient le plus gros poste restant sur les tâches courtes : l’appel math de Luna coûtait 0,00007 $ au total à none et 0,00025 $ avec le paramètre omis. Le raisonnement par défaut à lui seul a ajouté 0,00018 $, soit plus du double de l’appel managé entier. Mettez en cache sans fixer l’effort et les économies repartent par l’autre bout.

Quoi recommander selon la charge

La décision a maintenant une vraie structure. Voici ce qu’on dit aux clients du gateway :

Indépendamment de la forme : envoyez une prompt_cache_key stable par locataire ou session (la documentation fait de cette clé la base d’une correspondance fiable), maintenez chaque couche marquée au-dessus du seuil de 1 024 tokens, et surveillez cached_tokens car des échecs silencieux existent. N’oubliez pas que les caches sont propres à chaque modèle : un test A/B entre différents niveaux se réchauffe à partir de zéro de chaque côté. Et réglez l’autre levier dans le même commit : fixez reasoning_effort selon la matrice ci-dessus, none sauf si une évaluation indique le contraire.

Sur le choix du tier, la remise de 90 % change plus l’arithmétique que le tier lui-même. Une charge qui rejoue un préfixe de 3 000 tokens paie environ 0,30 $ par millier d’appels pour ce préfixe sur du trafic Luna chaud, et 1,50 $ sur du Sol chaud ; l’écart entre tiers sur la part cachée est plus faible que l’écart sur les tokens de sortie. Choisis donc le tier pour la qualité de sortie et le prix, puis laisse le caching aplatir le côté entrée. En venant de gpt-5.5, Sol est la mise à niveau directe au même tarif, avec des lectures de cache 5x moins chères et le contrôle du moment où elles se produisent ; descends vers Terra ou Luna là où tes évals disent que le tier plus petit tient, et le tarif est divisé par deux ou par cinq en plus.

Le tokenizer n’a pas changé

Nos 24 échantillons (un passage narratif en neuf langues, des versions technique et actualités dans six d’entre elles, une fonction Python et un tool-call JSON) sont comptés à l’identique par GPT-5.5, Sol, Terra et Luna dans toutes les comparaisons qui ont abouti. Les budgets de tokens et les estimations de plancher de cache calibrés sur 5.5 restent valables tels quels ; le comportement inter-langues est détaillé dans notre article sur le tokenizer par langue et s’applique à 5.6 en l’état.

L’essentiel

• La remise de cache qui passe de 50 % à 90 %, avec un TTL garanti de 30 minutes, c’est la vraie baisse de prix de cette version ; les prix des tiers font le titre, mais ce sont les conditions de caching qui font bouger les factures réelles.
• Adopte les breakpoints explicites pour les prompts en couches : la réutilisation partielle est mesurée, pas théorique, et le modèle mental se transpose depuis Claude à l’identique.
• Respecte le plancher de 1 024 tokens, envoie un prompt_cache_key et surveille cached_tokens ; les miss silencieux comme le non-caché-du-tout silencieux existent tous les deux.
• Envoie reasoning_effort explicitement, avec none par défaut : le défaut non géré a facturé 1,5x plus sur toute notre matrice, jusqu’à 3,5x sur des tâches uniques, pour des réponses identiques.
• xhigh est le plafond atteignable (max à 400s via chat completions) ; pas de re-calibrage du tokenizer par rapport à 5.5.

FAQ

GPT-5.6 gère-t-il le prompt caching explicite comme Claude ? Oui. On utilise prompt_cache_options: {"mode": "explicit"} avec des marqueurs prompt_cache_breakpoint sur les blocs de contenu, jusqu’à quatre écritures par requête (trois en mode implicite, où le breakpoint automatique consomme un emplacement). Mesuré via un gateway compatible OpenAI : un préfixe marqué de 3 012 tokens s’est écrit au premier appel et a été relu intégralement au tarif cache au second.

Combien coûte l’input mis en cache sur GPT-5.6 ? 10 % du tarif input, vérifié sur les trois tiers : 0,10 $ le million sur Luna, 0,25 $ sur Terra, 0,50 $ sur Sol. GPT-5.x facturait les tokens en cache à 50 % de l’input, donc le tarif cache est 5 fois plus bas sur la 5.6.

Le caching de GPT-5.6 est-il meilleur que celui de GPT-5.5 ? Sur la profondeur de réduction et le contrôle, oui : tarif cache à 10 % contre 50 %, quatre breakpoints explicites contre une détection automatique seule que vous ne pouvez ni déclencher ni déboguer, et un plancher de 30 minutes avec clé contre 5-10 minutes au mieux. Le seul avantage restant de la 5.5 est le tier de rétention optionnel à 24 heures, que la 5.6 supprime.

Combien de temps le cache de GPT-5.6 reste-t-il actif ? La documentation garantit au moins 30 minutes (ttl: "30m" est la seule valeur acceptée), voire davantage ; l’option remplace le paramètre déprécié prompt_cache_retention, y compris l’ancien palier étendu de 24 heures. Lors de nos tests, les relectures indexées 15 minutes après l’écriture ont été des succès complets ; nous n’avons pas testé les 30 minutes complètes.

Ai-je besoin de prompt_cache_key ? Envoyez-le : la documentation fait d’une clé stable par locataire ou session la base d’une correspondance fiable sur 5.6, avec une limite souple d’environ 15 requêtes par minute par clé. Son inclusion ne coûte rien, et son association avec la surveillance de cached_tokens est la façon de vérifier que la remise s’applique réellement.

Quel impact reasoning_effort a-t-il sur le coût de GPT-5.6 ? Sur notre matrice de 50 appels (quatre types de tâches, six réglages, Terra et Luna), chaque réglage a produit des réponses correctes. Omettre le paramètre a facturé 1,5 fois plus que none globalement, jusqu’à 3,5 fois sur la tâche arithmétique. Sur les tâches triviales (classification, extraction), aucun réglage n’a consommé de reasoning tokens. Fixez none et n’augmentez qu’en fonction de vos evals.

Le reasoning effort maximum est-il disponible sur GPT-5.6 Sol ? Pas via les chat completions. Les requêtes avec reasoning_effort: "max" renvoient un 400 listant les valeurs de none à xhigh, aussi bien sur Sol que sur Terra.

Quel tier GPT-5.6 choisir pour une charge de travail API ? Sol est le successeur de gpt-5.5 à prix identique (même grille à 5 $/30 $, lectures en cache 5 fois moins chères) ; Terra et Luna sont les tiers réduits, à la moitié et au cinquième de ce tarif. Une fois votre préfixe stable et associé à une clé, la réduction de 90 % sur le cache aplatit le coût de l’input. Descendez donc aussi bas que vos evals de qualité de sortie le permettent, et laissez le tier fixer le prix de la sortie.

← Retour au blog