GPT-5.6 Sol Ultrafast vs GPT-5.6 Sol : mêmes poids, niveau de service différent

GPT-5.6 Sol Ultrafast n'est pas un nouveau modèle, et il ne s'agit pas d'une annonce de lancement. L'éditeur a annoncé ce mode le 13 août 2026, et le jour même, la valeur ultrafast est apparue dans le schéma OpenAPI public de l'entreprise, à l'intérieur de la description ServiceTierResponses de la spécification — laquelle limite ce niveau, selon ses propres termes, au point de terminaison gpt-5.6-sol et le marque comme soumis à un contrôle d'accès. Ce qui a remis cette page dans notre file d'attente est plus petit et plus précis : le 25 septembre 2026, le commit fe4f7a1 a étendu cette valeur à deux énumérations supplémentaires, le paramètre de niveau de service au niveau de la requête et le champ de politique de niveau de service de l'agent. Six semaines après l'annonce, ce niveau figure toujours sur une liste d'attente, n'a toujours pas de tarif publié, et il est désormais câblé dans une part plus large de la surface de l'API qu'il ne peut réellement en desservir. GPT-5.6 Sol Ultrafast et GPT-5.6 Sol sont le même modèle ; la seule chose que cette comparaison puisse trancher, c'est qui contrôle le pointeur et qui vous a annoncé le coût.

La comparaison en titre est inhabituelle. GPT-5.6 Sol Ultrafast et GPT-5.6 Sol sont le même modèle. Mêmes poids, même point de contrôle, même comportement de raisonnement, même fenêtre de contexte de 1,05 million de tokens, même sortie maximale de 128K, mêmes réponses. La formulation d'OpenAI elle-même est « plus de travail utile par seconde », pas un modèle plus intelligent. La seule chose qui diffère entre les deux colonnes de cette comparaison est la manière dont les tokens sont produits et le nom donné au niveau dans le corps de votre requête — ce qui en fait l'expérience de contrôle la plus propre de la gamme actuelle, et aussi la plus difficile à acheter, car l'un des deux niveaux n'a aucun prix publié.

Qu’est-ce qui a réellement changé cette semaine ?

La preuve du changement de septembre est un commit, pas un article de blog. OpenAI maintient openai-openapi, le dépôt qui publie le schéma lisible par machine de son API, et le commit fe4f7a1 — daté du 2026-09-25 — ajoute ultrafast à deux énumérations : la politique de niveau de service attachée aux agents, et le champ au niveau de la requête que la spécification décrit comme « le niveau de service utilisé pour les requêtes de modèle ». Il s'agit d'une extension, pas d'une première apparition : avant ce commit, ces deux listes comportaient auto, default, flex, priority, fast, et le niveau était déjà présent dans le schéma depuis le 13 août. Ce commit mérite d'être signalé en raison du champ qu'il a atteint — le champ de politique avec lequel un agent est configuré, qui constitue une surface différente d'une surcharge par requête.

La description qui compte date du commit du 13 août, pas de celui-ci, et c’est la déclaration la plus précise qu’OpenAI ait publiée sur ce niveau, où que ce soit. À côté de la nouvelle valeur, la spécification indique : « Si la valeur est définie sur 'ultrafast', alors la requête sera traitée avec le niveau de service Ultrafast Processing à accès contrôlé. Ce niveau est actuellement disponible pour gpt-5.6-sol ; une réponse servie via celui-ci affichera service_tier=ultrafast. »

Relisez cette phrase deux fois, car elle tranche deux questions sur lesquelles cette page de comparaison devrait sinon rester dans le flou. Le palier est limité à un seul modèle — le fleuron GPT-5.6 Sol, et rien d’autre dans la gamme — et il est à accès contrôlé plutôt qu’ouvert, ce qui correspond à la présentation qu’en fait OpenAI pour un aperçu sur liste d’attente. Elle vous indique aussi comment vous sauriez que vous l’avez obtenu : la réponse renvoie en écho le palier qui a réellement traité la requête, de sorte qu’un repli vers le traitement standard est visible dans le corps de la réponse, plutôt que d’être quelque chose que vous devez déduire de la latence. La même description apparaît dans les schémas Responses standard et Beta, et c’est le cas depuis le 13 août.

Un second signal, plus faible, est arrivé le lendemain. Un reportage du 26 septembre décrit un nouveau sélecteur Speed — Fast, Standard et Ultrafast — à venir dans le Responses API Playground, avec une disponibilité plus large d’Ultrafast attendue après la conférence des développeurs DevDay d’OpenAI. Nous n’avons pas vu le sélecteur nous-mêmes et OpenAI n’a pas publié de note de déploiement, alors considérez cela comme un rapport à source unique plutôt qu’une fonctionnalité déployée. Les éléments vérifiables aujourd’hui sont les deux emplacements dans le schéma public et le fait qu’aucune grille tarifaire n’est apparue pour ce niveau.

