GPT-6.1 Ultrafast vs GPT-6.1 Sol : trois tâches, un verdict chacune

Demandez si GPT-6.1 Ultrafast vaut six fois le prix de GPT-6.1 Sol et la réponse honnête est que deux de vos trois charges de travail devraient rester exactement là où elles sont. L'agent de codage interactif devrait migrer. La campagne d'évaluation nocturne, non, et le résumeur par lots non plus, et la raison n'est pas que ce palier soit trop cher — c'est qu'ils n'achetaient jamais ce qu'il vend. GPT-6.1 Sol est sorti le 29 septembre 2026 et Ultrafast est arrivé comme un mode au-dessus de lui le 8 octobre 2026 : même checkpoint, même fenêtre de contexte de 1 050 000 tokens, même plafond de sortie de 128 000 tokens, même date limite de connaissances du 30 avril 2026, mêmes réponses, à $12.00 par million de tokens d'entrée et $60.00 par million de tokens de sortie contre $2.00 et $10.00. Un palier de vitesse, c'est l'achat de temps d'horloge, et le temps d'horloge ne vaut de l'argent que pour un travail que quelqu'un attend.

Ce recadrage, c’est tout l’article. Le reste, c’est l’arithmétique qui vous dit lesquels de vos postes sont du genre à attendre, et les deux coûts qui accompagnent le multiple, que vous les ayez prévus ou non.

Ce qui diffère réellement : un champ de requête et une facture

Il n’existe pas de point de contrôle Ultrafast, pas de limite de contexte distincte, pas de date de coupure des connaissances alternative, et rien à épingler. Vous envoyez le même identifiant de modèle avec un champ de niveau de service défini, et OpenAI planifie la requête différemment ; envoyez-le sans le champ et vous êtes sur Standard. Tout ce contre quoi un développeur code est identique, et il vaut la peine d’être mécanique quant à la liste, car la longueur de la liste est l’argument.

• ID de modèle — le même identifiant sur les deux, un instantané par défaut, rien de daté à épingler.

• Contexte — une fenêtre de 1 050 000 jetons, une entrée maximale de 922 000 jetons et une sortie maximale de 128 000 jetons pour les deux.

• Échelle de raisonnement : low, medium (par défaut), high, xhigh et max sur les deux, none non pris en charge sur les deux.

• Surface d’outils — recherche web, recherche de fichiers, génération d’images, interpréteur de code, shell hébergé, application de correctifs, compétences, utilisation de l’ordinateur, MCP et recherche d’outils, via l’API Responses, sur les deux.

• Prix — 2,00 $ en entrée / 0,10 $ en cache / 2,50 $ en écriture de cache / 10,00 $ en sortie par million de tokens en Standard, contre 12,00 $ / 0,60 $ / 15,00 $ / 60,00 $ en Ultrafast.

• Au-delà de 272 000 jetons d'entrée — l'ensemble de la requête est re-tarifé à 2x les tarifs d'entrée et de cache et à 1,5x pour la sortie sur les deux, ce qui place Ultrafast long-context à 24,00 $ / 1,20 $ / 30,00 $ / 90,00 $.

• Vitesse — Standard est la base de référence par définition ; Ultrafast est l’échelon le plus élevé, et le seul multiple propre à un modèle qu’O​penAI publie appartient à G​PT-6 Astra, et non à ce modèle.

Cette dernière ligne est la mise en garde qui sous-tend tout le reste, et elle a sa propre section plus bas. D’abord, les emplois.

Poste numéro un : l'agent interactif. C'est celui qui bouge.

Une boucle d'agent qui effectue quarante appels d'outils d'affilée est l'acheteur pour lequel ce palier a été conçu, car le temps de génération de chaque tour conditionne le tour suivant, et l'utilisateur regarde. Prenez une session qui envoie 30 000 jetons d'entrée et reçoit 1 500 jetons de sortie par tour sur 40 tours — 1 200 000 jetons d'entrée et 60 000 jetons de sortie au total, chaque requête étant bien en dessous du seuil de re-tarification de 272 000 jetons.

