GPT-6.1 Sol-contextvenster: 1.050.000 tokens, de 922.000-regel en de 272.000-klif

De modelpagina van de leverancier voor GPT-6.1 Sol, gelezen op 7 oktober 2026, vermeldt een contextvenster van 1.050.000 tokens en een maximale output van 128.000 tokens. Dezelfde pagina, in de machineleesbare vorm die je krijgt door .md aan de URL toe te voegen, bevat een derde cijfer dat de gerenderde pagina nooit weergeeft: een maximum van 922.000 invoertokens. GPT-6 Sol, het model dat 6.1 op 2026-09-29 moest opvolgen, publiceert het identieke paar plafondcijfers op zijn eigen pagina, en dezelfde regel van 922.000 in zijn eigen markdownvorm. Onze eigen modelkaart voor openai/gpt-6-sol rapporteert het venster als 1.050.000 tokens en de outputlimiet als 128.000, toont de eerste daarvan als "1M" in de specificatiestrook, en vermeldt "1.1M" voor hetzelfde model in een vergelijkingstabel verderop op dezelfde pagina.

Dus de pagina's verschillen inderdaad van elkaar, en het is de moeite waard precies te zijn over hoe. De gerenderde specificatiestrook van de leverancier geeft een venster en een uitvoerplafond en geen invoerplafond. De markdown-documentatie van de leverancier voor hetzelfde model geeft alle drie. Wie een aanvraag afstemt op de gerenderde pagina, werkt met één beperking minder dan de leverancier heeft gepubliceerd, en de ontbrekende is het getal dat bepaalt of een aanvraag erin past.

Drie cijfers, drie bronnen, en één aftrekking die niemand opschrijft

Hier is elk nummer met het document waar het vandaan komt, allemaal gelezen op 7 oktober 2026.

• 1.050.000 contextvenster — de modelpagina van de leverancier voor gpt-6.1-sol, in de weergegeven specificatiestrook en in de markdownvorm ervan, en hetzelfde cijfer op de pagina voor gpt-6-sol. Het is ook wat onze catalogus retourneert voor openai/gpt-6-sol en openai/gpt-6-luna, waar het veld als 1.050.000 is ingevuld in plaats van afgerond.

• maximaal 128.000 uitvoertokens — dezelfde pagina, dezelfde twee formulieren, voor beide generaties. Het veld op onze kaart zegt 128.000; de weergave rondt af naar "128K".

• 922.000 maximale invoertokens — de markdownvorm van de modelpagina van de gpt-6-sol van de leverancier en van diens gpt-6.1-sol-pagina. Het staat niet in de gerenderde strook van een van beide pagina's, en het staat niet in ons catalogusveld voor het model, dat ophoudt bij het venster en de uitvoerlimiet.

De drie getallen zijn rekenkundig met elkaar consistent: 922.000 plus 128.000 is precies 1.050.000. De eigen redeneergids van de leverancier beschrijft het mechanisme dat de gelijkheid betekenisvol maakt zonder ooit de som op de modelpagina te maken — redeneertokens, staat er, "nemen nog steeds ruimte in het contextvenster van het model in", en als gegenereerde tokens "de limiet van het contextvenster of de max_output_tokens-waarde die je hebt ingesteld bereiken", komt het antwoord gemarkeerd als onvolledig terug. Een venster dat wordt gedeeld tussen wat erin gaat en wat eruit komt, is een venster waarin het invoerplafond het venster minus de uitvoerreservering is.

Die interpretatie wordt gestaafd, niet bewezen, en het is de moeite waard die twee te scheiden. Wat gedocumenteerd is, is een venster van 1.050.000, een uitvoerplafond van 128.000 en een maximale invoer van 922.000. Wat wordt afgeleid, is welke daarvan de beperking is die het eerst toeslaat. De gevolgtrekking geldt voor elk verzoek dat zijn volledige uitvoertoelage reserveert en gaat niet op voor elk verzoek dat zijn volledige uitvoertoelage niet reserveert — stel max_output_tokens in op 4.000, en 1.000.000 invoertokens worden niet duidelijk geweigerd. Totdat de leverancier de aftrekking opneemt in de pagina waar de cijfers staan, beschouw de combinatie als de vorm van de vorm in plaats van als een harde toelatingsregel, en valideer tegen het counting-endpoint in plaats van tegen een blogpost.

Context is geen: de 272.000-stap