Ce qui n'a pas changé est tout aussi important. Il n'existe toujours pas de tarif Ultrafast. La page tarifaire d'OpenAI, consultée le 27 septembre, présente les quatre onglets qu'elle comportait déjà — Standard, Batch, Flex et Fast — et la chaîne « ultrafast » n'y figure nulle part. L'accès est toujours décrit comme un aperçu limité destiné à certains clients, qui s'élargira à mesure que la capacité augmentera. Ce niveau figure dans le contrat tout en étant absent de la grille tarifaire, et c'est là son état réel.

Les deux niveaux, côte à côte

Comme aucune capacité ne sépare ces deux-là, la comparaison se réduit presque entièrement au service et à la facturation. Chaque ligne ci-dessous présente les deux côtés sur une même ligne.

• Modèle — GPT-5.6 Sol Ultrafast utilise exactement le même checkpoint GPT-5.6 Sol que le traitement standard GPT-5.6 Sol, même checkpoint, sans distillation, sans réduction de taille.

• Débit de sortie — jusqu'à 750 tokens de sortie par seconde, jusqu'à 14× la norme, selon l'annonce d'OpenAI du 13 août, par rapport au traitement standard de GPT-5.6 Sol sur des clusters GPU, qui est la référence par rapport à laquelle le 14× est mesuré.

• Matériel — les puces à l’échelle du wafer de Cerebras, les poids résidant dans la SRAM sur puce, premier produit du partenariat de calcul de janvier 2026 entre OpenAI et Cerebras, d’une valeur estimée à environ 10 milliards de dollars sur trois ans selon les informations rapportées, par rapport à l’inférence GPU classique, où une grande partie du temps est consacrée au déplacement des poids entre la mémoire et le calcul.

• Prix — non publié au 27 septembre 2026, contre 4,00 $ en entrée / 20,00 $ en sortie par million de tokens, tarif promotionnel actuel d’OpenAI, plus 0,40 $ par million pour l’entrée mise en cache.

• Disponibilité — aperçu limité sur liste d'attente pour certains clients, par rapport à la voie par défaut, appelable par quiconque dispose d'une clé API.

• Les réponses que vous obtenez — identiques, en principe vs identiques, en principe ; si elles divergent sur le même prompt, c’est un constat, pas une fonctionnalité.

L'allégation de vitesse, et le plafond qui lui est imposé

Le chiffre phare est 14×, et il mérite le même soin que le reste de cette page. OpenAI annonce jusqu'à 750 tokens de sortie par seconde contre le traitement standard — un chiffre de débit pour les tokens de sortie, et non l'affirmation que chaque requête se termine 14 fois plus tôt. Le temps de bout en bout comprend aussi le traitement des entrées et le raisonnement propre du modèle, que le matériel à l'échelle d'une plaquette ne compresse ni l'un ni l'autre dans le même rapport. C'est pourquoi l'entreprise qualifie 14× de maximum plutôt que de mesure.

Les comparaisons publiées sont déclarées par les fournisseurs des deux côtés du tableau, et l’une d’elles couvre les stacks technologiques de deux fournisseurs. Une exécution de Humanity’s Last Exam de 2 500 questions est annoncée comme terminée en 11 heures 11 minutes sur Ultrafast, contre 78 heures 27 minutes pour Claude Fable 5, avec une précision comparable — c’est-à-dire OpenAI et Cerebras qui nous parlent d’un benchmark incluant le modèle d’un concurrent, et la couverture indépendante du lancement citait une comparaison plus resserrée, d’environ 11×, de la vitesse de génération sur la même exécution, tandis que les propres chiffres de Cerebras impliquent environ 7× pour le temps de test total. L’écart entre 14×, 11× et 7× n’est pas une contradiction ; c’est ce qui se passe lorsque trois parties mesurent différentes portions d’une même charge de travail. Cerebras rapporte séparément un facteur 5,6× de bout en bout sur GDP-Val, sans perte de qualité mesurable. Rien de tout cela n’a été reproduit par un tiers.

La liste de prix comporte une lacune.

C’est ici que les deux niveaux cessent d’être symétriques. GPT-5.6 Sol dispose de quatre grilles tarifaires publiées, et Ultrafast n’en fait pas partie.

• Standard GPT-5.6 Sol — 4,00 $ / 20,00 $ par million de jetons, avec l’entrée mise en cache à 0,40 $ et un palier de contexte long à 8,00 $ / 30,00 $ une fois que l’entrée dépasse environ 272 000 jetons.

• Mode rapide — 8,00 $ / 40,00 $, exactement le double du tarif standard. C'est le palier qui a été renommé depuis Priority processing le 30 juillet 2026, et l'API accepte soit service_tier: "priority", soit service_tier: "fast". Il permet d'atteindre jusqu'à environ 2,5× la vitesse de sortie.

• Batch et Flex — 2,00 $ / 10,00 $, une réduction forfaitaire de 50 % par rapport au tarif standard en échange d'une planification plus souple.

• Ultrafast — pas de grille tarifaire. Pas un blanc que nous avons comblé avec une supposition ; un blanc qu’OpenAI a laissé.

