GPT-6.1 Sols standardkontext har just gått från 272K till 500K i Codex: vad det förändrar, och vad det inte gör

GPT-6.1 Sol — mellanklassmodellen som släpptes den 29 september 2026 till 2,00 USD per miljon indatatoken och 10,00 USD per miljon utdatatoken — fick sin förvalda kontextlängd i Codex och ChatGPT Work höjd från 272 000 token till 500 000 den 12 oktober 2026, en ökning som leverantören uppskattar till ungefär 80 procent. Thibault Sottiaux, företagets produkt- och plattformschef, tillkännagav det som dag 7 av företagets 28 dagar långa leveranssprint, beskrev 500 000 som en grundligt testad "sweet spot" och sade att standardvärdet skulle höjas igen i framtiden. Maximumet är orört och detsamma gäller GPT-6 Sol, den generation som 6.1 ersatte, vars publicerade tak den här ärvde oförändrade.

Det är hela tillkännagivandet, och det är lätt att läsa förbi de två ord som gör jobbet. Standard, inte max. Codex och ChatGPT Work, inte API:et. Modellen har kunnat ta emot långt mer än 500 000 tokens sedan den släpptes – siffran som ändrades är den du får när du inte ber om något.

Allt nedan är läst från leverantörens egen dokumentation om modeller och priser och från dess tillkännagivande, båda från 2026-10-12, eller är aritmetik på de satser den publicerar. När en siffra är leverantörens egen och ingen utanför har reproducerat den, står det i meningen som innehåller den.

Deltat, specificerat

Sex saker är värda att hålla isär, eftersom tre av dem flyttade och tre inte.

• Standardkontext i Codex och ChatGPT Work — 272 000 tokens före 2026-10-12, 500 000 efter. Detta är talet som gäller när en begäran inte anger något.

• Maximal kontext – oförändrad. Leverantörens modellsida för GPT-6.1 Sol listar ett fönster på 1 050 000 token, maximal indata på 922 000 token och ett utdatatak på 128 000 token. Siffrorna är identiska på sidan för GPT-6 Sol.

• Manuell överstyrning — oförändrad. Användare kan fortfarande ställa in arbetskontexten högre eller lägre än standardvärdet, upp till modellens egen övre gräns, vilket är anledningen till att inget av detta tar bort ett alternativ som redan fanns.

• Prenumerationstillägget för lång kontext — togs bort för GPT-6.1 Sol, uttryckligen "under ChatGPT-prenumerationskvoter." Detta är klausulen med pengar kopplade till sig, och den är begränsad till användning som hämtas från en ChatGPT-plan.

• API-standardvärden och API-prissättning — oförändrat. API:et tillhör dig, inte en klients standardtabell, och långpromptmultiplikatorn på prissättningssidan står fortfarande kvar precis som den gjorde före tillkännagivandet.

• 1M-taket — ingen förändring, men värt att notera eftersom en standard på 500 000 token förbrukar 54 procent av det maximala indatautrymmet på 922 000 token. ”Det ryms inom 1M” och ”det ryms under standardvärdet” är nu två olika frågor med ett glapp på 422 000 token mellan dem.

Det enda talet i listan som en läsare kan agera på i dag är därför inte 500 000. Det är befrielsen från tilläggsavgiften – och bara om deras användning faktureras mot en prenumeration i stället för en API-nyckel.

Tilläggsavgiften är den del som ändrar en räkning

Räknar man på leverantörens publicerade API-priser är formen på problemet som undantaget gäller uppenbar. GPT-6.1 Sols angivna priser är 2,00 USD per miljon indatatokens, 0,10 USD per miljon cachade indatatokens och 10,00 USD per miljon utdatatokens. Prompter över 272 000 indatatokens prissätts med 2x indata- och cache-priser och 1,5x utdata för hela begäran — inte bara för tokens bortom gränsen.

• 270 000 icke-cachade indatatoken, 10 000 utdata — indata 270 000 till $2,00 är $0,540; utdata 10 000 till $10,00 är $0,100. Totalt $0,640.

• 300 000 indatatoken utan cache, 10 000 utdata — begäran överskrider gränsen, så varje pris ändras: indata 300 000 till $4,00 är $1,200; utdata 10 000 till $15,00 är $0,150. Totalt: $1,350.

