GPT-6.1 Sol vs GPT-6 Sol : ce qu'une semaine de travail supplémentaire a apporté, et ce qu'elle n'a pas apporté

Si vous avez GPT-6 Sol en production aujourd'hui et que vous cherchez à déterminer si GPT-6.1 Sol vaut la peine d'une migration, la réponse dépend entièrement de laquelle de vos dépenses est la plus élevée — et les deux modèles sont conçus de telle sorte que la réponse n'est presque jamais « les deux ». GPT-6 Sol est sorti le 22 septembre 2026 à 2,00 $ par million de tokens d'entrée, 0,20 $ en cache et 10,00 $ en sortie. GPT-6.1 Sol est sorti le 29 septembre 2026 à 2,00 $ en entrée, 0,10 $ en cache et 10,00 $ en sortie, avec une amélioration de 6,4 points de pourcentage annoncée par le fournisseur sur des tâches complexes d'ingénierie logicielle, à un effort de raisonnement réduit. Les prix d'entrée et de sortie n'ont pas bougé. Le tarif du cache a été divisé par deux. Cette seule ligne modifiée constitue tout l'argument financier, et tout le reste est un argument de capacité qui, à ce stade du cycle de vie de la version, provient d'une seule et unique source.

Trois choses ont changé. L’une d’entre elles est une facture.

Enlevez le marketing et l'écart entre ces deux déploiements est assez court pour tenir dans votre tête.

• Entrée mise en cache — 0,10 $ par million de jetons sur GPT-6.1 Sol contre 0,20 $ sur GPT-6 Sol. Mesuré plutôt qu'affirmé, et le seul changement qui se résume à de l'arithmétique.
• Capacités, selon le fournisseur — OpenAI annonce une avance de 6,4 points sur DeepSWE v1.1 avec un effort de raisonnement et un coût moindres, plus du double du score sur Terminal-Bench Science 0.1 à effort maximal, sept points sur l'ensemble hors ligne OSWorld 2.0 à effort maximal, 4,8 points sur AutomationBench à effort moyen, et un taux d'erreurs factuelles qui passe de 11,4 % à 7,7 % sur un ensemble de prompts conçu pour induire délibérément des erreurs. Rien de tout cela n'a été reproduit.
• Échelle de raisonnement — GPT-6.1 Sol prend en charge low, medium, high, xhigh et max, mais pas none ; GPT-6 Sol prend en charge les six. C'est le delta qui casse le code, et c'est celui que personne ne met dans un billet de lancement.

Tout le reste est identique, ou presque : la même fenêtre de contexte de 1 050 000 jetons, le même plafond de sortie de 128 000 jetons, le même tarif d’écriture dans le cache de 2,50 $, le même seuil de re-tarification de 272 000 jetons au-delà duquel une requête entière est facturée à 2× le tarif d’entrée et de cache et à 1,5× celui de sortie, la même obligation de passer par l’API Responses pour l’appel d’outils, et la même absence de prise en charge du fine-tuning. La date de coupure des connaissances est passée du 20 avril au 30 avril 2026 — dix jours, le genre de chiffre qui montre bien qu’il s’agissait davantage d’une remise à niveau que d’une reconstruction.

Pourquoi la ligne de cache vaut plus qu'elle n'en a l'air

Il est étrange de commencer une refonte produit par une lecture de cache réduite de moitié, jusqu'à ce que l'on regarde à quoi ressemble réellement le trafic des agents. Une boucle d'agent renvoie un préfixe stable — invite système, schémas d'outils, contexte récupéré, historique de conversation — à chaque tour, et sur une longue session, le même préfixe est facturé des dizaines ou des centaines de fois. C'est le type de trafic où un taux de cache cesse d'être une erreur d'arrondi pour devenir la ligne dominante de la facture.

