GPT-6.1 Sol vs GPT-6 Sol: wat een week extra werk opleverde, en wat niet

Als u GPT-6 Sol vandaag in productie heeft en u probeert te beslissen of GPT-6.1 Sol een migratie waard is, hangt het antwoord volledig af van welke van uw kosten groter is — en de twee modellen zijn zo gebouwd dat het antwoord bijna nooit "beide" is. GPT-6 Sol is op 22 september 2026 uitgebracht voor $2,00 per miljoen invoertokens, $0,20 gecacht en $10,00 uitvoer. GPT-6.1 Sol is op 29 september 2026 uitgebracht voor $2,00 invoer, $0,10 gecacht en $10,00 uitvoer, met een door de leverancier gerapporteerde verbetering van 6,4 procentpunt op complexe software-engineeringtaken bij een lagere redeneerinspanning. De invoer- en uitvoerprijzen zijn niet veranderd. Het cachetarief is gehalveerd. Die ene gewijzigde regel vormt de hele financiële onderbouwing, en al het overige is een argument over capaciteiten dat, op dit punt in de levensduur van de release, uit precies één bron komt.

Drie dingen zijn veranderd. Een ervan is een rekening.

Haal de marketing eraf en het verschil tussen deze twee deployments is kort genoeg om in je hoofd te houden.

• Gecachte invoer — $0,10 per miljoen tokens op GPT-6.1 Sol tegenover $0,20 op GPT-6 Sol. Gemeten in plaats van beweerd, en de enige verandering die zich als rekenwerk laat zien.
• Capaciteiten, volgens de leverancier — OpenAI rapporteert een voorsprong van 6,4 punten op DeepSWE v1.1 bij een lagere redeneerinspanning en lagere kosten, meer dan het dubbele van de score op Terminal-Bench Science 0.1 bij maximale inspanning, zeven punten op de offline set van OSWorld 2.0 bij maximale inspanning, 4,8 punten op AutomationBench bij gemiddelde inspanning, en een feitenfoutpercentage dat daalt van 11,4% naar 7,7% op een opzettelijk foutuitlokkende promptset. Niets ervan is gereproduceerd.
• Redeneerladder — GPT-6.1 Sol ondersteunt low, medium, high, xhigh en max, en ondersteunt none niet; GPT-6 Sol ondersteunt alle zes. Dit is het verschil dat code kapotmaakt, en het is degene die niemand in een lanceringsbericht zet.

Al het andere is identiek of vrijwel identiek: hetzelfde contextvenster van 1.050.000 tokens, dezelfde output van 128.000, hetzelfde tarief van $2,50 voor het schrijven naar cache, dezelfde drempel van 272K tokens waarboven een heel verzoek wordt gefactureerd tegen 2× input en cache en 1,5× output, dezelfde vereiste van de Responses-API voor tool calling, en hetzelfde ontbreken van ondersteuning voor fine-tuning. De cutoff verschoof van 20 april naar 30 april 2026 — tien dagen, precies het soort cijfer dat je vertelt dat dit eerder een refit dan een rebuild was.

Waarom de cachelijn meer waard is dan hij lijkt

Een gehalveerde cache-read is een vreemde manier om een productrefresh mee te leiden, tot je kijkt naar hoe agentverkeer er echt uitziet. Een agent-loop stuurt bij elke beurt een stabiele prefix opnieuw — systeemprompt, toolschema's, opgehaalde context, gespreksgeschiedenis — en in een lange sessie wordt dezelfde prefix tientallen of honderden keren gefactureerd. Dat is het verkeer waarbij een cachetarief ophoudt een afrondingsfout te zijn en de dominante regel op de factuur wordt.

Reken een enkele lange agentsessie door. Stel dat een prefix van 120.000 tokens over 40 beurten wordt hergebruikt, dus 4,8 miljoen gecachte invoertokens per sessie, plus een bescheiden 150.000 nieuwe uitvoertokens. Bij GPT-6 Sol kosten de gecachte reads $0,96 en de output $1,50 — ruwweg $2,46 per sessie. Bij GPT-6.1 Sol kost dezelfde sessie $0,48 voor gecachte reads en dezelfde $1,50 voor output: ongeveer $1,98. Per sessie is het verschil 48 cent, wat geen beslissing is. Vermenigvuldig dat met honderdduizend sessies per maand en het is $48.000 — wat het wel is.

Twee kanttekeningen zorgen dat dit eerlijk blijft. Leesbewerkingen uit cache worden alleen tegen het cachetarief gefactureerd als de prefix daadwerkelijk een hit oplevert, dus je gerealiseerde besparing is je hitratio keer het verschil, niet het verschil zelf. En de prefix moet minder dan 272.000 tokens bevatten om überhaupt voor de standaardtarieven in aanmerking te komen: ga je over die grens, dan wordt de hele aanvraag opnieuw geprijsd tegen 2× input en cache en 1,5× output, wat een besparing van 10 cent op de prefix ruimschoots teniet kan doen. Sessies met een lange context zijn juist de gevallen waarin de cacherekensom het minst waarschijnlijk op de brochure lijkt.

De benchmarkkloof is reëel, en die komt van één plek.

De lanceringspost van OpenAI is ongewoon specifiek over de eigen evaluaties, wat een pluspunt is, en elk van die cijfers is afkomstig van de leverancier die zijn eigen model beoordeelt, wat het minpunt is. Het patroon daarin is consistent: de vergelijking die de ronde doet, is altijd met GPT-6 Astra, en de Astra-vergelijking is altijd een kostenvergelijking. Bij DeepSWE v1.1 is de claim dat het Astra evenaart tegen ongeveer een vijfde van de kosten. Bij GDP.pdf: het benaderen van Astra's state-of-the-art tegen ongeveer een vijfde van de kosten per taak. Bij OSWorld 2.0: binnen 2,1 punten van Astra tegen ongeveer een zevende van de kosten per taak. Qua feitelijkheid: binnen 1,9 punten van Astra tegen minder dan een vijfde van de kosten per taak. Dat is geen toeval bij het opstellen; het is de productthese, en het is een these over prijs, niet over leiderschap in capaciteiten.

