GPT-6.1 Sol Fenêtre de contexte : 1 050 000 tokens, la limite des 922 000 et la falaise des 272 000

La page de modèle du fournisseur pour GPT-6.1 Sol, consultée le 7 octobre 2026, indique une fenêtre de contexte de 1 050 000 jetons et une sortie maximale de 128 000 jetons. La même page, dans la forme lisible par machine que l'on obtient en ajoutant .md à son URL, comporte un troisième chiffre que la page rendue n'affiche jamais : un maximum de 922 000 jetons d'entrée. GPT-6 Sol, le modèle auquel la version 6.1 a succédé le 29 septembre 2026, publie la paire identique de valeurs plafond sur sa propre page, ainsi que la même ligne de 922 000 dans sa propre forme markdown. Notre propre fiche modèle pour openai/gpt-6-sol indique la fenêtre comme 1 050 000 jetons et le plafond de sortie comme 128 000, affiche le premier de ces chiffres sous la forme « 1M » dans son bandeau de spécifications, et imprime « 1.1M » pour le même modèle dans un tableau comparatif plus bas sur la même page.

Donc les pages sont bel et bien en désaccord, et il vaut la peine de préciser en quoi. Le bandeau de spécifications rendu du fournisseur donne une fenêtre et un plafond de sortie, et aucun plafond d'entrée. La documentation Markdown du fournisseur pour le même modèle donne les trois. Quiconque dimensionne une requête d'après la page rendue travaille avec une contrainte de moins que ce que le fournisseur a publié, et celle qui manque est le nombre qui détermine si une requête tient.

Trois chiffres, trois sources, et une soustraction que personne ne note

Voici chaque numéro accompagné du document dont il provient, tous lus le 7 octobre 2026.

• fenêtre de contexte de 1 050 000 — la page du modèle du fournisseur pour gpt-6.1-sol, dans le bandeau de spécifications rendu et dans sa forme markdown, ainsi que le même chiffre sur la page de gpt-6-sol. C'est aussi ce que renvoie notre catalogue pour openai/gpt-6-sol et openai/gpt-6-luna, où le champ est saisi comme 1 050 000 plutôt qu'arrondi.

• 128 000 jetons de sortie maximum — la même page, les deux mêmes formulaires, pour les deux générations. Le champ de notre fiche indique 128 000 ; son affichage arrondit à « 128K ».

• 922 000 jetons d'entrée maximum — la forme markdown de la page du modèle gpt-6-sol du fournisseur et de sa page gpt-6.1-sol. Elle ne figure pas dans la bande rendue de l'une ou l'autre de ces pages, et elle ne figure pas dans notre champ de catalogue pour le modèle, qui s'arrête à la fenêtre et au plafond de sortie.

Les trois chiffres sont arithmétiquement cohérents entre eux : 922 000 plus 128 000 font exactement 1 050 000. le guide de raisonnement du fournisseur lui-même décrit le mécanisme qui rend cette identité significative sans jamais effectuer la somme sur la page du modèle — les jetons de raisonnement, y lit-on, « occupent toujours de l'espace dans la fenêtre de contexte du modèle », et si les jetons générés « atteignent la limite de la fenêtre de contexte ou la valeur max_output_tokens que vous avez définie », la réponse revient marquée comme incomplète. Une fenêtre partagée entre ce qui entre et ce qui sort est une fenêtre dans laquelle le plafond d'entrée correspond à la fenêtre moins la réservation de sortie.

Cette lecture est corroborée, non prouvée, et il vaut la peine de distinguer les deux. Ce qui est documenté, c'est une fenêtre de 1,050,000, un plafond de sortie de 128,000 et une entrée maximale de 922,000. Ce qui est déduit, c'est laquelle de ces limites est la contrainte qui se déclenche en premier. L'inférence tient pour toute requête qui réserve la totalité de son allocation de sortie et échoue pour toute requête qui ne le fait pas — fixez max_output_tokens à 4,000 et 1,046,000 jetons d'entrée ne sont pas manifestement refusés. Tant que le fournisseur n'inscrit pas la soustraction dans la page où figurent ces chiffres, considérez ce couple comme la forme du budget plutôt que comme une règle d'admission stricte, et validez auprès du point de terminaison de comptage plutôt qu'auprès d'un billet de blog.

Le contexte n'est pas un prix : l'étape des 272 000 tokens