Cette ligne Fast-mode est le seul véritable précédent sur lequel on puisse évaluer le prix d'Ultrafast, et il a de quoi refroidir quiconque prépare un budget : le seul palier de vitesse pour lequel OpenAI a réellement avancé un chiffre coûte exactement le double du tarif standard, pour deux fois et demie la vitesse. Ultrafast est une promesse de vitesse plus ambitieuse, qui repose sur du matériel plus rare — la capacité de production de wafers de Cerebras n'est pas une commodité —, si bien que l'orientation de la prime finale ne fait aucun doute. Son ampleur, si. Tant qu'il n'existe pas de grille tarifaire, tout chiffre de « prix de GPT-5.6 Sol Ultrafast » que vous voyez cité où que ce soit est une déduction de quelqu'un, y compris une déduction de notre part.

Comment vous l'appelleriez réellement

Le changement de schéma vous indique la forme de l'appel final. Si le palier suit le modèle des autres, il arrive sous la forme d'un champ supplémentaire sur une requête que vous effectuez déjà : vous conservez le modèle gpt-5.6-sol, conservez votre invite, et ajoutez le sélecteur de palier — de la même manière que le mode Fast est sélectionné aujourd'hui en remplaçant priority par fast. Rien ne change dans l'analyse de votre réponse, car rien ne change dans le modèle. C'est là tout l'attrait d'un palier de service par rapport à un changement de modèle, et la raison pour laquelle une page de comparaison comme celle-ci a si peu de choses à comparer.

Ce que vous ne pouvez pas faire aujourd’hui, c’est l’appeler. La valeur d’énumération existe ; la capacité derrière elle, non, pour la plupart des comptes. Ainsi, la question pratique pour les prochaines semaines n’est pas de savoir lequel des deux paliers choisir — mais ce qu’il faut exécuter tant que ce choix n’est pas disponible.

C'est une question à laquelle une passerelle répond mieux qu'une liste d'attente. Le palier standard du modèle est déjà en ligne sur OrcaRouter sous openai/gpt-5.6-sol, servi au tarif propre du fournisseur avec zéro marge sur les tokens, via le point de terminaison compatible avec OpenAI sur api.orcarouter.ai/v1 — ainsi les tarifs promotionnels d'OpenAI à $4 / $20 et son palier de contexte long à $8 / $30 sont répercutés tels quels au lieu d'être re-tarifés par nous, et toute modification les concernant arrive de notre côté le jour même où elle arrive chez OpenAI. La même clé donne accès à plus de 200 modèles, ce qui compte plus que d'habitude ici : parce que vous ne pouvez pas définir service_tier: "ultrafast" et obtenir une réponse, le moyen d'acheter de la latence aujourd'hui est d'acheminer le travail différemment — envoyez les appels interactifs vers le modèle du catalogue qui satisfait le plus vite votre seuil de qualité, et gardez les lots de nuit sur la voie la moins chère qui passe. Quand ce palier s'ouvrira, c'est dans le routeur que vous actionnerez l'interrupteur, et d'ici là, c'est la différence entre une liste d'attente et un plan.

Lequel doit être en production ?

Ignorez un instant le mot « versus », car il n'y a ici aucune décision de qualité à prendre. Si vous optimisez le coût par token, le GPT-5.6 Sol standard est la réponse, et l'option Batch à -50 % est la réponse pour tout ce qui peut attendre. Si vous optimisez la durée pendant laquelle un humain reste devant une roue de chargement, Ultrafast est la réponse dès que vous pouvez l'obtenir — et les charges de travail qu'OpenAI cite pour la preview montrent exactement pourquoi : la réponse à incident avec des journaux et des diffs ouverts lors d'une panne en direct, les contrôles antifraude sur des données en mouvement, les conversations d'assistance où une demi-seconde de silence est perçue comme un produit en panne, et les boucles de recherche qui tournaient autrefois toute la nuit et sont désormais comprimées dans une session de travail.

L'indice révélateur, c'est la forme de votre graphe de requêtes, pas la taille de votre prompt. Une génération longue unique affiche un gain de 14× sur le papier, et bien moins en pratique, car le traitement des entrées et le raisonnement ne se compressent pas à ce ratio. Quarante appels d'outils séquentiels derrière une seule action visible par l'utilisateur apportent un gain bien plus proche du multiplicateur complet, parce que chacun de ces allers-retours est une latence que l'utilisateur subit. Si votre charge de travail ressemble à la seconde, le palier vous est destiné ; si elle ressemble à la première, la voie standard allait de toute façon convenir.

Deux choses à surveiller, et aucune n'est une rumeur que nous pouvons trancher d'ici. Premièrement, la grille tarifaire : un niveau premium sans prix ne peut pas être budgété, et le précédent du Fast-mode suggère qu'il ne sera pas modeste. Deuxièmement, si la liste d'attente se réduit réellement autour du DevDay comme rapporté — car une valeur service_tier que la plupart des comptes ne peuvent pas utiliser relève de la documentation, pas de la disponibilité, et la différence entre les deux est la différence entre un plan et une promesse.