Passer au contenu principal
Illustration des trois modèles GPT-5.6 Sol, Terra et Luna et du mécanisme de mise en cache des prompts
OpenAI a officiellement publié la série GPT-5.6 le 9 juillet 2026. AIHubMix a intégré les trois modèles : gpt-5.6-sol, gpt-5.6-terra et gpt-5.6-luna sont désormais appelables via Chat Completions et Responses. Cette publication modifie également le mécanisme et la facturation de la mise en cache des prompts — l’écriture en cache est désormais facturée séparément. Cet article présente le positionnement des trois modèles et analyse point par point les changements du cache.

​
Ce qui change avec les trois modèles GPT-5.6

GPT-5.6 revoit le système de nommage : le numéro désigne la génération du modèle, tandis que Sol, Terra et Luna sont des paliers de capacité pouvant évoluer indépendamment. Définition officielle : Sol est le modèle phare, Terra est le palier économique aux performances équivalentes à GPT-5.5, Luna est le palier le plus rapide et le moins cher.
gpt-5.6-solgpt-5.6-terragpt-5.6-luna
Positionnement officielModèle phare pour le travail professionnel complexeÉquilibre intelligence / coûtCharges sensibles au coût
Fenêtre de contexte1 050 0001 050 0001 050 000
Sortie maximale128 000128 000128 000
Date de coupure des connaissances2026-02-162026-02-162026-02-16
Palier approximatif de l’ancienne générationSans suffixemininano
Formulation officielle sur les capacités : Sol obtient des résultats à l’état de l’art en codage, travail de connaissance, cybersécurité et tâches scientifiques ; OpenAI le présente comme son meilleur modèle de codage à ce jour, avec de nouveaux records sur Terminal-Bench 2.1 et DeepSWE. Terra offre des performances équivalentes à GPT-5.5 pour un prix réduit de moitié. La série ajoute un niveau de raisonnement max, et la Responses API gagne le Programmatic Tool Calling et des capacités multi-agent (Beta).

​
Analyse de l’évolution du mécanisme de cache

Avant GPT-5.6, la mise en cache des prompts de la série GPT était entièrement automatique : un préfixe atteignant 1 024 jetons était mis en cache automatiquement, les développeurs ne contrôlaient ni le contenu mis en cache ni sa durée, et le cache était effacé après 5–10 minutes d’inactivité. OpenAI résume les changements de GPT-5.6 par une mise en cache « plus prévisible » (more predictable prompt caching), en trois points :
  1. La rétention passe de « 5 minutes minimum » à « au moins 30 minutes ». prompt_cache_options.ttl ne prend actuellement en charge que "30m" ; c’est une durée plancher, la rétention effective peut être plus longue.
  2. Ajout de points de rupture de cache explicites. Placer prompt_cache_breakpoint sur un bloc de contenu fixe la limite du cache à la fin du contenu stable ; les modifications situées après le point de rupture ne détruisent pas le cache du préfixe précédent. Lorsque prompt_cache_options.mode vaut "explicit", seuls les points de rupture manuels sont utilisés.
  3. prompt_cache_key passe d’optimisation optionnelle à exigence officielle. À partir de GPT-5.6, ce paramètre doit être défini pour activer une correspondance de cache plus fiable ; OpenAI recommande de maintenir le trafic d’une même key autour de 15 requêtes/minute.

​
Comment évaluer la facturation à 1,25x de l’écriture en cache