Une fenêtre plus grande est une revendication de capacité. Ce n'est pas une revendication de coût, et dans cette famille, les deux se séparent à un seuil documenté. La page de tarification du fournisseur énonce la règle en une phrase : les invites de plus de 272K jetons d'entrée sont facturées à 2x les tarifs d'entrée et de cache et à 1,5x la sortie pour la requête complète. La définition de ses deux colonnes donnée sur la même page est « Contexte court : ≤272K jetons d'entrée. Contexte long : >272K jetons d'entrée. »

Lisez attentivement le mot full. Le palier ne taxe pas les tokens au-delà de la ligne — il re-tarife tout, y compris le premier token. Et ce n'est pas un changement de la 6.1 : la règle identique, avec le seuil identique, s'applique à GPT-6 Sol, c'est pourquoi la falaise doit être attribuée au palier et non à la version.

Traitez une tâche à long contexte des deux côtés, sur la base des tarifs publiés de GPT-6.1 Sol, avec le préfixe déjà résident en cache afin que les frais d’écriture du cache ne viennent pas fausser la comparaison :

• 240 000 tokens d'entrée (200 000 mis en cache, 40 000 non mis en cache), 6 000 en sortie — l'entrée non mise en cache de 40 000 à 2,00 $ par million coûte 0,080 $ ; l'entrée mise en cache de 200 000 à 0,10 $ coûte 0,020 $ ; la sortie de 6 000 à 10,00 $ coûte 0,060 $. Total, 0,160 $.

• 300 000 tokens d'entrée (260 000 en cache, 40 000 nouveaux), 6 000 en sortie — la requête est maintenant au-dessus du seuil, donc chaque tarif change : entrée nouvelle 40 000 à 4,00 $ donne 0,160 $ ; entrée en cache 260 000 à 0,20 $ donne 0,052 $ ; sortie 6 000 à 15,00 $ donne 0,090 $. Total : 0,302 $.

Vingt-cinq pour cent de jetons d’entrée en plus achètent une facture plus élevée de 89 pour cent. Exécutez la même paire sur GPT-6 Sol et la forme tient, avec une pente plus raide — 0,180 $ sous la ligne contre 0,354 $ au-dessus, parce que le tarif de cache de l’ancienne carte, à 0,20 $, se situe au même niveau que le tarif de cache en contexte long de la 6.1. Le franchissement est un palier, pas une pente, et la façon la moins chère de le constater est de le franchir d’un cheveu. Une requête de 271 000 jetons entièrement non mise en cache, avec 1 000 jetons de sortie, coûte 0,552 $ ; à 273 000, elle coûte 1,107 $. Sept dixièmes de pour cent de jetons d’entrée en plus, 2,01 fois le prix. Retirez 2 000 jetons de cette requête et la facture tombe de 1,107 $ à 0,552 $ — moins d’un pour cent de l’entrée pour la moitié du coût.

Rien dans cette section ne porte sur le fait que la fenêtre de GPT-6.1 Sol soit grande. Il s’agit du fait que la fenêtre soit suffisamment grande pour atteindre une limite dont le coût dépasse ce que la taille de la fenêtre permet d’acheter.

Qu’est-ce qui remplit réellement 1 050 000 jetons ?

Un budget de contexte se compose de six éléments, et ils ne sont pas tous également éligibles à la mise en cache. Répartition approximative d’une requête agentique illustrative de 240 000 jetons ; les proportions sont les nôtres, les règles de mise en cache sont celles du fournisseur, tirées de son guide de mise en cache des prompts consulté le jour même.

• Contenu système injecté par le fournisseur et formatage des requêtes — rendu avant vos messages, facturé comme entrée et explicitement exclu de la longueur minimale pouvant être mise en cache. Ce n'est pas à vous de le contrôler, ni à vous de le réduire.

• Vos instructions de développeur et système, environ 6 000 tokens. Mise en cache possible. C'est le début du préfixe, donc une modification ici invalide tout ce qui se trouve derrière.

• Définitions et schémas des outils, soit environ 14 000 tokens pour la surface d'outils hébergée, plus vos fonctions. Mise en cache possible, et la partie la plus fragile du préfixe : le guide répertorie les noms d'outils, les descriptions, les schémas, l'ordre et les instructions propres aux outils parmi les éléments qui déplacent la limite du préfixe.

• Le corpus récupéré, environ 180 000 tokens. Mise en cache possible, et de loin la ligne la plus volumineuse. Cela ne vaut la peine d'être mis en cache que s'il est stable au niveau des octets entre les appels — un corpus réassemblé à chaque requête est un corpus au prix plein.

• La transcription accumulée — les tours précédents et les résultats d'outils — environ 30 000 tokens et en augmentation. Mise en cache possible jusqu'à la modification la plus récente ; le résultat d'outil arrivé à ce tour est une entrée fraîche au tarif plein.

