Coûts GPT-5.6 : 90 % de remise, prompt caching et reasoning effort

GPT-5.6 agit sur les deux leviers de coût à la fois : l’input en cache passe à 10 % du tarif normal, contre une remise de 50 % sur la gamme 5.x. Le raisonnement étant activé par défaut, ne pas envoyer reasoning_effort a coûté 1.5x plus cher que le fixer à none sur notre matrice de 50 appels, pour des réponses identiques. Côté input, vous pouvez désormais définir explicitement jusqu’à quatre breakpoints de cache. Côté output, le niveau d’effort détermine la quantité de raisonnement facturée. Nous avons mesuré ces deux leviers via la gateway sur les modèles disponibles dès le lancement : Sol ($5/$30 par million de tokens en entrée/sortie), Terra ($2.50/$15) et Luna ($1/$6). Chaque tarif a été vérifié avec le compteur usage.cost en production.

TL;DR

• L’input en cache est facturé à 10 % du tarif normal, soit $0.10/$0.25/$0.50 par million selon le tier ; la gamme 5.x appliquait une remise de 50 %.
• Les breakpoints permettent une réutilisation partielle : après modification du bloc situé après un marqueur, seuls 1,210 tokens sur 2,431 ont été refacturés.
• Les préfixes de moins de 1,024 tokens ne sont jamais mis en cache, et les répétitions peuvent rater le cache sans aucun signal ; prévoyez un taux de hit inférieur à 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.
• Sur une matrice de 4 tâches, omettre reasoning_effort a coûté 1.5x plus cher que none, pour des réponses identiques ; fixez-le explicitement.

Mesures réalisées le 2026-07-10 via la gateway Synthorai avec des chat completions compatibles OpenAI, un jour après l’annonce de la gamme par OpenAI. Les trois modèles sont disponibles, et les nouveaux paramètres de cache sont transmis tels quels.

Trois tiers, une seule génération

La nomenclature change : le numéro désigne la génération, tandis que Sol, Terra et Luna correspondent aux niveaux de capacité qui remplacent les suffixes pro/mini/nano. Les trois modèles partagent une fenêtre de contexte de 1M tokens et une sortie maximale de 128K. Tous les tarifs ci-dessous correspondent exactement aux valeurs de usage.cost relevées pour des nombres de tokens connus, y compris la colonne du cache :

Sol est le modèle haut de gamme et succède à gpt-5.5 au même prix : la grille reste identique à $5/$30. Terra et Luna sont les versions allégées de la même génération, facturées respectivement à la moitié et au cinquième du prix de Sol. Elles occupent les créneaux auparavant associés aux suffixes mini et nano. Pour le comptage des tokens, les trois se comportent comme un seul modèle : chaque échantillon envoyé a produit des nombres identiques.

Fonctionnement du cache sur 5.6 selon la documentation

Jusqu’ici, le cache de GPT reposait sur un seul mécanisme : l’API détectait automatiquement les préfixes répétés d’au moins 1,024 tokens et facturait la partie en cache à moitié prix. C’est précisément pour cela que notre comparatif des mécanismes de cache par fournisseur classait GPT dans la catégorie « entièrement automatique ». Le guide du cache de 5.6 remplace ce fonctionnement par 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" }
  ]
}

Voici les règles à retenir, condensées à partir du guide :

• Un breakpoint marque la fin d’un préfixe mis en cache. Il couvre le bloc concerné et tout ce qui le précède. Le mode implicit, utilisé par défaut, place toujours automatiquement un breakpoint sur le dernier message. En mode explicit, seuls les éléments marqués sont mis en cache.
• Quatre écritures en cache sont autorisées par requête. Le breakpoint automatique du mode implicite en consomme une, ce qui laisse trois emplacements aux marqueurs explicites dans ce mode, contre quatre en mode explicite. Les breakpoints des tours précédents de la conversation sont en lecture seule lors des requêtes suivantes.
• Le seuil de 1,024 tokens reste en vigueur : un préfixe marqué mais plus court n’est pas mis en cache.
• ttl: "30m" garantit une durée de vie minimale, pas maximale (« au moins 30 minutes… peut être conservé plus longtemps »). Ce paramètre remplace prompt_cache_retention, désormais déprécié sur 5.6. L’ancienne option de rétention étendue 24h disparaît donc avec lui.
• prompt_cache_key permet d’obtenir des correspondances fiables. Le guide recommande une clé stable par tenant ou par session afin de router les répétitions vers le même cache, avec une limite indicative d’environ 15 requêtes par minute et par clé. Les caches sont isolés au niveau de votre organisation.
• Les écritures en cache sont facturées à 1.25x le tarif d’input sur 5.6 et versions ultérieures. Elles apparaissent dans le nouveau champ usage.prompt_tokens_details.cache_write_tokens. Les écritures étaient gratuites sur 5.x et les versions précédentes.