À partir de GPT-5.6, l’écriture en cache est facturée à 1,25 fois le prix d’entrée de base et la lecture à 0,1 fois ; pour les modèles antérieurs, l’écriture en cache était sans facturation supplémentaire. Texte officiel (extrait de l’annonce de lancement de GPT-5.6) : “For GPT-5.6 and later models, cache writes are billed at 1.25x the model’s uncached input rate, while cache reads continue to receive the 90% cached-input discount.” Le point d’équilibre se calcule directement à partir des taux officiels : écrire un préfixe coûte 0,25x le prix d’entrée de plus que sans cache, puis chaque hit économise 0,9x le prix d’entrée — dès qu’un préfixe est réutilisé 1 fois, l’économie est nette, et elle augmente avec le nombre de réutilisations.
  • Charges qui en bénéficient nettement : workflows d’agents à longs prompts système, RAG citant de manière répétée de longs documents de référence, applications transportant de nombreuses définitions d’outils, conversations multi-tours qui ajoutent uniquement des messages à la fin. Ces charges ont un taux de réutilisation de préfixe élevé, et le tarif de lecture à 0,1x domine.
  • Charges à surveiller : les longues requêtes uniques dont le préfixe ne sera pas réutilisé. Le cache automatique est activé par défaut, et ces requêtes génèrent des frais d’écriture à 1,25x non récupérables ; réglez prompt_cache_options.mode sur "explicit" sans définir de point de rupture, et la requête n’utilise pas le cache ni ne génère de frais d’écriture.

​
GPT-5.6 vs Claude : la mise en cache des prompts

La conception du cache de GPT-5.6 converge sur plusieurs dimensions avec le cache_control de Claude ; la différence centrale porte sur le comportement par défaut : GPT met en cache automatiquement sans aucun paramètre ; Claude requiert l’activation du cache dans la requête — champ cache_control au niveau racine (point de rupture automatique) ou point de rupture explicite au niveau des blocs de contenu.
DimensionSérie GPT-5.6Série Claude (tous les modèles actifs)
DéclenchementCache automatique, points de rupture explicites optionnelsActivation requise : cache_control racine (point de rupture automatique) ou point de rupture au niveau des blocs
Paramètre de point de ruptureprompt_cache_breakpoint (niveau bloc de contenu)cache_control (niveau racine ou bloc de contenu)
Nombre maximal de points de rupture4 nouvelles écritures max par requête4 points de rupture max
Rétention du cacheAu moins 30 minutes5 minutes par défaut (rafraîchi sans frais à chaque hit), 1 heure en option
Facturation de l’écriture en cache1,25x le prix d’entrée1,25x pour 5 minutes, 2x pour 1 heure
Facturation de la lecture en cache0,1x le prix d’entrée0,1x le prix d’entrée
Longueur minimale de cache1 024 jetons512–4 096 jetons selon le modèle
Condition de hitIdentité octet par octet avant le point de ruptureIdentité octet par octet avant le point de rupture
La colonne Claude du tableau correspond au barème commun à tous les modèles Claude actifs : écriture à 1,25x pour le palier 5 minutes, 2x pour le palier 1 heure, lecture à 0,1x sur toute la gamme (documentation Anthropic sur la mise en cache des prompts) ; les différences entre modèles ne portent que sur la longueur minimale de cache. La colonne GPT-5.6 provient du guide OpenAI de mise en cache des prompts. Le plafond de points de rupture, les taux d’écriture (à palier correspondant) et le taux de lecture sont identiques chez les deux fournisseurs ; concrètement pour les développeurs, la même stratégie de structuration des prompts — « contenu fixe en premier, contenu variable en dernier » — s’applique aux deux gammes de modèles. Le coût de migration se concentre sur la syntaxe des paramètres : GPT utilise prompt_cache_breakpoint + prompt_cache_key, Claude utilise cache_control.

​
Écriture du cache dans les deux protocoles

Pour le même scénario « mettre en cache de longues instructions fixes », voici l’implémentation minimale dans les deux protocoles. Les exemples utilisent gpt-5.6-sol et claude-opus-4-8 — leur prix d’entrée de base est identique ($5/M), et les prix effectifs issus des taux d’écriture (1,25x) et de lecture (0,1x) sont donc également identiques ; seule l’écriture diffère : Le protocole GPT définit prompt_cache_key à la racine (le long préfixe est mis en cache automatiquement, sans marqueur de point de rupture) ; le protocole Claude définit cache_control à la racine pour activer le cache automatique, et passe aux points de rupture au niveau des blocs lorsque la limite du cache doit être contrôlée précisément :
GPT-5.6（Chat Completions）
curl https://aihubmix.com/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $AIHUBMIX_API_KEY" \
  -d '{
    "model": "gpt-5.6-sol",
    "prompt_cache_key": "my-app-report-v1",
    "messages": [
      {
        "role": "system",
        "content": "[longues instructions fixes, ≥1024 jetons]"
      },
      {
        "role": "user",
        "content": "Summarize the key figures."
      }
    ]
  }'