• Jetons de raisonnement — générés, jamais mis en cache, facturés en tant que sortie. Ils consomment de la fenêtre et sont invisibles dans le corps de la réponse.

Deux remarques opérationnelles découlent directement de cette liste. Premièrement, les entrées de cache sont conservées sur des machines individuelles : le guide indique qu'une requête ne peut réutiliser un préfixe « que si elle atteint une machine contenant une entrée correspondante qui n'a pas expiré », et que le routage de débordement commence au-delà d'environ 15 requêtes par minute. Un préfixe stable dans votre code peut tout de même ne pas être trouvé en production. Deuxièmement, le préfixe minimal pouvant être mis en cache est de 1 024 tokens d'entrée visibles, et les tokens système masqués ne comptent pas dans ce total — ainsi, un petit prompt système n'est pas un préfixe pouvant être mis en cache, quelle que soit la taille de la requête qui l'entoure.

Le plafond de sortie est un budget à part, pas une deuxième portion

128 000 tokens de sortie maximum ne signifie pas 128 000 tokens de réponse. Le guide de raisonnement indique explicitement que max_output_tokens plafonne le total que le modèle génère, « y compris les tokens de raisonnement, les tokens de sortie visibles et les tokens de mise en forme non visibles », et que les tokens de raisonnement sont facturés comme sortie tout en occupant de l’espace dans la fenêtre.

Cela fait de la troncature une décision de conception plutôt qu'un cas limite, en raison de la manière dont elle échoue. Lorsque la génération atteint la limite, la réponse revient avec un statut incomplete et un motif max_output_tokens — et le guide avertit que cela « peut se produire avant que le moindre token de sortie visible ne soit produit, ce qui signifie que vous pourriez engager des coûts pour des tokens d'entrée et de raisonnement sans recevoir de réponse visible ». Un budget qui dépense toute la fenêtre en entrée et laisse la réservation de sortie au hasard est un budget qui peut facturer une requête complète à long contexte et ne rien renvoyer qu'un appelant puisse analyser. la recommandation de départ du fournisseur lui-même est de réserver au moins 25 000 tokens pour le raisonnement et les sorties tant que vous êtes encore en train de mesurer ce dont une invite a réellement besoin.

GPT-6.1 Sol affine cela, et il s’agit de l’une des rares lignes véritablement spécifiques à la 6.1 dans cette version. Son échelle d’effort de raisonnement comporte low, medium, high, xhigh et max, et les réglages none et minimal ne sont pas pris en charge. GPT-6 Sol accepte les six. Il n’existe donc aucun réglage sur la 6.1 permettant de désactiver la dépense de raisonnement ; la valeur par défaut est medium, et le volet sortie du budget n’est jamais gratuit.

La réduction de moitié de l’entrée mise en cache, à lire là où la fenêtre est la plus large

Le seul tarif de la fiche GPT-6.1 Sol qui a évolué défavorablement par rapport à GPT-6 Sol est l'entrée en cache : de 0,20 $ à 0,10 $ par million de jetons, ce que la page du modèle exprime comme 5 % du tarif d'entrée non mise en cache, et que le guide de mise en cache du fournisseur désigne explicitement comme le cas 0,05x, contre le 0,1x que la plupart des modèles GPT-5.6 et ultérieurs appliquent. L'entrée, les écritures de cache et la sortie sont identiques sur les deux fiches, et les multiplicateurs de contexte long le sont aussi.

Pour exactement la charge de travail dont traite cette page, c’est bien le compteur qu’il fallait faire bouger, et la raison tient à la composition d’une longue requête plutôt qu’à sa taille. Sur la tâche de 300 000 jetons ci-dessus, 260 000 des jetons d’entrée sont un préfixe mis en cache — 87 % de tout ce que la requête envoie. La ligne mise en cache est donc le plus grand compteur d’entrée unique de la facture, ce qui est la propriété générale du travail à long contexte : plus la fenêtre que vous utilisez est longue, plus une grande partie de celle-ci est un préfixe que vous avez déjà envoyé. Réduire de moitié ce compteur représente 0,052 $ sur cette requête.