GPT-5.5 et les modèles antérieurs rejettent ces nouveaux paramètres avec une erreur 400 explicite (prompt_cache_options is not supported on this model). Conditionnez donc leur activation à la version du modèle.

Ce fonctionnement reprend celui de cache_control chez Claude : marqueurs sur les blocs de contenu, quatre breakpoints, surcoût à l’écriture et historique glissant en lecture seule. La différence porte sur le TTL : le minimum garanti de 30 minutes d’OpenAI est 6x plus long que les 5 minutes par défaut de Claude.

Ce que renvoie le compteur

La documentation décrit le comportement attendu. Voici ce que le compteur de la gateway a effectivement renvoyé, test après test. Les données brutes complètes figurent dans le journal d’exécution. Chaque coût ci-dessous correspond exactement aux tarifs du tier concerné.

Trois de ces résultats méritent plus de détails.

La réutilisation partielle fonctionne réellement, et justifie à elle seule l’adoption des breakpoints. Avec un bloc A stable et une fin B remplacée, le compteur n’a refacturé que cette dernière : sur un prompt de 2,431 tokens, 1,212 tokens ont été relus au tarif du cache et 1,210 ont été écrits pour le nouveau bloc B avec le surcoût d’écriture. Le total correspond exactement à la grille tarifaire. C’est le comportement de préfixes en couches autour duquel les utilisateurs de Claude structurent leurs prompts : system prompt, puis tools, puis documents, chacun avec son marqueur. Le mode automatique de GPT ne permettait pas de le garantir. Nuance : lors de répétitions complètes, la longueur reconnue peut parfois s’arrêter avant le marqueur. Sur un test, 1,897 tokens seulement ont été reconnus sur une écriture de 2,422 tokens. Basez donc vos budgets sur le tarif remisé, pas sur un nombre exact de tokens reconnus.

Le seuil minimal et les cache misses silencieux sont les principaux pièges en production. Un bloc marqué de 621 tokens n’a rien mis en cache lors de deux appels successifs. Aucun message d’erreur ni autre indice que les valeurs à zéro dans les données d’usage. Si votre « préfixe stable » se résume à un system prompt court, vous payez plein tarif sans en être averti. De même, un cache miss peut être facturé plein tarif sans déclencher d’écriture ni produire d’erreur. Le taux de hit est une distribution, pas une garantie, quel que soit le chemin emprunté par les requêtes. Lisez cached_tokens en production et configurez des alertes, comme dans notre audit d’un cache de cinq minutes.

Le surcoût d’écriture est bien réel et modifie le seuil de rentabilité. Les tokens écrits sont facturés exactement à 1.25x le tarif d’input sur les trois tiers : $1.25 par million sur Luna, $3.125 sur Terra et $6.25 sur Sol. Tous les tests de notre exécution finale correspondent exactement à ces montants. Ce surcoût n’est amorti qu’après une nouvelle lecture du préfixe. Une écriture qui ne produit jamais de hit coûte 25 % plus cher que l’absence totale de cache. Nous avions mesuré le même piège avec le surcoût d’écriture de Claude dans notre article sur LangChain. Ne marquez que les préfixes dont vous savez qu’ils seront réutilisés, pas tout ce qui semble stable.