Claude（Messages）
curl https://aihubmix.com/v1/messages \
  -H "Content-Type: application/json" \
  -H "x-api-key: $AIHUBMIX_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -d '{
    "model": "claude-opus-4-8",
    "max_tokens": 1024,
    "cache_control": {"type": "ephemeral"},
    "system": "[longues instructions fixes, ≥1024 jetons]",
    "messages": [
      {
        "role": "user",
        "content": "Summarize the key figures."
      }
    ]
  }'
En comparant les deux requêtes, les différences se concentrent sur : le point de terminaison (/v1/chat/completions et /v1/messages), l’en-tête d’authentification (Authorization: Bearer et x-api-key + anthropic-version), le paramètre de cache (prompt_cache_key racine et cache_control racine), et l’obligation d’un max_tokens explicite pour Claude. Les deux requêtes ont été mesurées sur aihubmix.com (2026-07-10) : gpt-5.6-sol renvoie cached_tokens: 2816 au deuxième appel ; claude-opus-4-8 renvoie cache_creation_input_tokens: 3632 au premier appel et cache_read_input_tokens: 3632 au deuxième. Au-delà du format des requêtes, trois différences de mécanisme :
  1. Activation : GPT met en cache automatiquement même sans aucun paramètre de cache, prompt_cache_key servant à fiabiliser les hits ; Claude requiert une déclaration — point de rupture cache_control au niveau des blocs de contenu, ou mode automatique via cache_control à la racine de la requête.
  2. Champs usage : la lecture de cache GPT figure dans prompt_tokens_details.cached_tokens ; Claude rapporte séparément écriture et lecture via cache_creation_input_tokens et cache_read_input_tokens, ce qui permet de vérifier écritures et hits distinctement.
  3. Contrôle de la durée de vie : le ttl de GPT-5.6 ne prend actuellement en charge que "30m" ; Claude est à 5 minutes par défaut (rafraîchi sans frais à chaque hit), avec l’option "ttl": "1h" (écriture facturée à 2x).

​
Que modifier pour échanger les modèles entre protocoles

La passerelle AIHubMix prend en charge les appels inter-protocoles : l’interface compatible OpenAI peut appeler les modèles Claude (cache_control s’écrit directement dans les blocs de contenu des messages au format OpenAI, syntaxe décrite dans Pratiques de mise en cache des prompts) ; le point de terminaison /v1/messages compatible Claude peut aussi appeler GPT-5.6 (vérifié en conditions réelles). Trois points à vérifier lors de l’échange :
  • Remplacer model par l’ID du modèle cible ;
  • Adapter la syntaxe du paramètre de cache : prompt_cache_key / point de rupture explicite correspondent au cache_control de Claude ;
  • Adapter le nom du champ usage : cached_tokens correspond au cache_read_input_tokens de Claude.
Voie recommandée pour la mise en cache des prompts : Chat Completions pour les modèles GPT (voie dont le hit a été mesuré dans cet article), et l’un ou l’autre protocole pour les modèles Claude.

​
GPT-5.6 vs générations GPT précédentes : le cache