Elva procent fler indatatokens, 2,1 gånger notan. Steget är det som gör ett större standardvärde till en verklig fråga i stället för en gratis uppgradering, och det är steget som leverantören just tog bort från prenumerationssidan för den här modellen. Med en API-nyckel finns det fortfarande kvar, vid exakt samma tröskel, opåverkat av något som tillkännagavs den 12 oktober 2026.

Om du anropar modellen via OrcaRouter är den gränsen leverantörens och följer med den: vi tillhandahåller openai/gpt-6.1-sol till leverantörens listpriser med 0 % påslag, så $2.00 / $0.10 / $10.00-kortet och multiplikatorn på 272 000 token ovanför det är samma siffror som du skulle se på leverantörens egen sida, och en ändring på endera sidan slår igenom hos oss samma dag i stället för vid ett omprissättningsfönster. Det vi inte gör är att ändra leverantörens prisnivå. Om en begäran passerar 272 000 indatatoken på en API-nyckel omprissätts den, oavsett vem som routade den.

Var det nya standardvärdet faktiskt finns

Tillkännagivandet nämner två ytor, och distinktionen spelar större roll än det låter. Codex och ChatGPT Work är de agentiska produkterna; GPT-6.1 Sol finns inte i vanliga ChatGPT-chatten. Så standardvärdet på 500 000 token når de personer som kör långa kodningsloopar och dokumenttunga arbetspass, och når ingen som anropar modellen från ett skript.

Det finns ett andra lager under det. En klient som ansluter till modellen via ChatGPT-prenumerationsuppgifter har inte samma utformning som en klient som ansluter med en API-nyckel – den har en budgettabell som begränsar vilka modeller som är behöriga, så att användning som hämtas från en prenumeration motsvarar vad Codex självt tillåter. En kodningsklient med öppen källkod, OpenCode, slog samma dag samman en ändring i sin ChatGPT-OAuth-anslutning och höjde sin post för gpt-6.1-sol från 272 000 till 500 000 indatatoken mot ett kontexttak på 628 000 token, "bevarar det befintliga utdatautrymmet på 128k." Granskarens anteckning är den ärliga sammanfattningen av hela tillkännagivandet: endast standardgränserna för den här modellen på den anslutningen ändrades, det publika API:et är oförändrat, och modellspecifika konfigurationsöverskridanden gäller fortfarande.

Det där är en tredjepartsklients tolkning av hur gränserna tillämpas, inte ett leverantörsdokument, och det är värt att märkas som just det. Men det stämmer med tillkännagivandets egen inramning: leverantören höjde ett standardvärde som den kontrollerar, på de ytor där den sätter standardvärdet, och lämnade API:et där anroparen bestämmer.

Varför leverantören flyttade standardvärdet i stället för taket

Det angivna skälet är kompaktering. När en långkörande Codex-session närmar sig sin arbetskontext kondenserar harnessen tidigare vändor – sammanfattar och kastar bort detaljer – så att sessionen kan fortsätta. Kompaktering är inte dataförlust i kraschbemärkelse; det är ett medvetet byte av detaljtrohet mot utrymme, och det utlöses oftare ju mindre standardvärdet är. Att höja standardvärdet till 500 000 tokens innebär att utlösaren inträffar senare för just de uppgifter som har störst behov av bevarande: refaktoreringar över flera filer, långa felsökningsförlopp, arbete som bär en stor hämtad korpus över många vändor.

Det är också därför tillkännagivandet handlar om en standardinställning snarare än en gräns. En maxgräns hjälper bara en anropare som känner till gränsen och ställer in den; en standardinställning hjälper varje anropare, inklusive de som aldrig har konfigurerat något. För en produkt vars användare till stor del är interaktiva är det den ratt som ger större effekt. Det är leverantörens egen motivering, och den är rimlig vid första anblicken – den mätbara delen av påståendet är att färre komprimeringar sker, vilket är ett beteende hos testramen snarare än en modellförmåga, och själva modellen har inte ändrats. Samma ögonblicksbild, samma taxor, samma utdatagräns på 128 000 tokens, samma kunskapsgräns: 2026-04-30.

Argumentet mot, framfört som åsikt

