GPT-6.1 Sol-kontextfönster: 1 050 000 tokens, 922 000-linjen och 272 000-stupet

Leverantörens modellsida för GPT-6.1 Sol, läst den 7 oktober 2026, anger ett kontextfönster på 1 050 000 token och en maximal utdata på 128 000 token. Samma sida, i den maskinläsbara form som du får genom att lägga till .md i dess URL, innehåller en tredje uppgift som den renderade sidan aldrig visar: maximalt 922 000 indata-token. GPT-6 Sol, modellen som 6.1 släpptes den 29 september 2026 för att efterträda, publicerar samma par av takvärden på sin egen sida, och samma rad med 922 000 i sin egen markdown-form. Vårt eget modellkort för openai/gpt-6-sol anger fönstret som 1 050 000 token och utdatataket som 128 000, visar den första av dessa som "1M" i sin specifikationsrad, och skriver "1.1M" för samma modell i en jämförelsetabell längre ner på samma sida.

Så sidorna är faktiskt inte överens, och det är värt att vara precis om hur de skiljer sig. Leverantörens renderade specifikationsrad ger ett fönster och ett tak för utdata och inget tak för indata. Leverantörens markdown-dokumentation för samma modell ger alla tre. Den som dimensionerar en begäran utifrån den renderade sidan arbetar med en begränsning färre än vad leverantören publicerade, och den saknade är talet som avgör om en begäran får plats.

Tre siffror, tre källor och en subtraktion som ingen skriver ner

Här är var och en med dokumentet den kom ifrån, alla lästa den 7 oktober 2026.

• 1 050 000 kontextfönster — leverantörens modellsida för gpt-6.1-sol, i den renderade specifikationsremsan och i dess markdown-form, och samma siffra på sidan för gpt-6-sol. Det är också vad vår katalog returnerar för openai/gpt-6-sol och openai/gpt-6-luna, där fältet är angivet som 1 050 000 i stället för avrundat.

• maximalt 128 000 utdatatokens — samma sida, samma två formulär, för båda generationerna. Fältet på vårt kort anger 128 000; visningen avrundar till "128K".

• maximalt 922 000 indatatokens — markdown-formen av leverantörens modellsida för gpt-6-sol och av dess sida för gpt-6.1-sol. Den finns inte i den renderade remsan på någon av sidorna, och den finns inte i vårt katalogfält för modellen, som slutar vid fönstret och utdatataket.

De tre talen är aritmetiskt förenliga med varandra: 922 000 plus 128 000 är exakt 1 050 000. Leverantörens egen resonemangsguide beskriver mekanismen som gör identiteten meningsfull utan att någonsin utföra additionen på modellsidan – resonemangstoken, säger den, ”upptar fortfarande utrymme i modellens kontextfönster”, och om genererade token ”når gränsen för kontextfönstret eller det max_output_tokens-värde du har angett”, kommer svaret tillbaka markerat som ofullständigt. Ett fönster som delas mellan det som går in och det som kommer ut är ett fönster där taket för indata är fönstret minus reservationen för utdata.

Den tolkningen stöds, men är inte bevisad, och det är värt att hålla isär de två. Det som är dokumenterat är ett fönster på 1 050 000, ett tak för utdata på 128 000 och en maximal indata på 922 000. Det som är härlett är vilken av dessa som är den begränsning som slår till först. Slutsatsen gäller för varje begäran som reserverar hela sin utdatakvot och fallerar för varje begäran som inte gör det – sätt max_output_tokens till 4 000 och 1 046 000 indatatokens avvisas inte uppenbart. Fram till dess att leverantören skriver in subtraktionen på sidan där siffrorna bor, behandla parkopplingen som budgetens form snarare än som en hård antagningsregel, och validera mot räkningsslutpunkten i stället för mot ett blogginlägg.

Kontext är inte ett pris: steget på 272 000 token