DimensionAvant GPT-5.6GPT-5.6 et suivants
Écriture en cacheSans facturation supplémentaire1,25x le prix d’entrée
Rétention du cacheEffacé après 5–10 minutes d’inactivité, 1 heure maxAu moins 30 minutes
Contrôle du cacheAucunPoints de rupture explicites, mode explicit, correspondance fiable via prompt_cache_key
Rétention étendue 24 heuresprompt_cache_retention sur certains modèlesRemplacée par prompt_cache_options.ttl (actuellement 30m uniquement)
La direction du changement est cohérente : le cache des générations précédentes était gratuit, sans contrôle et à rétention incertaine ; GPT-5.6 facture l’écriture tout en apportant une durée de rétention plancher et des moyens de contrôle précis du cache. Selon les taux, dès qu’un préfixe est réutilisé en moyenne plus d’1 fois, l’économie dépasse le coût d’écriture ajouté ; la rétention plancher de 30 minutes et les points de rupture contrôlables augmentent la probabilité d’atteindre ce taux de réutilisation.

​
Commencer sur AIHubMix

Les trois modèles sont en ligne, avec les ID gpt-5.6-sol, gpt-5.6-terra et gpt-5.6-luna. Le cache ne nécessite aucune configuration supplémentaire ; des requêtes consécutives avec le même long préfixe suffisent pour obtenir un hit :
Python
import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["AIHUBMIX_API_KEY"],
    base_url="https://aihubmix.com/v1",
)

long_context = "You are a meticulous assistant for analyzing quarterly financial reports... [longues instructions fixes, ≥1024 jetons]"

for i in range(2):
    completion = client.chat.completions.create(
        model="gpt-5.6-sol",
        prompt_cache_key="my-app-report-assistant-v1",
        messages=[
            {"role": "system", "content": long_context},
            {"role": "user", "content": "Summarize the key figures in one sentence."},
        ],
    )
    print(completion.usage.prompt_tokens_details)
Si usage.prompt_tokens_details.cached_tokens du deuxième appel est supérieur à 0, le cache a été touché (exemple mesuré : cached_tokens: 2816). Les paramètres, les détails de facturation et le dépannage des hits figurent dans la documentation Mise en cache des prompts GPT.

​
Foire aux questions (FAQ)

​
Quelles interfaces permettent d’appeler GPT-5.6 sur AIHubMix ?

Chat Completions (/v1/chat/completions), Responses (/v1/responses) et l’interface Messages compatible Claude (/v1/messages) sont disponibles ; les trois modèles sont tous en ligne. Pour la mise en cache des prompts, la voie actuellement recommandée est Chat Completions.

​
Sans modification côté client, qu’est-ce qui change dans la facturation après le passage à GPT-5.6 ?

La mise en cache des prompts s’applique automatiquement par défaut : les requêtes dont le préfixe atteint 1 024 jetons génèrent une ligne d’écriture en cache facturée à 1,25x le prix d’entrée ; les préfixes réutilisés sont facturés à 0,1x en lecture. Le coût total des applications à fort taux de réutilisation de préfixe diminue en général ; les longues requêtes uniques sans réutilisation de préfixe peuvent désactiver le cache avec le mode explicit.

​
J’utilise déjà le cache de prompts Claude ; que modifier pour migrer vers GPT-5.6 ?

La stratégie de structure des prompts reste la même : contenu fixe au début, contenu variable à la fin. Le paramètre passe de cache_control à prompt_cache_breakpoint, complété par prompt_cache_key ; la rétention passe des deux paliers 5 minutes / 1 heure à un plancher de 30 minutes.

​
Comment choisir entre les trois modèles GPT-5.6 ?

Formulation officielle : Sol pour le travail professionnel complexe et les tâches de codage ; Terra pour les charges de travail quotidiennes (performances équivalentes à GPT-5.5, prix réduit de moitié) ; Luna pour les gros volumes sensibles au coût. Les trois partagent la même fenêtre de contexte et la même sortie maximale, ce qui permet un routage par niveau de complexité des tâches.

​
Références officielles

Les spécifications des modèles, le mécanisme de cache et les taux de facturation de cet article proviennent des sources officielles suivantes : Documentation associée sur le site : Mise en cache des prompts GPT · Mise en cache des prompts Claude · Pratiques de mise en cache des prompts
Consultez les prix de la série GPT-5.6 dans la galerie de modèles ou découvrez d’autres modes d’intégration dans le centre de documentation.
Mis à jour : 2026-07-10