Le contexte par défaut de GPT-6.1 Sol vient de passer de 272K à 500K dans Codex : ce que cela change, et ce que cela ne change pas

GPT-6.1 Sol — le modèle de milieu de gamme sorti le 29 septembre 2026 à 2,00 $ par million de jetons d'entrée et 10,00 $ par million de jetons de sortie — a vu sa longueur de contexte par défaut dans Codex et ChatGPT Work passer de 272 000 à 500 000 jetons le 12 octobre 2026, une augmentation que le fournisseur estime à environ 80 %. Thibault Sottiaux, responsable des produits et de la plateforme de l'entreprise, l'a annoncée comme le jour 7 du sprint de livraison de 28 jours de la société, a qualifié les 500 000 de « point idéal » amplement testé et a déclaré que la valeur par défaut serait de nouveau relevée à l'avenir. Le maximum reste inchangé, tout comme GPT-6 Sol, la génération que la 6.1 a remplacée, dont les plafonds publiés ont été repris sans changement.

Voilà toute l'annonce, et il est facile de passer à côté des deux mots qui font le travail. Par défaut, pas le maximum. Codex et ChatGPT Work, pas l'API. Le modèle est capable d'accepter bien plus de 500 000 tokens depuis son lancement — le chiffre qui a bougé est celui que vous obtenez quand vous ne demandez rien.

Tout ce qui suit est tiré de la documentation du fournisseur sur son propre modèle et sa tarification ainsi que de son annonce, toutes deux datées du 12 octobre 2026, ou résulte de calculs arithmétiques effectués sur les tarifs qu'il publie. Lorsqu'un chiffre provient du fournisseur lui-même et que personne de l'extérieur ne l'a reproduit, la phrase qui le contient le précise.

Le delta, détaillé

Six choses méritent d'être distinguées, car trois d'entre elles ont bougé et trois non.

• Contexte par défaut dans Codex et ChatGPT Work — 272 000 tokens avant le 2026-10-12, 500 000 après. C'est le nombre qui s'applique lorsqu'une requête n'en précise aucun.

• Contexte maximal — inchangé. La page du modèle du fournisseur pour GPT-6.1 Sol indique une fenêtre de 1 050 000 jetons, une entrée maximale de 922 000 jetons et un plafond de sortie de 128 000 jetons. Ces chiffres sont identiques sur la page de GPT-6 Sol.

• Forçage manuel — inchangé. Les utilisateurs peuvent toujours définir le contexte de travail au-dessus ou en dessous de la valeur par défaut, jusqu'au plafond propre au modèle, c'est pourquoi rien de tout cela ne supprime une option qui existait déjà.

• La surtaxe d'abonnement pour le contexte long — supprimée pour GPT-6.1 Sol, explicitement « dans le cadre des quotas d'abonnement ChatGPT ». C'est la clause qui comporte des frais, et elle est limitée à l'usage provenant d'un forfait ChatGPT.

• Valeurs par défaut de l'API et tarification de l'API — sans changement. L'API vous appartient, pas à la table par défaut d'un client, et le multiplicateur pour les prompts longs sur la page de tarification se lit toujours comme avant l'annonce.

• Le plafond de 1 M — inchangé, mais il vaut la peine de le préciser, car une valeur par défaut de 500 000 tokens consomme 54 % de l'allocation maximale d'entrée de 922 000 tokens. « Ça tient dans 1 M » et « ça tient sous la valeur par défaut » sont désormais deux questions distinctes, avec un écart de 422 000 tokens entre les deux.

Le seul chiffre de la liste sur lequel un lecteur peut agir aujourd’hui n’est donc pas 500 000. C’est l’exonération de la surcharge — et uniquement si leur utilisation est facturée sur un abonnement plutôt que sur une clé API.

Le supplément est la partie qui modifie une facture

Faites le calcul sur les tarifs API publiés du fournisseur et la nature du problème auquel la dérogation s'attaque est évidente. Les tarifs indiqués de GPT-6.1 Sol sont de 2,00 $ par million de jetons d'entrée, 0,10 $ par million de jetons d'entrée mis en cache et 10,00 $ par million de jetons de sortie. Les prompts dépassant 272 000 jetons d'entrée sont facturés à 2x les tarifs d'entrée et de cache et à 1,5x le tarif de sortie pour la requête complète — pas seulement pour les jetons au-delà de la limite.

• 270 000 jetons d'entrée non mis en cache, 10 000 en sortie — entrée : 270 000 à 2,00 $ = 0,540 $ ; sortie : 10 000 à 10,00 $ = 0,100 $. Total : 0,640 $.

