GPT-6.1 Sol vs GPT-6 Sol Pro: Den ena är en modell, den andra är en inställning

Det korta svaret är att GPT-6.1 Sol och GPT-6 Sol Pro inte är två modeller som tävlar om samma plats, och att jämföra deras benchmarkresultat är ett kategorifel: GPT-6 Sol Pro är inte alls en separat modell. Det är GPT-6 Sol med reasoning.mode inställt på pro i Responses API — samma identifierare, gpt-6-sol, samma prislista, samma fönster på 1 050 000 token, och utför mer modellarbete innan den returnerar ett slutligt svar och fakturerar de extra tokens till standardpriser. GPT-6.1 Sol är en genuin separat driftsättning med egen identifierare, gpt-6.1-sol, och ett pris för cachad indata som är hälften av GPT-6 Sols. Så den verkliga frågan är inte vilken som är smartast. Det handlar om huruvida en helt ny modell med 50 % cacherabatt slår ett körningsläge på en äldre modell vars pro-konfiguration Open​AI ännu inte har dokumenterat för den nya nivån.

Två olika typer av saker

Börja med vad varje namn faktiskt löses upp till när du anger det i en förfrågan. "GPT-6 Sol Pro" löses upp till gpt-6-sol plus en lägesparameter. "GPT-6.1 Sol" löses upp till gpt-6.1-sol — en distinkt ögonblicksbild på en separat modellsida, där ingen lägesparameter nämns någonstans på den sidan. Den asymmetrin är hela jämförelsen, och det är därför specifikationslistan nedan nästan inte innehåller något som är en rättvis kamp.

• Vad det är — GPT-6.1 Sol är en separat modelldistribution, medan GPT-6 Sol Pro är gpt-6-sol med reasoning.mode: "pro"
• Identifierare som du skickar — gpt-6.1-sol mot gpt-6-sol
• Indatapris — $2.00 per miljon tokens mot $2.00 per miljon tokens; identiska, och pro-läget har ingen tilläggsavgift på Sol-prislistan
• Utdatapris — $10.00 per miljon tokens för båda; pro-lägets ytterligare resonemangstokens faktureras enligt denna taxa
• Cachad indata — $0.10 per miljon på 6.1 Sol mot $0.20 per miljon på Sol, i endera läget — den enda posten där valet är fritt från avvägningar
• Cache-skrivningar — $2.50 per miljon för båda
• Kontext — 1 050 000 tokens och 128 000 max utdata för båda
• Resonemangsansträngning — low, medium (standard), high, xhigh, max, där none inte stöds på 6.1 Sol mot samma stege plus none på Sol, och pro-läget är oberoende av ansträngning
• Verktygsanrop — Responses API på båda; Chat Completions utan verktyg på 6.1 Sol, medan Sol stöder funktionsanrop i Chat Completions endast när ansträngningen är satt till none
• Latens — ingen publicerad siffra för någon av dem; pro-läget är långsammare till sin konstruktion, eftersom det utför mer arbete innan det slutliga svaret
• Kostnad per uppgift — ej publicerad för pro-läget, och ändå inte meningsfullt jämförbar, eftersom den beror på hur mycket extra arbete pro-läget utför på din uppgift

Läs listan och lägg märke till dess form: varje rad är antingen identisk, eller en jämförelse mellan ett dokumenterat värde och ett odokumenterat.

Vad proffsläget faktiskt ger, och vad det kostar

OpenAI:s beskrivning av pro-läget är kort och värd att citera snarare än att parafrasera, eftersom vagheten är själva poängen: det är "ett körningsläge i Responses API som tillämpar mer modellarbete på en begäran innan ett enda slutligt svar returneras", det kan förbättra tillförlitligheten vid svåra uppgifter, det ökar svarstiden, och det "aggregerar tokens från detta arbete i rapporterad användning", fakturerat enligt den valda modellens standardtaxor för tokens. Leverantörens egen vägledning om när det bör användas är ovanligt återhållsam för att vara ett lanseringsdokument – pro-läget är till för fall där "en marginell kvalitetsförbättring väsentligt påverkar resultatet", och standardläget föredras "för rutinmässigt, latenskänsligt eller högvolymarbete, och närhelst dina utvärderingar inte visar någon meningsfull vinst med pro-läget."

Det OpenAI inte publicerar är multiplikatorn. Det finns ingen siffra per uppgift, inget intervall och ingen post för pro-läge på Sol-prislistan. Kostnaden kommer helt och hållet som volym, synlig i usage-objektet under reasoning tokens som faktureras som output och aldrig returneras i svarskroppen. Vid $10.00 per miljon output-token kostar ytterligare 10 000 token per uppgift en cent, så beslutet handlar sällan om huvudnumret; det handlar om huruvida det extra arbetet förändrar ditt resultat. Det är en mätning, inte en uppslagning, och det är det enda med den här kombinationen som en läsare kan avgöra utan att vänta på någons benchmark.

Luckan i dokumentationen som avgör den här matchen