Faites le calcul sur une seule longue session d'agent. Supposez un préfixe de 120 000 tokens réutilisé sur 40 tours, soit 4,8 millions de tokens d'entrée mis en cache par session, plus un modeste 150 000 tokens de sortie frais. Sur GPT-6 Sol, les lectures mises en cache coûtent 0,96 $ et la sortie 1,50 $ — environ 2,46 $ par session. Sur GPT-6.1 Sol, la même session coûte 0,48 $ pour les lectures mises en cache et les mêmes 1,50 $ pour la sortie : environ 1,98 $. Par session, la différence est de 48 cents, ce qui n'est pas une décision. Multipliez cela par cent mille sessions par mois et cela fait 48 000 $ — ce qui en est une.

Deux mises en garde permettent de rester honnête. Les lectures mises en cache ne sont facturées au tarif du cache que lorsque le préfixe est effectivement touché ; votre économie réalisée correspond donc à votre taux de réussite multiplié par la différence, et non à la différence elle-même. Et le préfixe doit faire moins de 272,000 tokens pour que les tarifs standard s’appliquent, tout simplement : dépassez cette limite et l’ensemble de la requête est refacturé à 2× l’entrée et le cache et 1,5× la sortie, ce qui peut engloutir une économie de 10 cents sur le préfixe. Les sessions à contexte long sont celles où le calcul du cache a le moins de chances de ressembler à la brochure.

L’écart de performance est réel, et il vient d’un seul endroit.

Le post de lancement d’OpenAI est inhabituellement précis sur ses évaluations, ce qui est un point en sa faveur, et chacun de ces chiffres est le fournisseur qui note son propre modèle, ce qui est l’argument qui joue contre lui. Le schéma qui les traverse est cohérent : la comparaison qui revient est toujours face à GPT-6 Astra, et la comparaison avec Astra est toujours une comparaison de coûts. Sur DeepSWE v1.1, l’affirmation est qu’il égale Astra pour environ un cinquième du coût. Sur GDP.pdf, il s’approche de l’état de l’art d’Astra pour environ un cinquième du coût par tâche. Sur OSWorld 2.0, à 2,1 points d’Astra pour environ un septième du coût par tâche. Sur la factualité, à 1,9 point d’Astra pour moins d’un cinquième du coût par tâche. Ce n’est pas un accident de rédaction ; c’est la thèse du produit, et c’est une thèse sur le prix, pas sur le leadership en matière de capacités.

Le seul endroit où OpenAI s’affranchit de son propre cadrage mérite d’être salué : sur Terminal-Bench Science 0.1, il est clairement indiqué que GPT-6 Astra détient toujours le meilleur score parmi les modèles testés, à 68,1 %, et qu’il devrait être utilisé pour les recherches scientifiques les plus difficiles. Un post de lancement qui vous dit quand acheter le frère plus cher est un post de lancement qui fait preuve d’une certaine discipline.

Face à GPT-6 Sol en particulier, l’état honnête de la comparaison est le suivant — il n’existe aucun score indépendant pour le modèle dans cette configuration. Artificial Analysis dispose d’une évaluation complète de GPT-6 Sol à effort de raisonnement maximal : un Intelligence Index de 48, 1,06 $ par tâche de l’index, 77 millions de tokens de sortie générés contre une médiane du classement de 88 millions, et un Coding Agent Index de 57 à 2,99 $ par tâche. Il n’a aucune entrée GPT-6.1 Sol du tout au 30 septembre ; le slug du modèle renvoie une 404 et la chaîne n’apparaît pas dans le classement en direct. Ainsi, la seule comparaison mesurée par un tiers disponible aujourd’hui est entre GPT-6 Sol et les modèles d’autres laboratoires — pas entre GPT-6 Sol et son propre successeur. Quiconque vous montre un graphique 6.1 contre 6.0 en ce moment vous montre la diapositive d’OpenAI.

La migration est un changement de chaîne, sauf quand ce n'est pas le cas

