GPT-6.1 vs GPT-6.1 Sol: Ett av dessa två namn är inte en modell

Sök efter en direkt jämförelse mellan G​PT-6.1 och G​PT-6.1 Sol och du hittar sidor som jämför två saker som inte är två saker. Modellistan från O​penAI har en post under 6.1-generationen, och dess identifierare är gpt-6.1-sol. Det finns ingen syskonmodell som heter gpt-6.1, ingen basvariant, ingen mini, ingen pro. "G​PT-6.1" är generationsetiketten på lådan; G​PT-6.1 Sol är det som finns i lådan. Jämförelsen som faktiskt kostar folk pengar är G​PT-6.1 Sol mot G​PT-6 Sol, nivån som den ersatte tre veckor tidigare – samma listpris på $2 och $10, annat cachepris, annan indexpoäng och ett utfasningsmeddelande som ligger på den äldre. De dokumenterade AI-felen och agentincidenterna bakom releaser som den här samlas i OrcaRouter AI Incident Archive där varje post har sina egna källor, allvarlighetsgrad, konfidensgrad och flagga för omstridd status.

Den här sidan gör två saker. Den avgör namnfrågan med hjälp av bevisen, eftersom ett felaktigt namn ger en 404 i loggarna i stället för ett sämre svar. Sedan genomför den jämförelsen som namnet antyder men katalogen inte stöder, eftersom det är beslutet som alla som skrev den första frågan står inför.

Vad händer när du skickar fel sträng?

Inget elegant. En begäran som namnger en modell som API:et inte listar misslyckas i routningslagret, innan någon token debiteras, och felet är model-not-found i stället för en återgång till närmaste matchning. På OpenAI:s eget API är det slutet på saken. På en router är felläget åtminstone synligt: OrcaRouters katalog innehåller openai/gpt-6.1-sol och innehåller inte enbart openai/gpt-6.1, så en felstavning dyker upp som en saknad rutt i stället för att tyst landa på en annan nivå och producera svar till ett annat pris.

Den distinktionen spelar större roll än den låter. De två vanligaste versionerna av det här misstaget är en trunkerad identifierare och en med mellanslag — gpt-6.1 där gpt-6.1-sol var avsett, eller G​PT 6.1 Sol inklistrat från ett pressmeddelande i ett konfigvärde. Den första är en 404; den andra är en 404 som framstår som ett behörighetsproblem om man skummar. Båda är billiga att åtgärda och dyra att diagnostisera klockan 2 på natten, vilket är hela argumentet för att låsa modellsträngar i en enda konfigfil och aldrig i applikationskoden.

• Korrekt identifierare — gpt-6.1-sol på leverantörens API, openai/gpt-6.1-sol på OrcaRouter

• Generationsetikett, inte en identifierare — "G​PT-6.1", som förekommer i dokumentation och marknadsföring men inte motsvarar något

• Vad etiketten antyder och listan inte gör — en familj av nivåer, varav exakt en existerar

Varför 6.1-uppdateringen har exakt en medlem

O​penAI släppte G​PT-6-generationen i tre vågor och förnyade en av nivåerna i den. G​PT-6 Astra anlände den 3 september 2026 högst upp i modelltrappan. G​PT-6 Sol och G​PT-6 Luna anlände den 22 september som mellannivå respektive volymnivå. Sedan, den 29 september, landade 6.1-uppdateringen enbart på Sol-nivån – G​PT-6.1 Sol, positionerad för komplex kodning och professionellt arbete, med ett kontextfönster på 1 050 000 token och ett sänkt pris för cachad indata från $0.20 till $0.10 per miljon token.

Astra och Luna återlanserades inte. Det är därför som "G​PT-6.1 vs G​PT-6.1 Sol" låter som en match mellan en familj och en medlem: för en generation, den här gången, är de samma uppsättning. Om du letar efter det billigare 6.1-syskonet att skicka högvolymsarbete till, finns det inget — volymnivån är fortfarande G​PT-6 Luna, fortfarande på 6.0-numreringen, fortfarande $0.10 och $0.50 per miljon tokens.

Namngivningen är inte godtycklig, och det är den delen som är värd att ta till sig. En generationssiffra i ett modellnamn markerar en uppdatering av den nivån, inte en ny familj. När en leverantör uppdaterar en nivå beskriver generationsbeteckningen kortvarigt en mängd med ett enda element – och varje artikel, konfigurationsfil och upphandlingsdokument som skrivs utifrån enbart beteckningen får en felaktig mental modell. Läs modellistan, inte rubriken i tillkännagivandet.

GPT-6.1 Sol mot nivån den ersatte

Jämförelsen som folk faktiskt behöver, utifrån siffrorna som varje källa publicerar. Leverantörsspecifikation från O​penAI:s utvecklardokumentation; indexpoäng och tider från Artificial Analysis, lästa den 21 oktober 2026, enligt index v4.3.2.

• Pris — identiskt: G​PT-6.1 Sol 2,00 $ in / 10,00 $ ut per miljon; G​PT-6 Sol 2,00 $ in / 10,00 $ ut per miljon

• Cachad indata — G​PT-6.1 Sol 0,10 USD per miljon; G​PT-6 Sol 0,20 USD per miljon

• Kontext — G​PT-6.1 Sol 1 050 000 tokens; G​PT-6 Sol 1 050 000 tokens

• Intelligensindex — G​PT-6.1 Sol 52; G​PT-6 Sol 48, en skillnad på fyra poäng vid samma listpris

• Kostnad per indextask — G​PT-6.1 Sol $0.72; G​PT-6 Sol $1.04