De enige plek waar OpenAI zijn eigen framing afwijst, verdient waardering: op Terminal-Bench Science 0.1 zegt het ronduit dat GPT-6 Astra nog steeds de hoogste score heeft onder de geteste modellen, met 68,1%, en gebruikt moet worden voor het moeilijkste wetenschappelijke onderzoek. Een lanceringsbericht dat je vertelt wanneer je het duurdere zusje moet kopen, is een lanceringsbericht met enige discipline erin.

Wat GPT-6 Sol specifiek betreft, is de eerlijke stand van zaken bij de vergelijking deze: er is voor geen van beide modellen een onafhankelijke score in deze configuratie. Artificial Analysis heeft een volledige evaluatie van GPT-6 Sol bij maximale redeneerinspanning: een Intelligence Index van 48, $1,06 per indextaak, 77 miljoen gegenereerde uitvoertokens tegenover een mediaan van 88 miljoen op het leaderboard, en een Coding Agent Index van 57 tegen $2,99 per taak. Het heeft per 30 september helemaal geen vermelding van GPT-6.1 Sol; de slug van het model geeft een 404 en de string komt niet voor in het live leaderboard. Dus de enige gemeten, door derden uitgevoerde vergelijking die vandaag beschikbaar is, is tussen GPT-6 Sol en de modellen van andere labs — niet tussen GPT-6 Sol en zijn eigen opvolger. Iedereen die je nu een grafiek van 6.1 versus 6.0 laat zien, laat je de slide van OpenAI zien.

De migratie is een stringwijziging, behalve waar dat niet zo is

OpenAI's eigen migratierichtlijnen voor de GPT-6-familie zijn het lezen waard voordat je de identifier omzet, want twee onderdelen ervan breken werkende code. Het eerste is de redeneerladder: als een verzoek reasoning_effort: "none" verstuurt, wijst GPT-6.1 Sol het af, en de gedocumenteerde oplossing is om te beginnen bij low en te vergelijken op representatieve taken in plaats van aan te nemen dat de laagste instelling gelijkwaardig is. Workflows die none als latentie-baseline gebruikten, verliezen die baseline. Het tweede is het aanroepen van tools: GPT-6.1 Sol ondersteunt Chat Completions, maar niet het aanroepen van tools via die route — tools vereisen de Responses API. Als je stack functies aanroept op /v1/chat/completions, dan vervang je geen string, maar port je een endpoint. De instructie van de leverancier zelf aan ontwikkelaars die al op GPT-6 Sol zitten, is om die richtlijnen te bekijken voordat ze overstappen, wat een duidelijk signaal is dat dit niet de drop-in-vernieuwing is die de tussenpoos van één week suggereert.

De overige parameters werken als volgt: redeneerinspanning, gestructureerde uitvoer, streaming, prompt-caching en de toolset blijven allemaal behouden, en dezelfde 272K-prijsherzieningsregel geldt identiek voor beide modellen. Stel model in op gpt-6.1-sol, behoud je effort-instelling waar die werd ondersteund, en verwijder temperature, top_p en top_logprobs wanneer effort niet none is — dat laatste geldt voor beide modellen en is een veelvoorkomende oorzaak van 400-fouten na elke migratie naar een redeneermodel.

Migreren zonder daarbij een productiepad op het spel te zetten

De realistische migratie is geen cutover, maar een shadow run: stuur een deel van het productieverkeer naar de nieuwe identifier, houd de oude aan als het pad dat antwoordt, en vergelijk op je eigen taken. Dat is een routeringsprobleem, en het is de enige plek waar het platform waar je je calls doorheen stuurt de vorm van het werk verandert. OrcaRouter serveert GPT-6 Sol vandaag tegen OpenAI's eigen listprijs met nul markup — de kaart van $2,00 / $0,20 / $10,00, inclusief de 272K-herprijsregel — dus de baseline-arm van de vergelijking is live op dezelfde key als al het andere, en de 6.1-arm kan aan de routeset worden toegevoegd zodra die aanroepbaar is, zonder een tweede contract of een tweede SDK. Tot die tijd is de eerlijke positie dat GPT-6 Sol het model is dat je kunt aanroepen, en dat kun je maar beter ronduit zeggen in plaats van iets anders te suggereren: openai/gpt-6.1-sol geeft "model not found" terug op ons openbare catalogus-endpoint, vandaag. Automatische failover is wat de shadow run veilig maakt zodra die er is — als de nieuwe route een fout geeft, wordt het verzoek afgehandeld op de oude en ontdek je het uit de logs in plaats van van je gebruikers.

Wie moeten nu overstappen: teams waarvan de kosten worden gedomineerd door gecachte input bij lange agentsessies, en teams wier workflows de Responses API al gebruiken en nooit verzenden none. Voor hen is dit bijna een gratis upgrade — de leverancier meldt de capaciteitswinsten, de cacheratio is gehalveerd, en de migratie is één string. Wie moeten wachten: teams met none in een latency-kritiek pad, teams waarvan de tool calling via Chat Completions loopt, en iedereen die een cijfer van buiten OpenAI nodig heeft voordat ze zich vastleggen. Voor die laatste groep heeft het wachten geen gepubliceerde einddatum, en het verstandige om met de tijd te doen is de evalset bouwen die de vergelijking nodig zal hebben — want wanneer de onafhankelijke score arriveert, zal die voor andermans verkeer zijn.