Ett större fönster är ett kapacitetsanspråk. Det är inte ett kostnadsanspråk, och i den här familjen skiljer sig de två åt vid en dokumenterad gräns. Leverantörens prissida anger regeln i en mening: prompter med fler än 272K indatatoken prissätts med 2x indata- och cachepriser och 1,5x utdata för hela förfrågan. Samma sidas egen definition av sina två kolumner är "Kort kontext: ≤272K indatatoken. Lång kontext: >272K indatatoken."

Läs ordet full noggrant. Nivån beskattar inte tokens efter linjen — den omprissätter allt, inklusive den första token. Och det är inte en 6.1-ändring: den identiska regeln, med den identiska tröskeln, gäller för GPT-6 Sol, vilket är varför stupet måste tillskrivas nivån och inte utgåvan.

Kör ett långkontextjobb genom båda sidorna, enligt GPT-6.1 Sols publicerade priser, med prefixet redan kvar i cachen så att cache-skrivningsavgiften inte grumlar jämförelsen:

• 240 000 indatatoken (200 000 cachade, 40 000 nya), 6 000 utdata — ny indata 40 000 till $2,00 per miljon är $0,080; cachad indata 200 000 till $0,10 är $0,020; utdata 6 000 till $10,00 är $0,060. Totalt $0,160.

• 300 000 indatatokens (260 000 cachade, 40 000 nya), 6 000 utdata — begäran ligger nu över gränsen, så varje pris ändras: nya indata 40 000 till 4,00 $ är 0,160 $; cachade indata 260 000 till 0,20 $ är 0,052 $; utdata 6 000 till 15,00 $ är 0,090 $. Totalt 0,302 $.

Tjugofem procent fler indatatokens ger en 89 procent större räkning. Kör samma par på GPT-6 Sol och formen håller i sig med en brantare lutning – $0,180 under linjen mot $0,354 över den, eftersom det äldre kortets cache-pris på $0,20 ligger på samma plats som 6.1:s cache-pris för lång kontext gör. Övergången är ett steg, inte en lutning, och det billigaste sättet att se det är att korsa den med en hårsmån. En helt ocachad begäran på 271 000 tokens med 1 000 utdatatokens kostar $0,552; vid 273 000 kostar den $1,107. 0,7 procent fler indatatokens, 2,01 gånger kostnaden. Skala bort 2 000 tokens från den begäran och räkningen faller från $1,107 till $0,552 – mindre än en procent av indata för halva kostnaden.

Inget i det här avsnittet handlar om att GPT-6.1 Sols fönster är stort. Det handlar om att fönstret är tillräckligt stort för att nå en gräns som kostar mer än vad fönstrets storlek köper.

Vad fyller egentligen 1 050 000 tokens

En kontextbudget består av sex saker, och de är inte lika cachebara. Ungefärliga andelar av en illustrativ agentisk begäran på 240 000 token; proportionerna är våra egna, cachebarhetsreglerna är leverantörens, från dess guide för prompt-cachning läst samma dag.

• Leverantörsinjicerat systeminnehåll och begäransformatering — renderas före dina meddelanden, faktureras som indata och undantas uttryckligen från den minsta cachelagringsbara längden. Inte ditt att styra, och inte ditt att trimma.

• Dina utvecklar- och systeminstruktioner, cirka 6 000 token. Går att cachelagra. Detta är början av prefixet, så en ändring här ogiltigförklarar allt som ligger bakom det.

• Verktygsdefinitioner och scheman, omkring 14 000 tokens för den värdbaserade verktygsytan plus dina funktioner. Cachebart, och den mest ömtåliga delen av prefixet: guiden listar verktygsnamn, beskrivningar, scheman, ordning och verktygsspecifika instruktioner som saker som flyttar prefixgränsen.

• Den hämtade korpusen, cirka 180 000 tokens. Cachebar och den överlägset största raden. Den är bara värd att cachelagra om den är byte-stabil mellan anrop — en korpus som sätts samman på nytt för varje begäran är en fullpriskorpus.

• Den ackumulerade transkriptionen – tidigare vändor och verktygsresultat – cirka 30 000 tokens och stigande. Kan cachas fram till den senaste ändringen; det verktygsresultat som kom in i den här vändan är ny indata till full taxa.