• Standard — 1,2 million de jetons d’entrée à 2,00 $, soit 2,40 $ ; 60 000 jetons de sortie à 10,00 $, soit 0,60 $. Trois dollars pour l’exécution.

• Ultrafast — 1,2 million de tokens d'entrée à 12,00 $, soit 14,40 $ ; 60 000 tokens de sortie à 60,00 $, soit 3,60 $. Dix-huit dollars pour l'exécution.

• Le delta — 15,00 $ pour supprimer la majeure partie de la latence de génération d’une tâche dont le résultat est par ailleurs identique.

Savoir si 15,00 $ est bon marché est une question de minutes, pas de jetons. Si la session prend vingt minutes sur Standard et quatre minutes sur Ultrafast, vous avez acheté seize minutes pour quinze dollars — environ 0,94 $ la minute — et la comparaison qui compte est celle avec ce que ces seize minutes vous coûtent. Un développeur au coût complet vaut plus d'un dollar la minute ; donc, dans le cas où un humain est dans la boucle, la réponse est sans appel. Un agent qui attend dans une file d'attente de révision humaine ne vaut rien à la minute, et là, ces mêmes seize minutes sont seize minutes gratuites et le palier est un gaspillage.

Voilà le test à appliquer, et il n’a rien à voir avec le modèle. Sur l’horloge de qui repose le temps de génération, et que vaut cette horloge ? Si la réponse est « celle d’une personne, et beaucoup », Ultrafast est l’élément le moins cher de votre facture. Si la réponse est « celle d’un ordonnanceur, et rien », c’est l’élément le plus cher.

Tâche deux : la campagne d’évaluation nocturne. C’est un non.

Un sweep d’évaluation fait passer quelques milliers de prompts dans le modèle, écrit les résultats dans le stockage objet, et un humain lit le tableau le matin. Son budget de latence ne se chiffre pas en minutes ; il se chiffre en une nuit. Rien dans le pipeline n’attend le modèle, hormis la prochaine requête dans la file d’attente.

Ultrafast ne supprime pas le coût en temps d’horloge du balayage, car ce coût en temps d’horloge est une décision d’ordonnancement que vous avez prise, et non un problème de latence que vous subissez. Ce qu’il fait, c’est multiplier la facture par six et déplacer la tâche vers un budget assorti de ses propres limites de débit par organisation — ce qui constitue un risque réel dans un traitement par lots sans surveillance, car un plafond de limite de débit est exactement le mode de défaillance qu’un grand balayage rencontre, et la page du niveau ne publie pas la valeur.

Et il y a une voie sur la même grille tarifaire qui est tarifée pour cette tâche et tarifée dans la direction opposée. Batch et Flex sont tarifés à la moitié de Standard, et le traitement Batch de l’API est conçu exactement pour ce profil : de gros volumes, aucune échéance interactive, des résultats renvoyés de manière asynchrone. D’après les chiffres ci-dessus, le même total de 40 tours coûte 1,50 $ avec Batch contre 18,00 $ avec Ultrafast. Cela représente un écart de 12x pour une tâche qui ne peut pas faire la différence.

L’erreur à éviter est de considérer Ultrafast comme la mise à niveau polyvalente. C’est le sommet d’une échelle — Batch et Flex à moitié, Standard à un, Fast à deux, Ultrafast à six — et une échelle n’est pas un menu de versions meilleures. Choisir le mauvais barreau coûte plus cher que choisir le mauvais modèle.

Job trois : le résumeur par lots. Aussi un non, pour une autre raison.

Supposons que la charge de travail soit une passe nocturne sur un magasin de documents : entrées longues, sorties courtes, aucune intervention humaine, et un SLA mesuré en heures. C’est là que la composition des tokens joue contre Ultrafast plutôt qu’en sa faveur.