Le minimum de 30 minutes a tenu sur toute la durée de nos tests. Une relecture avec clé, effectuée 15 minutes après l’écriture, a été intégralement servie depuis le cache : 1,313 tokens sur 1,313, facturés au tarif de 10 %. C’est bien au-delà de l’ancienne durée en mémoire de 5 à 10 minutes. Un second test avec clé et le même délai a donné le même résultat. Nous n’avons pas testé les 30 minutes complètes.

Comparaison avec la même charge sur GPT-5.5

La comparaison pertinente se fait à prix égal : Sol reprend exactement la grille tarifaire de gpt-5.5 ($5/$30). Il s’agit donc de son successeur direct, tandis que Terra et Luna constituent les tiers plus économiques. Le prix affiché reste le même, mais les conditions du cache changent fortement :

À prix catalogue identique, l’amélioration vient des conditions du cache. Sur 5.5, un préfixe de 3,000 tokens coûte $0.0075 par appel lorsque le cache automatique produit un hit. Sur Sol déjà chaud, il coûte $0.0015, soit 5x moins pour la partie mise en cache. Le changement le plus profond concerne le contrôle et la visibilité. Sur 5.5, les hits dépendent d’une détection opaque des préfixes, qu’il est impossible de déclencher ou de déboguer. Sur 5.6, vous marquez précisément ce qui doit être mis en cache, vous routez les répétitions avec prompt_cache_key et vous observez chaque écriture dans usage. Un échec apparaît désormais comme un zéro dans un champ que vous avez activé, plutôt que de rester totalement invisible. Il reste ensuite possible de descendre en gamme : si 5.5 était surdimensionné pour la charge, Terra divise toute la grille tarifaire par deux et Luna par cinq. Le même préfixe chaud passe alors à $0.00075 et $0.0003. GPT-5.5 conserve toutefois la rétention optionnelle de 24 heures. Pour un traitement batch quotidien utilisant un préfixe très volumineux, ce compromis peut rester avantageux. Enfin, le second levier peut augmenter les coûts lors d’une migration : 5.6 raisonne par défaut. Une charge 5.5 migrée sans fixer reasoning_effort génère donc de nouveaux coûts d’output malgré une grille tarifaire identique.

Le second levier : reasoning effort

Le cache détermine le coût de l’input. reasoning_effort agit sur l’output, car les tokens de raisonnement sont facturés au tarif de sortie et ne peuvent jamais être mis en cache, contrairement au préfixe. GPT-5.6 accepte tous les niveaux de none à xhigh sur les trois tiers. L’annonce de lancement mentionne également un niveau max pour Sol, mais il n’est pas disponible via les chat completions (400: 'reasoning_effort' does not support 'max' with this model, sur Sol comme sur Terra). xhigh est donc le maximum utilisable par les gateways et les SDKs via cette API.

Nous avons exécuté une matrice de 50 appels : quatre types de tâches, classification d’un avis, extraction d’un champ dans une ligne de log, problème arithmétique en plusieurs étapes et petite tâche de génération de code, avec les six réglages de none à xhigh, plus l’omission du paramètre. Les tests ont porté sur Terra et Luna, avec une vérification ponctuelle sur Sol. Les 50 réponses étaient correctes, quel que soit le réglage. Seule la facture variait. Les sorties visibles de ces appels sont courtes, de l’ordre de quelques dizaines de tokens. Quelques dizaines de tokens de raisonnement facturés au tarif d’output dominent donc rapidement le coût total. La dernière colonne compare le coût de l’appel complet :

Trois constats se dégagent. Premièrement, 5.6 adapte seul son comportement : sur les deux tâches triviales, aucun réglage n’a consommé le moindre token de raisonnement. Le paramètre ne coûte donc rien dans ces cas. Deuxièmement, pour les tâches qui semblent nécessiter une réflexion, calcul et code, le comportement par défaut raisonne même lorsque cela n’améliore pas le résultat. Sur Luna, pour le calcul et le code, ainsi que sur Terra pour le calcul, omettre le paramètre a coûté entre 2.5x et 3.5x le prix de none, pour les mêmes réponses correctes. Le test de code sur Terra n’a, lui, consommé aucun token de raisonnement avec le réglage par défaut. Au total, le coût sur la grille Terra et Luna était 1.5x plus élevé. Troisièmement, les niveaux intermédiaires, absents du tableau, produisent du bruit plutôt qu’une progression régulière. Pour le calcul sur Terra, nous avons relevé 19 tokens de raisonnement avec low, zéro avec medium, 21 avec high, puis de nouveau zéro avec xhigh. Pour le code sur Luna, xhigh en a consommé 101 contre 41 avec high. Ces noms indiquent une intention, pas un budget, comme nous l’avions déjà mesuré sur GLM 5.2.