• 300 000 jetons d'entrée non mis en cache, 10 000 en sortie — la requête dépasse la limite, donc tous les tarifs changent : entrée 300 000 à 4,00 $, soit 1,200 $ ; sortie 10 000 à 15,00 $, soit 0,150 $. Total, 1,350 $.

Onze pour cent de jetons d’entrée en plus, une facture multipliée par 2,1. Le palier, c’est ce qui fait qu’une valeur par défaut plus élevée devient une véritable question plutôt qu’une mise à niveau gratuite, et c’est le palier que le fournisseur vient de retirer du côté abonnement pour ce modèle. Avec une clé API, il est toujours là, exactement au même seuil, inchangé par quoi que ce soit annoncé le 2026-10-12.

Si vous appelez le modèle via OrcaRouter, cette frontière est celle du fournisseur et voyage avec elle : nous servons openai/gpt-6.1-sol aux tarifs catalogue du fournisseur, avec 0 % de marge, donc la grille 2,00 $ / 0,10 $ / 10,00 $ et le multiplicateur de 272 000 tokens au-dessus sont exactement les mêmes chiffres que ceux que vous verriez sur le site du fournisseur lui-même, et une modification des tarifs d'un côté comme de l'autre intervient le jour même, dans une fenêtre de re-tarification. Ce qui change, c'est le fournisseur. Si une requête dépasse 272 000 tokens d'entrée sur une clé API, elle est re-tarifée, quel que soit celui qui l'a routée.

Où se trouve réellement le nouveau paramètre par défaut

L’annonce nomme deux surfaces, et la distinction compte plus qu’elle n’en a l’air. Codex et ChatGPT Work sont les produits agentiques ; GPT-6.1 Sol ne figure pas dans le chat ChatGPT standard. Ainsi, la valeur par défaut de 500 000 tokens touche les personnes qui font tourner de longues boucles de codage et des sessions de travail riches en documents, et ne touche personne qui appelle le modèle depuis un script.

Il y a une deuxième couche en dessous. Un client qui se connecte au modèle avec des identifiants d’abonnement ChatGPT n’a pas la même forme qu’un client qui se connecte avec une clé API — il porte une table budgétaire qui plafonne les modèles éligibles afin que l’usage tiré d’un abonnement corresponde à ce que Codex autorise lui-même. Un client de codage open source, OpenCode, a fusionné une modification de sa connexion ChatGPT-OAuth le jour même, relevant son entrée pour gpt-6.1-sol de 272 000 à 500 000 jetons d’entrée face à un plafond de contexte de 628 000 jetons, « préservant la marge de sortie existante de 128k ». La note de son relecteur est le résumé honnête de toute l’annonce : seules les limites par défaut pour ce modèle sur cette connexion ont changé, l’API publique est inchangée, et les surcharges de configuration par modèle s’appliquent toujours.

C’est la lecture d’un client tiers sur la manière dont les plafonds sont appliqués, pas un document du fournisseur, et il vaut la peine de le signaler comme tel. Mais cela correspond au cadrage de l’annonce elle-même : le fournisseur a relevé une valeur par défaut qu’il contrôle, sur les surfaces où il définit cette valeur par défaut, et a laissé l’API là où l’appelant décide.

Pourquoi l'éditeur a déplacé la valeur par défaut au lieu du plafond

La raison invoquée est la compaction. Lorsqu’une longue session Codex approche de son contexte de travail, le harnais condense les tours précédents — en résumant et en supprimant des détails — pour que la session puisse continuer. La compaction n’est pas une perte de données au sens de plantage ; c’est un compromis délibéré entre fidélité et marge de manœuvre, et elle se déclenche d’autant plus souvent que la valeur par défaut est faible. Relever la valeur par défaut à 500 000 tokens signifie que le déclencheur intervient plus tard, précisément sur les tâches qui ont le plus besoin de rétention : refactorisations multi-fichiers, longues séquences de débogage, travaux transportant un vaste corpus récupéré sur de nombreux tours.

C'est aussi pourquoi l'annonce porte sur une valeur par défaut plutôt que sur une limite. Un maximum n'aide qu'un appelant qui connaît la limite et la définit ; une valeur par défaut aide tous les appelants, y compris ceux qui n'ont jamais rien configuré. Pour un produit dont les utilisateurs sont en grande partie interactifs, c'est le levier au plus fort impact. C'est l'argumentation du fournisseur lui-même, et elle est raisonnable à première vue — la moitié mesurable de l'affirmation est qu'il y a moins de compactions, ce qui relève du comportement du harnais plutôt que d'une capacité du modèle, et le modèle lui-même n'a pas changé. Même snapshot, mêmes tarifs, même plafond de sortie de 128 000 tokens, même date d'arrêt des connaissances du 2026-04-30.