Modellsidan för GPT-6.1 Sol – den som innehåller dess kontextstorlek, prisblock, effort-trappa, verktygslista och snapshot-lista – nämner inte reasoning.mode, pro-läge eller standardläge någonstans. Guiden i löpande text som täcker pro-läge ramar fortfarande in funktionen som att den fungerar med "vilken GPT-5.6-modell som helst" och säger till utvecklare att behålla sin valda modell och ställa in reasoning.mode till pro i stället för att byta till en separat Pro-slug. Vi kontrollerade båda sidorna och kunde inte bekräfta från OpenAIs dokumentation att en pro-lägeskonfiguration finns för 6.1-nivån. Det kan fungera; den överordnade GPT-6-guiden listar pro-läge bland de förmågor som familjen för vidare. Men "kan fungera" är inte något att bygga en produktionsväg på, och det är det ärliga läget i dokumentationen per den 30 september 2026.

Det gapet leder till ett genuint obalanserat beslut. Om du vill ha pro-läget i dag, är den dokumenterade hemvisten för det GPT-6 Sol — och kostnaden för att välja det är att du betalar 0,20 $ i stället för 0,10 $ för cachad indata för varje återanvänt prefix, plus vad pro-lägets extra arbete än tillför, mot en modell vars leverantörsrapporterade poäng ligger under 6.1 Sols i varje uppgiftsfamilj som Open​AI publicerade. Om du vill ha 6.1-nivåns cachepris och dess benchmarkposition i dag, avstår du från en dokumenterad pro-konfiguration. Det finns ingen rad där du får båda, eftersom ingen har berättat för oss huruvida den andra existerar.

Avgöra det på din egen trafik på en eftermiddag

Mätningen är oglamorös och den kräver ett experiment, inte en benchmark-svit. Ta en uppgiftsuppsättning som representerar ditt svåra arbete, kör den tre gånger och läs usage-objektet varje gång: en gång på gpt-6-sol vid medium effort i standardläge, en gång på gpt-6-sol vid medium effort med pro-läge aktiverat, och en gång på gpt-6.1-sol vid medium effort. Håll effort konstant över alla tre — hela poängen är att isolera en variabel i taget. Jämför uppgiftsframgång, latens och totalt fakturerade tokens. Token-totalen för pro-lägeskörningen mot standardlägets total är din multiplikator för din trafik; den kommer inte att matcha någon annans, eftersom designen är att mängden extra arbete skalas med begärans svårighetsgrad.

Två praktiska noteringar för att köra det. För det första är 6.1-körningen och Sol-körningen samma request body med en enda sträng ändrad, så experimentet är billigt att sätta upp och enkelt att behålla som ett regressionstest. För det andra: om pro-mode-anropet på 6.1-identifieraren returnerar ett fel i stället för ett resultat har du svaret om dokumentationsluckan gratis – och du har lärt dig det innan du placerar det ens i närheten av produktion.

Båda konfigurationerna, en nyckel

Det här är den typ av jämförelse som kostar mer i operativ overhead än i tokens, och det är här routing slutar vara en fotnot. OrcaRouter tillhandahåller GPT-6 Sol till OpenAI:s eget listpris utan påslag, så prislistan ovan på $2.00 / $0.20 / $10.00 — inklusive 272K-omprissättningsregeln — förs vidare exakt som leverantören listar den. Det innebär att de tre grenarna i experimentet som beskrivs ovan kan köras via en enda endpoint med en enda API-nyckel och inget andra avtal: de två Sol-konfigurationerna skiljer sig åt genom en parameter, och 6.1-nivån lägger sig bredvid dem så snart den går att routa. Tills dess är modellen du kan anropa den vars pro-läge är dokumenterat. För svårt arbete med låg volym, där en marginell kvalitetsvinst förändrar utfallet, är pro-läget på Sol vad leverantörens egen vägledning rekommenderar; för allt som har hög volym eller är latenskänsligt är standardkonfigurationen både snabbare och, för återanvända prefix, nu dubbelt så dyr per cachad token som den nyare nivån. En routingregel som delar trafiken längs den linjen — pro-läge för de förfrågningar som förtjänar det, en billigare konfiguration för merparten — är en parameterändring i en routing-DSL snarare än en omarkitektur, och det är versionen av detta beslut som överlever nästa modelluppdatering.

Vem bör välja vad, konkret. Om du redan har mätt en tillförlitlighetsvinst från pro-läget på dina egna uppgifter, stanna där du mätte den och vänta med att byta tills Open​AI dokumenterar 6.1-motsvarigheten — cache-besparingen är verklig men den är cent på ett prefix, och att mäta om en kvalitetsvinst kostar mer än rabatten är värd vid lågvolymarbete. Om du aldrig har mätt pro-läget alls är 6.1-nivån den bättre startpunkten: den är den nyare modellen, dess leverantörsrapporterade resultat leder inom varje uppgiftsfamilj som Open​AI har publicerat, dess cachade indata kostar hälften så mycket, och pro-frågan kan tas upp igen när dokumentationen kommer ikapp. Inget av valen är fel i dag. Det som är fel är att anta att de är alternativ, när det ena är en kryssruta på det andra.