• Reasoning tokens — genereras, cachelagras aldrig, debiteras som utdata. De förbrukar kontextfönstret och är osynliga i svarskroppen.

Två operativa noteringar följer direkt ur den listan. För det första lagras cacheposter på enskilda maskiner: guiden säger att en begäran kan återanvända ett prefix "endast om den når en maskin som har en matchande post som inte har gått ut", och att överflödesroutning börjar vid fler än ungefär 15 förfrågningar per minut. Ett prefix som är stabilt i din kod kan ändå bli en cachemiss i produktion. För det andra är det minsta cachebara prefixet 1 024 synliga indatatoken, och dolda systemtoken räknas inte in i det — så en liten systemprompt är inte ett cachebart prefix, hur stor begäran runt den än är.

Utdatataket är en separat budget, inte en andra portion.

128 000 maximala utdatatokens betyder inte 128 000 tokens svar. Resonemangsguiden är tydlig med att max_output_tokens begränsar det totala antalet som modellen genererar, ”inklusive resonemangstokens, synliga utdatatokens och icke-synliga formateringstokens”, och att resonemangstokens faktureras som utdata samtidigt som de upptar plats i fönstret.

Det gör trunkering till ett designbeslut snarare än ett gränsfall, på grund av hur det misslyckas. När genereringen når gränsen returneras svaret med statusen incomplete och orsaken max_output_tokens – och guiden varnar för att detta "kan inträffa innan några synliga utdatatokens har producerats, vilket innebär att du kan få kostnader för indata- och resonemangstokens utan att få ett synligt svar." En budget som spenderar hela fönstret på indata och lämnar utdatareservationen åt slumpen är en budget som kan debitera en fullständig begäran med lång kontext och returnera ingenting som en anropare kan tolka. Leverantörens egen inledande rekommendation är att reservera minst 25 000 tokens för resonemang och utdata medan du fortfarande mäter vad en prompt faktiskt behöver.

GPT-6.1 Sol skärper detta, och det är en av de få genuint 6.1-specifika raderna i utgåvan. Dess nivåskala för resonemangsinsats omfattar low, medium, high, xhigh och max, och inställningarna none och minimal stöds inte. GPT-6 Sol accepterar alla sex. Det finns därför ingen inställning på 6.1 som stänger av resonemangskostnaden, standard är medium, och utdatasidan av budgeten är aldrig gratis.

Halveringen av cachad indata, läst där fönstret är som bredast.

Den enda taxa på GPT-6.1 Sol-kortet som har ändrats till nackdel jämfört med GPT-6 Sol är cachad indata: $0,20 ned till $0,10 per miljon token, vilket modellsidan uttrycker som 5 % av taxan för icke-cachad indata, och som leverantörens cachingguide uttryckligen anger som 0,05x-fallet mot 0,1x som de flesta modeller från GPT-5.6 och framåt ligger på. Indata, cache-skrivningar och utdata är identiska på båda korten, och multiplikatorerna för lång kontext är också identiska.

För exakt den arbetsbelastning som den här sidan handlar om är det rätt mätare att ha ändrat, och anledningen är sammansättningen av en lång begäran snarare än dess storlek. I jobbet på 300 000 tokens ovan är 260 000 av indatatoken ett cachat prefix – 87 procent av allt som begäran skickar. Den cachade raden är därför den största enskilda indatamätaren i räkningen, vilket är den allmänna egenskapen hos arbete med lång kontext: ju längre fönster du använder, desto mer av det är ett prefix som du redan har skickat. Att halvera den mätaren är värt 0,052 USD på den begäran.

Och klippan tar tillbaka mer än vad halveringen ger, på samma begäran. Prisatt enligt kortkontextsatserna skulle det ha betalat under linjen; samma jobb på 300 000 token på GPT-6.1 Sol skulle kosta 0,166 USD i stället för 0,302 USD — en passeringskostnad på 0,136 USD, eller ungefär 2,6 gånger vad den enda ändrade mätaren i släppet är värd. Ovanför linjen står det cachade priset på 0,20 USD, vilket inte är en ny siffra i den här familjen: det är dubbelt så mycket som rubrikpriset på 6.1-kortet och exakt vad GPT-6 Sol tog för en cachad läsning under linjen före detta släpp. En cachad arbetsbelastning med lång kontext plockar upp ändringen av rubrikpriset och lämnar sedan tillbaka den vid gränsen, och gränsen — inte modellen — är orsaken.