L'argument contre, formulé comme une opinion

La réaction des praticiens n'a pas été uniformément positive, et les objections méritent d'être reprises, car ce sont des affirmations testables, pas des impressions. Un développeur a publiquement qualifié ce changement d'anti-fonctionnalité pour deux raisons : les quotas d'abonnement seront consommés plus rapidement si les sessions durent régulièrement plus longtemps avant la compaction, et la qualité de récupération de type « aiguille dans une botte de foin » ne sera probablement pas aussi bonne à 500 000 tokens qu'à 272 000, donc l'espace supplémentaire n'est peut-être pas de l'espace utilisable. D'autres ont fait valoir le point connexe qu'une fenêtre plus grande est une capacité, pas une recommandation — la remplir de fichiers vaguement pertinents dilue l'attention et ralentit les réponses.

Ce sont des positions de la communauté, et non des recommandations du fournisseur, et la réponse du fournisseur est implicite dans l'expression « sweet spot » : la valeur a été testée et choisie pour l'expérience autant que pour la capacité. Mais ces deux préoccupations portent sur des choses différentes et doivent être séparées. Le point sur le quota est une question de comptabilité — si votre forfait compte les tokens, une valeur par défaut plus longue signifie plus de tokens avant que le filet de sécurité de la compaction n'entre en jeu. Le point sur la qualité est une question d'évaluation, et il n'y a qu'une seule façon d'y répondre, comme pour toutes ces questions : exécutez votre propre tâche à long contexte aux deux tailles et comparez, plutôt que d'adopter le cadrage de l'annonce ou celui d'un fil de réponses.

Ce qu'il faut vérifier avant de se fier au nouveau numéro

• L'interface que vous utilisez. Codex ou ChatGPT Work facturés via un abonnement obtiennent 500 000 par défaut et aucun supplément pour le contexte long. Une clé API n'obtient ni l'un ni l'autre — pas de modification du paramètre par défaut, et le multiplicateur de 272 000 jetons s'applique toujours.

• Que votre harnais envoie une limite explicite ou non.Un client qui code en dur une valeur de contexte remplace entièrement la nouvelle valeur par défaut. Vérifiez la configuration avant de supposer que l’augmentation vous est parvenue, car le correctif peut être une ligne dans vos propres paramètres plutôt que quoi que ce soit livré par le fournisseur.

• Comment les plafonds se composent. Une connexion ChatGPT-OAuth tierce peut présenter son propre tableau — le cas OpenCode ci-dessus associe une allocation d'entrée de 500 000 jetons à un plafond de contexte de 628 000 jetons et laisse 128 000 jetons de marge de sortie. Si votre client appartient à cette catégorie, vérifiez son chiffre plutôt que celui de l'annonce.

• Que votre facture soit un abonnement ou un compteur. L'exonération de surcharge est un changement côté abonnement. Le palier API est inchangé, donc un modèle de coûts basé sur l'API n'a rien de nouveau.

• Si vous devez remplir la fenêtre. La valeur par défaut est ce que vous obtenez ; ce n'est pas un objectif. L'entrée mise en cache à 0,10 $ par million contre 2,00 $ sans cache est le levier qui fait réellement baisser une facture de contexte long, et elle récompense les préfixes stables en octets plutôt que les préfixes plus volumineux.

La question ouverte

Le fournisseur a dit que la valeur par défaut augmentera encore, ce qui fait de 500 000 une étape plutôt qu’une destination — et fait que la question intéressante n’est pas de savoir si le nombre augmente, mais si les deux contraintes qui l’entourent évoluent avec lui. Le seuil de re-tarification de 272 000 jetons se situe désormais sous la nouvelle valeur par défaut, ce qui signifie qu’une session facturée au titre de l’abonnement qui atteint sa valeur par défaut selon les règles de l’API serait une requête à contexte long ; c’est la dérogation qui empêche que cela ait de l’importance du côté de l’abonnement, et rien de ce qui a été annoncé le 2026-10-12 ne suggère que le seuil de l’API suive la valeur par défaut à la hausse. Surveillez ce seuil, pas la fenêtre.

Pour une équipe qui développe déjà sur GPT-6.1 Sol, la lecture pratique est étroite et claire. Si vous êtes sur Codex ou ChatGPT Work avec un abonnement, vous disposez de plus de marge avant la compaction et d’une ligne de moins sur la facture, dès maintenant. Si vous appelez l’API, rien n’a changé, et le chiffre à surveiller reste 272 000. Notre page de modèle pour openai/gpt-6.1-sol — contexte de 1 050 000 tokens, sortie de 128 000 tokens, 2,00 $ en entrée et 10,00 $ en sortie — est l’endroit où cela reste tarifé.