Een groter venster is een capaciteitsclaim. Het is geen kostenclaim, en in deze familie vallen de twee uiteen bij een gedocumenteerde grens. De prijspagina van de leverancier vermeldt de regel in één zin: prompts met meer dan 272K invoertokens worden voor het volledige verzoek geprijsd tegen 2x de invoer- en cachetarieven en 1,5x de uitvoer. De eigen definitie van de twee kolommen op dezelfde pagina is: "Korte context: ≤272K invoertokens. Lange context: >272K invoertokens."

Lees het woord full aandachtig. De tier belast de tokens voorbij de grens niet — hij herprijst alles, inclusief het eerste token. En het is geen 6.1-wijziging: de identieke regel, met de identieke drempel, geldt voor GPT-6 Sol, en daarom moet de cliff aan de tier worden toegeschreven en niet aan de release.

Voer één long-contexttaak uit aan beide zijden, tegen de gepubliceerde tarieven van GPT-6.1 Sol, met de prefix al in de cache aanwezig, zodat de cache-schrijfkosten de vergelijking niet vertroebelen:

• 240.000 invoertokens (200.000 in cache, 40.000 nieuw), 6.000 uitvoer — nieuwe invoer 40.000 tegen $2,00 per miljoen is $0,080; invoer uit cache 200.000 tegen $0,10 is $0,020; uitvoer 6.000 tegen $10,00 is $0,060. Totaal: $0,160.

• 300.000 invoertokens (260.000 in cache, 40.000 nieuw), 6.000 uitvoer — het verzoek zit nu boven de grens, dus elk tarief verschuift: nieuwe invoer 40.000 tegen $4,00 is $0,160; gecachte invoer 260.000 tegen $0,20 is $0,052; uitvoer 6.000 tegen $15,00 is $0,090. Totaal: $0,302.

Vijfentwintig procent meer invoertokens levert een 89 procent hogere rekening op. Voer hetzelfde paar uit op GPT-6 Sol en de vorm blijft behouden, met een steilere helling — $0,180 onder de lijn tegenover $0,354 erboven, omdat het cachetarief van $0,20 van de oudere kaart op dezelfde plek zit als het long-context cachetarief van 6.1. De overgang is een stap, geen helling, en de goedkoopste manier om dat te zien is er op een haar na overheen te gaan. Een volledig niet-gecachte aanvraag van 271.000 tokens met 1.000 outputtokens kost $0,552; bij 273.000 kost die $1,107. Zeven tienden van een procent meer invoertokens, 2,01 keer zoveel geld. Haal 2.000 tokens weer van die aanvraag af en de rekening daalt van $1,107 naar $0,552 — minder dan één procent van de invoer voor de helft van de kosten.

Niets in dit gedeelte gaat erover dat het venster van GPT-6.1 Sol groot is. Het gaat erover dat het venster groot genoeg is om een grens te bereiken die meer kost dan wat de grootte van het venster oplevert.

Wat vult eigenlijk 1.050.000 tokens?

Een contextbudget bestaat uit zes onderdelen, en ze zijn niet in gelijke mate cachebaar. Geschatte aandelen van een illustratief agentisch verzoek van 240.000 tokens; de verhoudingen zijn van ons, de cachebaarheidsregels zijn van de leverancier, uit zijn gids voor prompt-caching die dezelfde dag is gelezen.

• Door de provider geïnjecteerde systeeminhoud en verzoekopmaak — weergegeven vóór je berichten, gefactureerd als invoer, en expliciet uitgesloten van de minimale cachebare lengte. Niet iets wat jij kunt beheren, en niet iets wat jij kunt inkorten.

• Je ontwikkelaars- en systeeminstructies, ongeveer 6.000 tokens. Cachebaar. Dit is het begin van het prefix, dus een wijziging hier maakt alles erachter ongeldig.

• Tooldefinities en schema's, ongeveer 14.000 tokens voor het gehoste tooloppervlak plus je functies. Cachebaar, en het meest kwetsbare deel van het prefix: de gids noemt toolnamen, beschrijvingen, schema's, ordening en toolspecifieke instructies als zaken die de prefixgrens verleggen.

• Het opgehaalde corpus, ongeveer 180.000 tokens. Cachebaar, en veruit de grootste regel. Het is alleen het cachen waard als het byte-stabiel is tussen aanroepen — een corpus dat per verzoek opnieuw wordt samengesteld is een corpus dat de volle prijs kost.

• Het opgebouwde transcript — eerdere beurten en toolresultaten — ongeveer 30.000 tokens en groeiend. Cachebaar tot de nieuwste wijziging; het toolresultaat dat in deze beurt binnenkwam, is verse invoer tegen het volledige tarief.