Et la falaise reprend plus que ce que la réduction de moitié donne, sur la même requête. Facturée aux tarifs de contexte court qu’elle aurait payés sous le seuil, la même tâche de 300 000 jetons sur GPT-6.1 Sol coûterait 0,166 $ au lieu de 0,302 $ — un coût de franchissement de 0,136 $, soit environ 2,6 fois ce que vaut l’unique tarif modifié de cette version. Au-dessus du seuil, le tarif en cache affiche 0,20 $, ce qui n’est pas un nouveau chiffre dans cette famille : c’est le double du tarif affiché sur la fiche 6.1 et exactement ce que GPT-6 Sol facturait pour une lecture en cache sous le seuil avant cette version. Une charge de travail en cache à contexte long encaisse le changement de tarif affiché puis le rend à la limite, et c’est la limite — pas le modèle — qui en est la cause.

Comment dimensionner un budget de contexte

En tant que procédure, dans l’ordre où les contraintes se lient :

• Comptez la requête, ne l’estimez pas. Envoyez en POST le payload exact — outils, images, fichiers et tout le reste — au point de terminaison input token count de l’API Responses. Le guide est sans détour sur la raison : le comptage inclut les jetons de formatage pour les rôles et limites des messages qui n’apparaissent jamais dans le texte que vous pouvez tokeniser localement, et les estimations locales comme le nombre de caractères divisé par quatre sont inexactes pour les images, les fichiers et les schémas.

• Réservez d'abord le côté sortie. Choisissez max_output_tokens en gardant à l'esprit qu'il couvre à la fois le raisonnement, la sortie visible et le formatage, et partez du tampon de 25 000 tokens du fournisseur plutôt que de zéro. Votre budget d'entrée correspond à la fenêtre moins cette réservation, et le chiffre de neuf cent vingt-deux est la version du fournisseur de la même soustraction.

• Chiffrez la demande des deux côtés de 272 000 avant de l'envoyer. L'écart est suffisamment important pour qu'une demande conçue pour tomber juste en dessous de la limite et une demande conçue pour tomber juste au-dessus constituent deux produits différents.

• Ordonnez le préfixe par stabilité. Les instructions, puis les schémas d’outils, puis le corpus, puis la transcription. Tout ce qui change entre les appels va à la fin, où cela coûte une correspondance de préfixe plutôt que le cache entier.

• Dépassez 1 024 tokens d'entrée visibles avant de compter sur un cache. En dessous de ce minimum, rien n'est mis en cache, et les tokens masqués du fournisseur ne comptent pas dans ce total.

• Vérifiez que la réutilisation est plausible. Un préfixe doit être réutilisé pendant la durée de vie du cache de 30 minutes et doit se retrouver sur la machine qui détient l’entrée ; ces deux points sont décrits dans le guide et aucun des deux n’est une propriété de votre code.

• Mesurez à nouveau après tout changement de modèle ou de paramètre. Passer à GPT-6.1 Sol supprime la position de raisonnement désactivé, ce qui modifie le nombre de tokens de raisonnement et donc le côté sortie du budget — et une modification de l'effort de raisonnement, des outils, du schéma de sortie structurée ou de la gestion du contexte peut aussi déplacer une limite de préfixe et vous faire perdre entièrement le tarif mis en cache.

• Décidez de ce qui se passe lorsque la tâche ne rétrécira pas. La compaction est l’échappatoire documentée : une requête Responses peut définir context_management avec un seuil de compaction, et le serveur remplace le contenu antérieur de la conversation par un élément de compaction opaque qui reporte l’état clé avec moins de tokens. C’est une décision budgétaire plutôt qu’un élagage gratuit, car le guide note que la compaction « peut empêcher la réutilisation à partir du premier token modifié » — une passe de compaction invalide le préfixe qui la précède.

L'arithmétique de cette page part de la génération que GPT-6.1 Sol remplace, et cet échelon est celui qui est appelable aujourd'hui : notre fiche pour openai/gpt-6-sol indique une fenêtre de contexte de 1 050 000 jetons avec 128 000 jetons de sortie maximale aux tarifs catalogue d'OpenAI avec une marge de 0 % — le prix du fournisseur est le prix affiché sur la page, et un changement tarifaire du fournisseur y est répercuté le jour même plutôt qu'à un renouvellement. Notre fiche ne comporte pas de champ d'entrée maximale qui lui soit propre, donc le chiffre de 922 000 jetons pour ce modèle doit venir de la documentation propre du fournisseur, ce que cette page a utilisé d'un bout à l'autre. Ce à quoi la fiche sert, c'est au dimensionnement : la fenêtre et le plafond de sortie qu'elle publie effectivement sont les deux nombres que la procédure budgétaire ci-dessus soustrait l'un de l'autre, et l'échelon en dessous est celui auquel vous pouvez réellement appliquer cette procédure tant que 6.1 est encore nouveau. Il se trouve à https://www.orcarouter.ai/models/openai/gpt-6-sol.