Le seuil de 272 000 tokens est la raison. Quel que soit le palier, une seule requête qui le franchit réévalue l’ensemble de la requête — chaque token d’entrée, chaque lecture en cache, chaque token de sortie — en appliquant le double des tarifs d’entrée et de cache et 1,5 fois le tarif de sortie. Long-context Ultrafast revient donc à 24,00 $ par million de tokens d’entrée et à 90,00 $ par million de tokens de sortie, et la réévaluation est déclenchée par la requête, et non par la partie qui dépasse le seuil. Un outil de résumé de documents qui envoie occasionnellement une requête de 300 000 tokens d’entrée paie le tarif long contexte sur la totalité de ces 300 000 tokens.

Le comportement du cache l’amplifie. Les lectures mises en cache sont les tokens les moins coûteux sur ce modèle et le levier de coût le plus efficace, et elles évoluent avec le palier au lieu de l’absorber — 0,10 $ par million d’entrées mises en cache sur Standard, 0,60 $ sur Ultrafast, les deux à 5 % du tarif des entrées non mises en cache. Aucun mélange de tokens mis en cache et de tokens frais n’atténue ce facteur multiplicatif, de sorte qu’un pipeline en cache fortement optimisé ne bénéficie pas d’une réduction de la part de la voie rapide. Il paie simplement six fois un nombre plus petit.

En combinant les deux, le résumeur est le cas où le surcoût d’Ultrafast est le plus élevé en termes absolus et son bénéfice est le plus faible. Si les documents sont vraiment longs et que le délai est réellement de plusieurs heures, la configuration correcte est Batch ou le Standard standard, et le bon usage d’Ultrafast est la boucle de mi-développement, où vous itérez sur le prompt et une personne attend chaque révision.

Les deux coûts qui accompagnent le multiple

Le tarif x6 est la partie visible du prix. Deux parties invisibles comptent davantage en production.

Le premier est le budget de limitation de débit. Ultrafast fonctionne selon ses propres limites, distinctes des budgets Standard et Fast, et O​penAI les définit par organisation plutôt que de les publier sur la page des niveaux ; la recommandation est de vérifier les limites de votre organisation avant d’augmenter le trafic et de contacter une équipe de compte si elles doivent être relevées. Ainsi, faire passer une charge de travail à Ultrafast fait deux choses à la fois : elle multiplie la facture et elle place la charge de travail sous un plafond que vous ne pourrez peut-être pas lire. Pour un agent non supervisé, le plafond contraint en premier.

Le deuxième point est la structure des économies. Ultrafast réduit le temps entre les tokens, pas le temps jusqu’au premier token ni la phase de délibération. Une requête qui passe la majeure partie de son temps réel à réfléchir avant d’émettre quoi que ce soit peut être basculée vers Ultrafast et continuer de paraître lente, car le niveau accélère la partie de la requête qui n’a jamais été le goulot d’étranglement. C’est le mode de défaillance qui produit les retours du type « nous avons payé six fois plus et c’est la même vitesse » : on mesure une application dont la latence réside là où le niveau n’atteint pas. Avant de vous engager, mesurez où passent réellement les secondes — le temps jusqu’au premier token par rapport au temps entre les tokens — car le niveau n’a prise que sur l’un des deux.

Pourquoi « plus rapide » n’est pas encore un chiffre que vous pouvez exiger d’OpenAI

Ultrafast est vendu sur la base de « jusqu'à 8x », et la mesure derrière cette expression appartient à un autre modèle. La phrase publiée concerne G​PT-6 Astra Ultrafast générant des jetons jusqu'à 8 fois plus vite que G​PT-6 Astra en mode Standard dans Codex. Il n'existe aucun multiple publié équivalent pour GPT-6.1 Sol, et aucune partie indépendante n'a non plus publié de chiffre de jetons par seconde pour la variante Sol. La documentation de ce niveau le décrit comme réduisant le temps entre les jetons de sortie générés et pointe vers une grille tarifaire.