• Reasoning-tokens — gegenereerd, nooit gecachet, gefactureerd als output. Ze verbruiken contextvenster en zijn onzichtbaar in de responsbody.

Twee operationele opmerkingen vloeien rechtstreeks uit die lijst voort. Ten eerste worden cache-items op afzonderlijke machines bewaard: de gids zegt dat een verzoek een prefix alleen kan hergebruiken "als het een machine bereikt die een overeenkomend item bevat dat niet is verlopen", en dat overflow-routing begint boven ongeveer 15 verzoeken per minuut. Een prefix die in je code stabiel is, kan in productie alsnog missen. Ten tweede is de minimale cachebare prefix 1.024 zichtbare invoertokens, en verborgen systeemtokens tellen daar niet voor mee — dus een kleine systeemprompt is geen cachebare prefix, ongeacht hoe groot het omringende verzoek is.

Het outputplafond is een apart budget, geen tweede portie.

128.000 maximale uitvoertokens betekent niet 128.000 tokens aan antwoord. De gids over redeneren vermeldt expliciet dat max_output_tokens het totaal begrenst dat het model genereert, "inclusief redeneertokens, zichtbare uitvoertokens en niet-zichtbare opmaaktokens", en dat redeneertokens als uitvoer worden gefactureerd terwijl ze ruimte innemen in het venster.

Dat maakt truncatie een ontwerpbeslissing in plaats van een randgeval, vanwege de manier waarop het faalt. Wanneer de generatie de limiet bereikt, komt het antwoord terug met de status 'incomplete' en de reden 'max_output_tokens' — en de gids waarschuwt dat dit "zich kan voordoen voordat er zichtbare uitvoertokens worden geproduceerd, wat betekent dat je kosten kunt maken voor invoer- en redeneertokens zonder een zichtbaar antwoord te ontvangen." Een budget dat het hele venster aan invoer besteedt en de reservering voor uitvoer aan het toeval overlaat, is een budget dat een volledig long-contextverzoek in rekening kan brengen en niets kan teruggeven dat een aanroeper kan parsen. De eigen initiële aanbeveling van de leverancier is om ten minste 25.000 tokens te reserveren voor redenering en uitvoer terwijl je nog meet wat een prompt daadwerkelijk nodig heeft.

GPT-6.1 Sol scherpt dit aan, en het is een van de weinige echt 6.1-specifieke regels in de release. De ladder voor redeneerinspanning kent low, medium, high, xhigh en max, en de instellingen none en minimal worden niet ondersteund. GPT-6 Sol accepteert alle zes. Er is daarom geen instelling op 6.1 die het redeneerbudget uitschakelt, de standaardwaarde is medium, en de outputzijde van het budget is nooit gratis.

De halvering van de gecachte invoer, gelezen waar het venster het breedst is.

Het enige tarief op de GPT-6.1 Sol-kaart dat ten opzichte van GPT-6 Sol is gewijzigd, is gecachte invoer: $0,20 omlaag naar $0,10 per miljoen tokens, wat de modelpagina uitdrukt als 5% van het tarief voor niet-gecachte invoer, en wat de cachinggids van de leverancier expliciet het 0,05x-geval noemt tegenover de 0,1x die de meeste GPT-5.6 en latere modellen hanteren. Invoer, cacheschrijfacties en uitvoer zijn identiek op beide kaarten, en de vermenigvuldigingsfactoren voor lange context zijn ook identiek.

Voor precies de workload waar deze pagina over gaat, is dat de juiste meter om te hebben verplaatst, en de reden is de samenstelling van een lang verzoek, niet de grootte ervan. Bij de taak van 300.000 tokens hierboven zijn 260.000 van de invoertokens een gecachte prefix — 87 procent van alles wat het verzoek verstuurt. De gecachte regel is daarom de grootste afzonderlijke invoermeter op de factuur, wat de algemene eigenschap is van werk met een lange context: hoe langer het venster dat je gebruikt, hoe meer ervan een prefix is die je al hebt verzonden. Die meter halveren is $0,052 waard bij dat verzoek.

En de cliff neemt meer terug dan de halvering oplevert, bij hetzelfde verzoek. Afgerekend tegen de tarieven voor korte context die het onder de lijn zou hebben betaald, zou dezelfde taak van 300.000 tokens op GPT-6.1 Sol $0,166 kosten in plaats van $0,302 — een kostenpost van $0,136 voor het overschrijden van de grens, of ongeveer 2,6 keer wat de ene gewijzigde meter in deze release waard is. Boven de lijn bedraagt het cachetarief $0,20, wat geen nieuw getal is voor deze familie: het is het dubbele van het hoofdtarief op de 6.1-kaart en precies wat GPT-6 Sol onder de lijn in rekening bracht voor een gecachte leesactie vóór deze release. Een gecachte workload met lange context ontvangt de verandering in het hoofdtarief en geeft die vervolgens terug bij de grens, en de grens — niet het model — is de oorzaak.

