GPT-6.1 Sol vs GPT-6 Sol: Vad en vecka extra arbete gav – och vad den inte gav

Om du har GPT-6 Sol i produktion idag och försöker avgöra om GPT-6.1 Sol är värd en migrering, beror svaret helt och hållet på vilken av dina kostnader som är större – och de två modellerna är byggda så att svaret nästan aldrig är ”båda”. GPT-6 Sol släpptes den 22 september 2026 för $2,00 per miljon indatatoken, $0,20 cachade och $10,00 utdata. GPT-6.1 Sol släpptes den 29 september 2026 för $2,00 indata, $0,10 cachade och $10,00 utdata, med en leverantörsrapporterad förbättring på 6,4 procentenheter för komplexa mjukvaruutvecklingsuppgifter vid lägre resonemangsansträngning. Priserna för indata och utdata rörde sig inte. Cachningsfrekvensen halverades. Den enda ändrade raden är hela den finansiella kalkylen, och allt annat är ett förmågeargument som, vid den här tidpunkten i släppets liv, kommer från exakt en källa.

Tre saker förändrades. En av dem är en räkning.

Skala bort marknadsföringen, så är deltat mellan dessa två distributioner kort nog att hålla i huvudet.

• Cachad indata — 0,10 USD per miljon tokens på GPT-6.1 Sol jämfört med 0,20 USD på GPT-6 Sol. Uppmätt snarare än påstått, och den enda förändringen som visar sig som aritmetik.
• Förmåga, enligt leverantören — OpenAI rapporterar ett försprång på 6,4 punkter på DeepSWE v1.1 vid lägre resonemangsinsats och kostnad, mer än dubbelt så högt resultat på Terminal-Bench Science 0.1 vid maximal insats, sju punkter på OSWorld 2.0:s offline-uppsättning vid maximal insats, 4,8 punkter på AutomationBench vid medelinsats, och en sakfelsfrekvens som sjunker från 11,4 % till 7,7 % på en avsiktligt felinducerande promptuppsättning. Inget av det har reproducerats.
• Resonemangstrappa — GPT-6.1 Sol stöder low, medium, high, xhigh och max, och saknar stöd för none; GPT-6 Sol stöder alla sex. Detta är deltat som får kod att gå sönder, och det är det som ingen tar med i ett lanseringsinlägg.

Allt annat är identiskt eller tillräckligt nära: samma kontextfönster på 1 050 000 token, samma utdatatak på 128 000 token, samma cache-skrivningspris på 2,50 $, samma omprissättningströskel på 272K token över vilken en hel begäran debiteras med 2× indata och cache och 1,5× utdata, samma krav på Responses-API för verktygsanrop och samma avsaknad av stöd för finjustering. Kunskapsgränsen flyttades från den 20 april till den 30 april 2026 – tio dagar, vilket är en sådan siffra som säger hur mycket av en uppfräschning detta var snarare än en återuppbyggnad.

Varför cacheraden är värd mer än den ser ut att vara

En halverad cacheläsning är en märklig sak att inleda en produktuppdatering med, tills man tittar på hur agenttrafik faktiskt ser ut. En agentloop skickar om ett stabilt prefix – systemprompt, verktygsscheman, hämtad kontext, konversationshistorik – vid varje tur, och under en lång session debiteras samma prefix dussintals eller hundratals gånger. Det är trafiken där en cacheavgift slutar vara ett avrundningsfel och blir den dominerande posten på fakturan.

Räkna på siffrorna för en enda lång agentsession. Anta ett prefix på 120 000 token som återanvänds över 40 turer, alltså 4,8 miljoner cachade indatatoken per session, plus blygsamma 150 000 nya outputtoken. På GPT-6 Sol kostar de cachade läsningarna 0,96 $ och outputen 1,50 $ – ungefär 2,46 $ per session. På GPT-6.1 Sol kostar samma session 0,48 $ för cachade läsningar och samma 1,50 $ för output: cirka 1,98 $. Per session är skillnaden 48 cent, vilket inte är ett beslut. Multiplicera det med hundra tusen sessioner i månaden och det blir 48 000 $ – vilket är ett beslut.

Två förbehåll håller det ärligt. Cachelagrade läsningar debiteras bara till cachetaxan när prefixet faktiskt träffar, så din faktiska besparing är din träffrekvens gånger skillnaden, inte skillnaden i sig. Och prefixet måste ligga under 272 000 tokens för att standardtaxorna överhuvudtaget ska gälla: passerar du den gränsen omprissätts hela begäran till 2× för indata och cache och 1,5× för utdata, vilket kan dränka en besparing på 10 cent på prefixet. Sessioner med lång kontext är de där cache-matematiken minst sannolikt liknar broschyren.

Benchmark-gapet är verkligt, och det kommer från ett enda ställe

OpenAI:s lanseringsinlägg är ovanligt specifikt när det gäller sina utvärderingar, vilket är en poäng till dess fördel, och var och en av dessa siffror är leverantören som betygsätter sin egen modell, vilket är poängen emot. Mönstret är konsekvent: jämförelsen som får spridning är alltid mot GPT-6 Astra, och Astra-jämförelsen är alltid en kostnadsjämförelse. På DeepSWE v1.1 är påståendet att den matchar Astra till ungefär en femtedel av kostnaden. På GDP.pdf närmar den sig Astra:s absoluta framkant till ungefär en femtedel av kostnaden per uppgift. På OSWorld 2.0 ligger den inom 2,1 punkter från Astra till ungefär en sjundedel av kostnaden per uppgift. När det gäller faktakorrekthet ligger den inom 1,9 punkter från Astra till mindre än en femtedel av kostnaden per uppgift. Det är inte en slump i utformningen; det är produkttesen, och det är en tes om pris, inte om att vara ledande i förmåga.