Envoyez explicitement reasoning_effort à chaque appel et utilisez none par défaut pour la classification, l’extraction, le routage et les transformations courtes. N’augmentez le niveau sur un call site précis que si vos evals montrent une amélioration des résultats, pas simplement parce que la tâche semble difficile. Nos quatre types de tâches correspondent à des appels API aux sorties courtes. Un travail réellement complexe et multi-étapes peut justifier ce coût de raisonnement, mais laissez les mesures en décider.

Les deux leviers se cumulent. Une fois le préfixe chaud, l’input d’un appel Luna coûte un dixième du tarif catalogue. Sur les tâches courtes, le raisonnement par défaut devient alors le principal poste restant : l’appel de calcul sur Luna a coûté $0.00007 au total avec none, contre $0.00025 lorsque le paramètre était omis. Le comportement par défaut a ajouté à lui seul $0.00018, soit plus de deux fois le coût total de l’appel maîtrisé. Utiliser le cache sans fixer le niveau d’effort revient à perdre une partie des économies sur l’autre versant.

Recommandations selon le type de charge

Le choix dépend désormais clairement de la structure de la charge. Voici nos recommandations aux clients de la gateway :

Quelle que soit la forme de la charge, envoyez un prompt_cache_key stable par tenant ou par session. La documentation en fait 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 cache misses silencieux existent. Les caches sont propres à chaque modèle : un test A/B entre tiers repart de zéro et réchauffe séparément le cache de chaque côté. Configurez aussi l’autre levier dans le même commit : fixez reasoning_effort selon la matrice ci-dessus, à none sauf si une eval justifie un niveau supérieur.

La remise de 90 % pèse davantage dans le calcul que le choix du tier. Pour une charge rejouant un préfixe de 3,000 tokens, ce préfixe coûte environ $0.30 par millier d’appels sur Luna déjà chaud, contre $1.50 sur Sol. L’écart entre les tiers est plus faible sur la partie en cache que sur les tokens d’output. Choisissez donc le tier selon la qualité de sortie et son prix, puis laissez le cache réduire le coût de l’input. Si vous venez de gpt-5.5, Sol constitue une mise à niveau directe au même tarif, avec des lectures du cache 5x moins chères et un contrôle explicite de leur déclenchement. Passez ensuite à Terra ou Luna si vos evals montrent que le tier inférieur reste suffisant : la grille est alors divisée par deux ou par cinq en plus de la remise liée au cache.

Le tokenizer ne change pas

Nos 24 échantillons, un passage narratif en neuf langues, des textes techniques et d’actualité dans six d’entre elles, une fonction Python et un tool call JSON, ont produit exactement le même nombre de tokens sur GPT-5.5, Sol, Terra et Luna pour chaque comparaison menée à terme. Les budgets de tokens et les estimations du seuil de cache calibrés sur 5.5 restent donc valables sans modification. Le comportement selon les langues est détaillé dans notre analyse des tokenizers par langue et s’applique tel quel à 5.6.

En bref

• Le passage de 50 % à 90 % de remise sur le cache, accompagné d’un TTL minimal garanti de 30 minutes, constitue la véritable baisse de prix de cette version. Les tarifs des tiers font les gros titres, mais les nouvelles conditions du cache ont davantage d’impact sur les factures réelles.
• Adoptez les breakpoints explicites pour les prompts en couches : la réutilisation partielle est mesurée, pas théorique, et le modèle mental de Claude s’applique directement.
• Respectez le seuil de 1,024 tokens, envoyez un prompt_cache_key et surveillez cached_tokens ; un cache miss ou une absence totale de mise en cache peuvent tous deux passer inaperçus.
• Envoyez explicitement reasoning_effort, avec none par défaut : sur notre matrice, le comportement non maîtrisé a coûté 1.5x plus cher, jusqu’à 3.5x sur certaines tâches, pour des réponses identiques.
• xhigh est le maximum accessible (max renvoie une erreur 400 via les chat completions) ; aucun recalibrage du tokenizer n’est nécessaire par rapport à 5.5.