C’est un a priori raisonnable que le facteur multiplicateur se reporte — les deux modèles reposent sur la même pile de service et le mécanisme du palier est le même —, mais « jusqu’à » joue un vrai rôle dans cette phrase, et un plafond fournisseur mesuré sur un modèle frère chez un autre client n’est pas le chiffre que votre charge de travail verra. Il en va de même pour l’échelon plus ancien : Ultrafast sur GPT-5.6 Sol a été annoncé en août 2026 comme étant « jusqu’à 14x plus rapide que Standard processing » en aperçu limité, et la documentation indique toujours un accès en aperçu, la table tarifaire Ultrafast ne contenant que deux lignes exactement.

Ce à quoi vous pouvez tenir OpenAI, c'est le prix, car le prix est publié et s'applique à chaque token. Ce qui signifie que la décision dont traite cette page est une décision qui porte sur votre propre budget de latence, et non sur l'allégation de vitesse du fournisseur.

Tester sans committer, puis revenir en arrière

Ce niveau est disponible pour tous les utilisateurs de l’API, donc le moyen le plus économique de répondre à la question du temps d’horloge consiste à exécuter deux fois le même ensemble d’invites, avec le champ activé puis désactivé, et à comparer le nombre de jetons et les durées. Deux choses à surveiller dans ce test : si vos requêtes franchissent la barre des 272 000 jetons, et si le temps jusqu’au premier jeton domine le temps entre les jetons. L’un ou l’autre peut donner à l’essai l’apparence d’un résultat nul alors que le niveau fonctionne exactement comme annoncé.

Le retour en arrière est un champ de requête, pas une migration, et la voie standard est servie au tarif catalogue propre au fournisseur, via OrcaRouter, sous la référence openai/gpt-6.1-sol — 2,00 $ par million de jetons en entrée et 10,00 $ par million de jetons en sortie, 0 % de marge, le prix du fournisseur étant répercuté tel quel, si bien qu'une révision tarifaire du fournisseur est effective de notre côté le jour même. Ultrafast en soi n'est pas quelque chose que nous vendons ; c'est un indicateur de niveau de service facturé sur votre propre compte OpanAI, et le dire est plus utile que de laisser entendre le contraire. Ce qu'une clé unique permet bel et bien d'obtenir, c'est la voie standard plus le reste du catalogue derrière un seul point de terminaison compatible OpanAI, et la bascule automatique entre fournisseurs, ce qui vaut la peine si vous vous apprêtez à placer un niveau tarifaire coûteux devant un agent en production et souhaitez que la voie standard relève d'une décision de routage plutôt que d'une modification de code.

Une remarque pratique sur la voie rapide qui ne s’applique pas à l’option économique : les WebSockets. OpenAI recommande une connexion WebSocket persistante pour Ultrafast, ce qui est la bonne approche pour un agent qui effectue de nombreux appels séquentiels, et la mauvaise pour un script par lots qui fait une requête par processus. Si votre client est du second type, le transport recommandé par le niveau lui-même est une raison supplémentaire pour laquelle la tâche nocturne a sa place ailleurs.

Lorsque le verdict change

Trois évolutions feraient sortir des tâches de la liste « rester ». Une limite de débit Ultrafast publiée pour GPT-6.1 Sol éliminerait le risque de plafond dans le cas du traitement par lots. Une mesure de vitesse publiée ou reproduite indépendamment pour le palier Sol vous permettrait de budgéter l'économie de temps réel au lieu de la supposer. Et un échelon de remise sur la voie rapide — un équivalent Ultrafast de Batch, où le palier reste rapide mais ne coûte pas six fois le prix — changerait l'économie de chaque tâche au milieu de l'échelle.

Aucun de ceux-là n’existe aujourd’hui. Ce qui existe, c’est un palier qui est exactement ce qu’il dit être : le même GPT-6.1 Sol, ordonnancé différemment, à six fois le prix sur chaque ligne. Déplacez l’agent interactif, laissez les deux autres tranquilles, et mesurez où passent réellement vos secondes avant de décider lequel est le vôtre.