Hur man dimensionerar en kontextbudget

Som en procedur, i den ordning som begränsningarna binder:

• Räkna förfrågan, uppskatta den inte.POST:a den exakta nyttolasten – verktyg, bilder, filer och allt – till slutpunkten för räkning av indatatoken på Responses API. Guiden är tydlig med varför: räkningen inkluderar formateringstoken för meddelanderoller och gränser som aldrig visas i det du kan tokenisera lokalt, och lokala tumregler som tecken dividerat med fyra är felaktiga för bilder, filer och scheman.

• Reservera utdatasidan först. Välj max_output_tokens och kom ihåg att det omfattar resonemang, synlig utdata och formatering tillsammans, och utgå från leverantörens buffert på 25 000 token snarare än från noll. Din indatabudget är fönstret minus den reserverade delen, och siffran niohundratjugotvå är leverantörens version av samma subtraktion.

• Prissätt begäran på båda sidor om 272 000 innan du skickar den. Steget är tillräckligt stort för att en begäran som är utformad för att hamna precis under gränsen och en begäran som är utformad för att hamna precis över den är olika produkter.

• Ordna prefixet efter stabilitet. Instruktioner, sedan verktygsscheman, sedan korpusen, sedan transkriptet. Allt som ändras mellan anrop hör hemma i slutet, där det kostar en prefixmatchning i stället för hela cachen.

• Passera 1 024 synliga indatatokens innan du kan förvänta dig en cache. Under det minimumet cachas ingenting, och dolda leverantörstokens räknas inte in.

• Kontrollera att återanvändning är trolig. Ett prefix måste återanvändas inom cachens livstid på 30 minuter och måste hamna på den maskin som håller posten; båda beskrivs i guiden och ingendera är en egenskap hos din kod.

• Mät om efter varje modell- eller inställningsändring. Att byta till GPT-6.1 Sol tar bort läget för avstängt resonemang, vilket ändrar antalet resonemangstoken och därmed utdatasidan av budgeten – och en ändring av resonemangsansträngning, verktyg, schema för strukturerad utdata eller kontexthantering kan också flytta en prefixgräns och göra att du helt förlorar den cachade taxan.

• Bestäm vad som händer när jobbet inte kan krympas. Kompaktering är den dokumenterade utvägen: en Responses-begäran kan ange context_management med en kompakteringströskel, och servern ersätter tidigare konversationsinnehåll med ett ogenomskinligt kompakteringsobjekt som för vidare centralt tillstånd med färre tokens. Det är ett budgetbeslut snarare än en kostnadsfri nedbantning, eftersom guiden noterar att kompaktering "kan förhindra återanvändning från den första ändrade tokenen och framåt" – en kompakteringskörning ogiltigförklarar prefixet bakom den.

Aritmetiken på den här sidan utgår från den generation som GPT-6.1 Sol ersätter, och det steget är det som går att anropa i dag: vårt kort för openai/gpt-6-sol rapporterar ett kontextfönster på 1 050 000 tokens med 128 000 tokens maximal utdata till OpenAI:s listpriser med 0 % påslag — leverantörens pris är priset på sidan, och en leverantörsändring slår igenom där samma dag i stället för vid en förnyelse. Vårt kort har inget eget fält för maximal indata, så siffran 922 000 tokens för den modellen måste komma från leverantörens egen dokumentation, vilket är vad den här sidan har använt hela tiden. Vad kortet är användbart för är dimensionering: fönstret och det tak för utdata som det faktiskt publicerar är de två tal som budgetproceduren ovan subtraherar från varandra, och steget nedanför är det du faktiskt kan köra den proceduren mot medan 6.1 fortfarande är nytt. Den finns på https://www.orcarouter.ai/models/openai/gpt-6-sol.