Les propres consignes de migration d'OpenAI pour le GPT-6 valent la peine d'être lues avant de basculer le modèle, car deux éléments de ce guide cassent du code fonctionnel. Le premier est l'échelle de raisonnement : si une requête envoie reasoning_effort: "none", GPT-6.1 Sol la rejette, et le remède documenté est de commencer à low et de comparer sur des tâches représentatives plutôt que de supposer que le réglage le plus bas est équivalent. Les workflows qui utilisaient none comme référence de latence perdent cette référence. Le second est l'appel d'outils : GPT-6.1 Sol prend en charge Chat Completions mais pas l'appel d'outils via cette API — les outils nécessitent l'API Responses. Si votre stack appelle des fonctions sur /v1/chat/completions, vous ne remplacez pas une chaîne, vous portez un point de terminaison. L'instruction du fournisseur aux développeurs déjà sur GPT-6 Sol est de consulter ces consignes avant de changer, ce qui est un signal clair qu'il ne s'agit pas de la mise à jour directe que l'écart d'une semaine laisse supposer.

Les paramètres restants se comportent comme suit : l'effort de raisonnement, les sorties structurées, le streaming, la mise en cache des prompts et l'ensemble d'outils sont tous conservés, et la même règle de réévaluation tarifaire à 272K s'applique de manière identique aux deux modèles. Définissez model sur gpt-6.1-sol, conservez votre réglage d'effort là où il était pris en charge, et supprimez temperature, top_p et top_logprobs chaque fois que l'effort n'est pas none — ce dernier point s'applique aux deux modèles et constitue une source fréquente de 400 après toute migration vers un modèle de raisonnement.

Migrer sans parier un chemin de production dessus

La migration réaliste n'est pas un basculement, c'est une exécution en miroir : envoyez une fraction du trafic de production vers le nouvel identifiant, gardez l'ancien comme le chemin qui répond, et comparez sur vos propres tâches. C'est un problème de routage, et c'est le seul endroit où la plateforme via laquelle vous appelez change la forme du travail. OrcaRouter sert GPT-6 Sol aujourd'hui au prix catalogue d'OpenAI, sans aucune marge — la grille 2,00 $ / 0,20 $ / 10,00 $, y compris la règle de re-tarification à 272K — de sorte que le bras de référence de la comparaison est actif sur la même clé que tout le reste, et le bras 6.1 pourra être ajouté à l'ensemble de routes dès qu'il sera appelable, sans second contrat ni second SDK. D'ici là, la position honnête est que GPT-6 Sol est le modèle qu'il est possible d'appeler, et il vaut mieux le dire clairement plutôt que de sous-entendre le contraire : openai/gpt-6.1-sol renvoie « model not found » sur le point d'accès public de notre catalogue aujourd'hui. Le basculement automatique est ce qui rend l'exécution en miroir sûre le jour où elle arrivera — si la nouvelle route renvoie une erreur, la requête aboutit sur l'ancienne et vous le découvrez dans les logs plutôt que par vos utilisateurs.

Qui doit y passer dès maintenant : les équipes dont le coût est dominé par l'entrée mise en cache lors de longues sessions d'agents, et les équipes dont les workflows utilisent déjà l'API Responses et n'envoient jamais none. Pour elles, c'est presque une mise à niveau gratuite — le fournisseur annonce les gains de capacités, le taux de cache est réduit de moitié, et la migration se résume à une seule chaîne. Qui doit attendre : les équipes avec none dans un chemin critique en termes de latence, les équipes dont l'appel d'outils passe par Chat Completions, et quiconque a besoin d'un chiffre provenant de l'extérieur d'OpenAI avant de s'engager. Pour ce dernier groupe, l'attente n'a aucune date de fin publiée, et la chose sensée à faire de ce temps est de construire le jeu d'évaluation dont la comparaison aura besoin — car lorsque le score indépendant arrivera, il portera sur le trafic de quelqu'un d'autre.