Den enda platsen där OpenAI avstår från sin egen framing är värd att berömma: på Terminal-Bench Science 0.1 säger man klart och tydligt att GPT-6 Astra fortfarande har den högsta poängen bland de testade modellerna med 68,1 % och bör användas för den svåraste vetenskapliga forskningen. Ett lanseringsinlägg som talar om när du bör köpa det dyrare syskonet är ett lanseringsinlägg med viss disciplin i sig.

Specifikt mot GPT-6 Sol är det ärliga läget för jämförelsen följande — det finns ingen oberoende poäng för någon av modellerna i den här konfigurationen. Artificial Analysis har en fullständig utvärdering av GPT-6 Sol vid maximal resonemangsansträngning: ett Intelligence Index på 48, 1,06 USD per indexuppgift, 77 miljoner genererade utdatatokens, jämfört med en median för resultattavlan på 88 miljoner, och ett Coding Agent Index på 57 vid 2,99 USD per uppgift. Den har ingen post för GPT-6.1 Sol alls per den 30 september; modellens slug ger 404 och strängen förekommer inte i den aktiva resultattavlan. Så den enda uppmätta jämförelsen från tredje part som finns tillgänglig i dag är mellan GPT-6 Sol och andra labbs modeller — inte mellan GPT-6 Sol och dess egen efterföljare. Den som visar dig ett diagram över 6.1 mot 6.0 just nu visar dig OpenAI:s slide.

Migreringen är en strängändring, förutom när den inte är det.

OpenAI:s egen migreringsvägledning för GPT-6-familjen är värd att läsa innan du byter ut identifieraren, eftersom två punkter i den får fungerande kod att gå sönder. Den första är resonemangstrappan: om någon begäran skickar reasoning_effort: "none", avvisar GPT-6.1 Sol den, och den dokumenterade lösningen är att börja på low och jämföra på representativa uppgifter i stället för att anta att den lägsta inställningen är likvärdig. Arbetsflöden som använde none som latensbaslinje förlorar den baslinjen. Den andra är verktygsanrop: GPT-6.1 Sol stöder Chat Completions men inte verktygsanrop genom det – verktyg kräver Responses API. Om din stack anropar funktioner på /v1/chat/completions, byter du inte ut en sträng, du porterar en slutpunkt. Leverantörens egen instruktion till utvecklare som redan använder GPT-6 Sol är att granska den vägledningen innan de byter, vilket är en rimlig signal om att detta inte är den drop-in-uppdatering som enveckasglappet antyder.

De återstående parametrarna beter sig så här: reasoning effort, strukturerade utdata, streaming, prompt-cachning och verktygsuppsättningen följer alla med, och samma omprissättningsregel på 272K gäller identiskt för båda modellerna. Ställ in model på gpt-6.1-sol, behåll din effort-inställning där den stöddes, och ta bort temperature, top_p och top_logprobs närhelst effort inte är none — den sista gäller båda modellerna och är en vanlig orsak till 400-fel efter varje migrering av en reasoning-modell.

Migrera utan att satsa en produktionsväg på det

Den realistiska migreringen är inte en cutover, det är en skuggkörning: skicka en del av produktionstrafiken till den nya identifieraren, behåll den gamla som den väg som svarar, och jämför på din egen trafik. Det är ett routingproblem, och det är den enda platsen där plattformen du anropar via förändrar arbetets utformning. OrcaRouter tillhandahåller GPT-6 Sol idag till OpenAIs eget listpris utan något påslag — $2,00 / $0,20 / $10,00-kortet, med 272K-omprissättningsregeln inkluderad — så jämförelsens basarm är live på samma nyckel som allt annat, och 6.1-armen kan läggas till i ruttuppsättningen så snart den går att anropa, utan ett andra avtal eller ett andra SDK. Fram till dess är den ärliga hållningen att GPT-6 Sol är den modell som går att anropa, och det är värt att säga rakt ut i stället för att antyda något annat: openai/gpt-6.1-sol returnerar "model not found" på vår publika katalog-slutpunkt idag. Automatisk failover är det som gör skuggkörningen säker när den väl är på plats — om den nya rutten ger fel slutförs begäran på den gamla, och du får reda på det från loggarna i stället för från dina användare.

Vem bör byta nu: team vars kostnader domineras av cachad indata i långa agentsessioner, och team vars arbetsflöden redan använder Responses API och aldrig skickar none. För dem är detta nära nog en gratis uppgradering – leverantören rapporterar kapacitetsvinsterna, cachefrekvensen halveras och migreringen är en enda sträng. Vem bör vänta: team med none i en latenskritisk väg, team vars verktygsanrop går via Chat Completions, och alla som behöver en siffra från någon utanför OpenAI innan de binder sig. För den sista gruppen har väntan inget publicerat slutdatum, och det kloka att göra med tiden är att bygga den eval-uppsättning som jämförelsen kommer att behöva – för när den oberoende poängen kommer, kommer den att gälla någon annans trafik.