Reaktionerna från praktiker var inte enhälligt positiva, och invändningarna är värda att ta med eftersom de är testbara påståenden, inte vibbar. En utvecklare kallade offentligt ändringen för en anti-funktion av två skäl: prenumerationskvoter kommer att förbrukas snabbare om sessioner rutinmässigt kör längre innan kompaktering, och kvaliteten på nål-i-höstack-sökning är sannolikt inte lika bra vid 500 000 tokens som vid 272 000, så det extra utrymmet är kanske inte användbart utrymme. Andra framförde den närliggande poängen att ett större fönster är en kapacitet, inte en rekommendation – att fylla det med löst relevanta filer späder ut uppmärksamheten och gör svaren långsammare.

Det här är communitypositioner, inte leverantörsvägledning, och leverantörens motargument ligger implicit i ordet "sweet spot": värdet testades och valdes för såväl upplevelse som förmåga. Men de två frågorna pekar på olika saker och bör hållas isär. Kvotfrågan är en redovisningsfråga – om din plan mäter tokens innebär ett längre standardvärde fler tokens innan kompakteringens skyddsnät slår in. Kvalitetsfrågan är en utvärderingsfråga, och den kan bara besvaras på det enda sätt som dessa frågor någonsin kan besvaras: kör din egen långkontextuppgift i båda storlekarna och jämför, i stället för att utgå från inramningen i antingen tillkännagivandet eller en svarstråd.

Vad du bör kontrollera innan du litar på det nya numret

• Vilken yta du befinner dig på.Codex eller ChatGPT Work som faktureras via prenumeration får 500 000 som standard och ingen tilläggsavgift för lång kontext. En API-nyckel får ingetdera – ingen ändrad standard, och multiplikatorn på 272 000 token gäller fortfarande.

• Huruvida din harness skickar en explicit gräns. En klient som hårdkodar ett kontextvärde åsidosätter helt det nya standardvärdet. Kontrollera konfigurationen innan du utgår från att höjningen nådde dig, eftersom åtgärden kan vara en rad i dina egna inställningar snarare än något som leverantören har släppt.

• Hur taken samverkar. En ChatGPT-OAuth-anslutning från tredje part kan visa en egen tabell — fallet med OpenCode ovan kombinerar en indatakvot på 500 000 tokens med ett kontexttak på 628 000 tokens och lämnar 128 000 tokens i utrymme för utdata. Om din klient tillhör den kategorin, verifiera dess siffra i stället för annonsens.

• Oavsett om din faktura är en prenumeration eller en mätare. Eftergiften av tilläggsavgiften är en förändring på prenumerationssidan. API-nivån är orörd, så en kostnadsmodell byggd på API:et har inget nytt i sig.

• Huruvida du bör fylla fönstret. Standardvärdet är vad du får; det är inte ett mål. Cachad indata för 0,10 USD per miljon mot 2,00 USD ocachad är den hävstång som faktiskt sänker en räkning för lång kontext, och den belönar byte-stabila prefix snarare än större.

Den öppna frågan

Leverantören har sagt att standardvärdet kommer att höjas igen, vilket gör 500 000 till en vägpunkt snarare än en destination – och gör att den intressanta frågan inte är om talet växer, utan om de två begränsningarna runt det flyttar med. Tröskeln på 272 000 token för omprissättning ligger nu under det nya standardvärdet, vilket innebär att en prenumerationsfakturerad session som når upp till sitt standardvärde enligt API:ets regler skulle vara en long-context-begäran; undantaget är det som gör att det inte spelar någon roll på prenumerationssidan, och inget som tillkännagavs den 2026-10-12 tyder på att API-tröskeln följer standardvärdet uppåt. Håll koll på den tröskeln, inte på fönstret.

För ett team som redan bygger på GPT-6.1 Sol är den praktiska tolkningen snäv och tydlig. Om du använder Codex eller ChatGPT Work via en prenumeration får du mer utrymme innan komprimering och en rad mindre på räkningen, från och med nu. Om du anropar API:et har ingenting ändrats, och siffran som är värd att hålla koll på är fortfarande 272 000. Vår modellsida för openai/gpt-6.1-sol — kontext på 1 050 000 token, utdata på 128 000 token, $2,00 in och $10,00 ut — är där det priset ligger kvar.