Hoe bepaal je de grootte van een contextbudget?

Als procedure, in de volgorde waarin de beperkingen binden:

• Tel het verzoek, schat het niet. POST de exacte payload — tools, afbeeldingen, bestanden en al het overige — naar het eindpunt voor het tellen van invoertokens van de Responses API. De gids is bot over waarom: de telling bevat opmaaktokens voor berichtrollen en -grenzen die nooit voorkomen in tekst die je lokaal kunt tokeniseren, en lokale schattingen zoals het aantal tekens gedeeld door vier zijn onnauwkeurig voor afbeeldingen, bestanden en schema's.

• Reserveer eerst de uitvoerzijde. Kies max_output_tokens en houd er rekening mee dat dit redenering, zichtbare uitvoer en opmaak samen omvat, en begin vanaf de buffer van 25.000 tokens van de leverancier in plaats van vanaf nul. Je invoerbudget is het venster minus die reservering, en het getal negenhonderdtweeëntwintig is de versie van de leverancier van dezelfde aftrekking.

• Beprijs het verzoek aan beide zijden van 272.000 voordat je het verstuurt. De stap is groot genoeg dat een verzoek dat net onder de grens moet uitkomen en een verzoek dat net daarboven moet uitkomen verschillende producten zijn.

• Orden de prefix op stabiliteit. Instructies, dan tool-schema's, dan het corpus, dan het transcript. Alles wat tussen aanroepen verandert, hoort achteraan, waar het een prefix-match kost in plaats van de hele cache.

• Overschrijd 1.024 zichtbare invoertokens voordat je een cache kunt verwachten.Onder dat minimum wordt niets gecachet, en verborgen providertokens tellen daar niet voor mee.

• Controleer of hergebruik plausibel is. Een prefix moet binnen de cachelevensduur van 30 minuten opnieuw worden gebruikt en moet terechtkomen op de machine waar de prefix zich bevindt; beide worden in de handleiding beschreven en geen van beide is een eigenschap van je code.

• Meet opnieuw na elke wijziging van model of instelling. Overstappen naar GPT-6.1 Sol verwijdert de positie 'reasoning uit', waardoor het aantal reasoningtokens verandert en dus de uitvoerzijde van het budget — en een wijziging van reasoning effort, tools, schema voor gestructureerde uitvoer of contextbeheer kan ook een prefixgrens verschuiven en je het volledige gecachte tarief kosten.

• Bepaal wat er gebeurt wanneer de taak niet kleiner wordt. Compaction is de gedocumenteerde uitweg: een Responses-verzoek kan context_management instellen met een compact-drempelwaarde, en de server vervangt eerdere gespreksinhoud door een ondoorzichtig compactie-item dat de belangrijkste status met minder tokens doorgeeft. Het is een budgetbeslissing en niet een gratis trim, omdat de gids opmerkt dat compactie "hergebruik vanaf de eerste gewijzigde token kan verhinderen" — een compactieronde maakt het prefix erachter ongeldig.

De rekensom op deze pagina begint bij de generatie die GPT-6.1 Sol vervangt, en die trede is degene die vandaag aanroepbaar is: onze kaart voor openai/gpt-6-sol vermeldt een contextvenster van 1.050.000 tokens met 128.000 tokens maximale uitvoer tegen de lijsttarieven van OpenAI met 0% opslag — de prijs van de leverancier is de prijs op de pagina, en een prijswijziging van de leverancier komt daar dezelfde dag terecht, niet pas bij een verlenging. Onze kaart heeft zelf geen veld voor maximale invoer, dus het cijfer van 922.000 tokens voor dat model moet uit de eigen documentatie van de leverancier komen, en dat is wat deze pagina steeds heeft gebruikt. Waar de kaart nuttig voor is, is het bepalen van de grootte: het venster en het uitvoerplafond die hij wel publiceert, zijn de twee getallen die de bovenstaande budgetprocedure van elkaar aftrekt, en de trede eronder is degene waarop je die procedure daadwerkelijk kunt uitvoeren terwijl 6.1 nog nieuw is. De kaart staat op https://www.orcarouter.ai/models/openai/gpt-6-sol.