FAQ

GPT-5.6 prend-il en charge un prompt caching explicite comme Claude ? Oui. Utilisez prompt_cache_options: {"mode": "explicit"} et des marqueurs prompt_cache_breakpoint sur les blocs de contenu, avec jusqu’à quatre écritures par requête. En mode implicite, le breakpoint automatique occupe un emplacement, ce qui n’en laisse que trois. Lors de nos mesures via une gateway compatible OpenAI, un préfixe marqué de 3,012 tokens a été écrit au premier appel, puis relu intégralement au tarif du cache lors du second.

Combien coûte l’input en cache sur GPT-5.6 ? 10 % du tarif d’input, d’après nos mesures sur les trois tiers : $0.10 par million sur Luna, $0.25 sur Terra et $0.50 sur Sol. GPT-5.x facturait les tokens en cache à 50 % du tarif d’input. Le prix des tokens en cache est donc 5x plus bas sur 5.6.

Le cache de GPT-5.6 est-il meilleur que celui de GPT-5.5 ? Oui, sur le niveau de remise et le contrôle : tarif à 10 % au lieu de 50 %, quatre breakpoints explicites au lieu d’une détection uniquement automatique qu’il est impossible de déclencher ou de déboguer, et minimum de 30 minutes avec clé au lieu de 5 à 10 minutes sans garantie. GPT-5.5 ne conserve qu’un avantage : l’option de rétention de 24 heures, supprimée sur 5.6.

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, et les données peuvent être conservées plus longtemps. Cette option remplace prompt_cache_retention, désormais déprécié, ainsi que l’ancien tier étendu de 24 heures. Dans nos tests, les relectures avec clé effectuées 15 minutes après l’écriture ont entièrement utilisé le cache. Nous n’avons pas testé les 30 minutes complètes.

Dois-je utiliser prompt_cache_key ? Oui. La documentation recommande une clé stable par tenant ou par session pour obtenir des correspondances fiables sur 5.6, avec une limite indicative d’environ 15 requêtes par minute et par clé. Son inclusion ne coûte rien. Associée à la surveillance de cached_tokens, elle permet de vérifier que la remise s’applique réellement.

Dans quelle mesure reasoning_effort modifie-t-il le coût de GPT-5.6 ? Sur notre matrice de 50 appels, quatre types de tâches, six réglages, Terra et Luna, tous les réglages ont produit des réponses correctes. L’omission du paramètre a toutefois coûté 1.5x plus cher que none au total, et jusqu’à 3.5x sur la tâche arithmétique. Pour les tâches triviales comme la classification et l’extraction, aucun réglage n’a consommé de tokens de raisonnement. Fixez none et n’augmentez le niveau qu’en fonction de vos evals.

Le niveau maximal de reasoning effort est-il disponible sur GPT-5.6 Sol ? Pas via les chat completions. Les requêtes avec reasoning_effort: "max" renvoient une erreur 400 indiquant les valeurs de none à xhigh, sur Sol comme sur Terra.

Quel tier GPT-5.6 choisir pour une charge API ? Sol succède à gpt-5.5 au même prix : grille identique à $5/$30, mais lectures du cache 5x moins chères. Terra et Luna sont les tiers allégés, facturés respectivement à la moitié et au cinquième de ce tarif. Lorsque le préfixe est stable et associé à une clé, la remise de 90 % réduit fortement le poids de l’input. Descendez donc de tier aussi loin que vos evals de qualité d’output le permettent, puis laissez le tier déterminer le prix de sortie.

Autres guides de cette série fondés sur des mesures de coût : coût de la transcription audio sur sept modèles ASR, coût de la génération d’images et tarification de la voix avec GPT Realtime.

← Retour au blog