• Utdatashastighet — GPT-6.1 Sol 55,2 token per sekund; GPT-6 Sol är den långsammare av de två på samma kort

• Ekonomi för långa prompter — GPT-6.1 Sol över 272 000 indatatoken: indata och cache till 2×, utdata till 1,5× (15 USD per miljon)

• Status — G​PT-6.1 Sol är aktuell; G​PT-6 Sol är markerad som föråldrad till förmån för den

Två av de raderna bär beslutet. Indexgapet på fyra punkter vid ett oförändrat listpris innebär att ersättaren är strikt bättre på kvalitet per dollar, vilket är ovanligt och är anledningen till att den äldre nivån avvecklas i stället för att rabatteras. Och det halverade cache-läsningspriset förstärker effekten: för en agent som skickar om en lång systemprompt eller ett stort dokument varje tur utgör cachad indata större delen av räkningen, och $0,10 mot $0,20 halverar den dominerande kostnadsposten. Terminal X uppger i den kundberättelse som OpenAI publicerade den 20 oktober att kostnaden per fråga är cirka 30 % lägre i sitt långkontextutvärderingsarbete än för den näst bästa modellen det testade – en siffra som rapporterats av leverantören och kunden, inte en oberoende sådan, men i samma riktning som prislistan.

Parametrarna som ändrar svaret

Identiska modellsträngar kan ge mycket olika fakturor, och specifikationen för 6.1 Sol har tre inställningar som påverkar siffran mer än valet av nivå gör.

• Resonemangsansträngning – låg, medel, hög, xhigh, max. Indexpoängen 52 mäts vid maxansträngning. Arbete på utkastnivå vid låg ansträngning är billigare och snabbare och kommer inte att matcha den poängen; ingen och minimal avvisas direkt.

• Nivå för långa prompter – över 272 000 indatatoken kostar indata och cachad indata 2× och utdata 1,5×. Ett 1M-tokenfönster är inte en 1M-tokenbudget; de sista 700 000 tokens kostar dubbelt.

• Latens vid maximal ansträngning — tid till första token på 248 sekunder på Artificial Analysis-tavlan, jämfört med en median på 3,69 sekunder för jämförelseobjekten. Okej för batchutvärdering, fatalt för ett chattgränssnitt.

• Servicenivå — standard, Fast till 2×, Batch och Flex 50 % lägre, Ultrafast till 6×. Batch plus 6.1 Sol är ofta billigare än standard plus en mindre modell för nattliga körningar.

Effort-inställningen är där de flesta migrering överraskningar uppstår. Team går från G​PT-6 Sol med hög effort till G​PT-6.1 Sol med max eftersom det framhävda resultatet är resultatet för max-effort, och upptäcker sedan att eval-genomströmningen kollapsade och kostnaden per objekt steg. Den rättvisa jämförelsen är samma effort-nivå på båda modellerna, och den ärliga standardinställningen för en första genomgång är den effort-nivå som arbetsbelastningen redan använde.

Ett migrationstest du kan köra på en eftermiddag

Plocka ut 100 till 200 representativa objekt från din egen trafik, kör dem genom G​PT-6 Sol och G​PT-6.1 Sol med motsvarande insats och poängsätt mot det som ditt team redan använder – en bedömningsmatris, en guldstandard, en granskare.

Båda modellerna ligger i samma routningsnamnrymd på OrcaRouter till leverantörens listpris utan påslag, så körningen kostar bara prislistan och inget annat, och att växla mellan dem är en ändring av en enda sträng i stället för ett andra avtal och en andra faktura.

Tre saker att mäta som de offentliga siffrorna inte kan berätta för dig. Träffrekvensen för cachen med din faktiska promptstruktur – det halverade cachepriset lönar sig bara om du får träffar. Huruvida tröskeln på 272 000 token ligger över eller under din typiska kontext, eftersom en arbetsbelastning som ligger precis under den beter sig helt annorlunda än en som ligger precis över. Och latensen vid den ansträngningsnivå du avser att leverera, inte den du benchmarkade.

För en produktionsväg är anledningen till att flytta nu i stället för senare meddelandet om utfasning, inte de fyra indexpoängen. Kör båda parallellt bakom routing-DSL:en, låt den nya nivån ta en del av livetrafiken och använd automatisk failover för att skicka tillbaka förfrågningar till den gamla modellen om den nya inte beter sig som den ska. Det förvandlar en riskabel övergång till ett experiment du kan följa – vilket är rätt form för varje migrering där modellidentifieraren ändrades men inte priset.

Där jämförelserna slutar vara användbara

Två begränsningar är värda att sägas rakt ut. För det första är indexpoäng vid maximal insats inte en proxy för din arbetsbelastning; en skillnad på fyra poäng på tio utvärderingar säger ingenting om huruvida modellen fångar de specifika fel som dina granskare fångar. För det andra är G​PT-6.1 Sol inte automatiskt rätt uppgradering för varje nivå – om arbetet är extrahering, klassificering eller något med ett högt antal anrop och kort kontext, är G​PT-6 Luna till $0.10 och $0.50 en femtedel av indatapriset och mer än dubbelt så hög utdatahastighet, och indexgapet är irrelevant för uppgiften.

Den användbara sammanfattningen är den tråkiga. Det finns ingen G​PT-6.1 att jämföra med G​PT-6.1 Sol, eftersom generationen och modellen är samma objekt. Jämförelsen som finns är G​PT-6.1 Sol mot G​PT-6 Sol, där priset inte ändrades, kvaliteten gjorde det, och raden för cachad indata halverades. Det är ett tillräckligt bra skäl att köra testet – och inte alls ett tillräckligt bra skäl att hoppa över det.