GPT-6.1 Sol vs GPT-6 Sol Pro: de een is een model, de ander is een instelling

Het korte antwoord is dat GPT-6.1 Sol en GPT-6 Sol Pro geen twee modellen zijn die om dezelfde plek strijden, en dat het vergelijken van hun benchmarkscores een categoriefout is: GPT-6 Sol Pro is helemaal geen apart model. Het is GPT-6 Sol met reasoning.mode ingesteld op pro in de Responses API — dezelfde identifier, gpt-6-sol, dezelfde tariefkaart, hetzelfde venster van 1.050.000 tokens, dat meer modelwerk verzet voordat het een definitief antwoord retourneert en de extra tokens tegen standaardtarieven in rekening brengt. GPT-6.1 Sol is een echt aparte deployment met een eigen identifier, gpt-6.1-sol, en een tarief voor gecachte invoer dat de helft is van dat van GPT-6 Sol. De echte vraag is dus niet welk model slimmer is. Het is of een gloednieuw model met 50% cachekorting een uitvoeringsmodus op een ouder model verslaat waarvan de pro-configuratie Open​AI nog niet voor de nieuwe tier heeft gedocumenteerd.

Twee verschillende soorten dingen

Begin met waarnaar elke naam daadwerkelijk verwijst wanneer je die in een request zet. "GPT-6 Sol Pro" verwijst naar gpt-6-sol plus een modusparameter. "GPT-6.1 Sol" verwijst naar gpt-6.1-sol — een afzonderlijke snapshot op een afzonderlijke modelpagina, waarbij op die pagina nergens een modusparameter wordt genoemd. Die asymmetrie is de hele vergelijking, en daarom staat er in de specificatielijst hieronder bijna niets dat een eerlijke strijd is.

• Wat het is — GPT-6.1 Sol is een aparte modelimplementatie versus GPT-6 Sol Pro is gpt-6-sol met reasoning.mode: "pro"
• Identificatie die je verstuurt — gpt-6.1-sol versus gpt-6-sol
• Inputprijs — $2,00 per miljoen tokens versus $2,00 per miljoen tokens; identiek, en de pro-modus rekent geen toeslag op de Sol-tariefkaart
• Outputprijs — $10,00 per miljoen tokens voor beide; extra redeneertokens van de pro-modus worden tegen dit tarief gefactureerd
• Gecachte invoer — $0,10 per miljoen op 6.1 Sol versus $0,20 per miljoen op Sol, in beide modi — de enige regel waarop de keuze geen afwegingen kent
• Cache-schrijfacties — $2,50 per miljoen voor beide
• Context — 1.050.000 tokens en 128.000 maximale uitvoer voor beide
• Redeneerinspanning — low, medium (standaard), high, xhigh, max, waarbij none niet wordt ondersteund op 6.1 Sol versus dezelfde reeks plus none op Sol, en de pro-modus onafhankelijk is van de inspanning
• Aanroepen van tools — Responses API op beide; Chat Completions zonder tools op 6.1 Sol, terwijl Sol functieaanroepen in Chat Completions alleen ondersteunt als de inspanning op none
is ingesteld • Latentie — geen gepubliceerd cijfer voor beide; de pro-modus is per definitie langzamer, omdat deze meer werk verricht voordat het definitieve antwoord er is
• Kosten per taak — niet gepubliceerd voor de pro-modus, en toch niet zinvol vergelijkbaar, omdat het afhangt van hoeveel extra werk de pro-modus voor jouw taak verricht

Lees die lijst en let op de vorm ervan: elke rij is ofwel identiek, ofwel een vergelijking tussen een gedocumenteerde waarde en een ongedocumenteerde.

Wat pro-modus daadwerkelijk oplevert, en wat het kost

OpenAI's beschrijving van de pro-modus is kort en het is de moeite waard die te citeren in plaats van te parafraseren, want de vaagheid is juist het punt: het is "een uitvoeringsmodus van de Responses API die meer modelwerk op een verzoek toepast voordat één definitief antwoord wordt geretourneerd", het kan de betrouwbaarheid bij moeilijke taken verbeteren, het verhoogt de latentie, en het "aggregeert de tokens van dat werk in het gerapporteerde gebruik", gefactureerd tegen de standaard tokentarieven van het geselecteerde model. De eigen richtlijnen van de leverancier over wanneer je het moet gebruiken, zijn ongewoon conservatief voor een lanceringsdocument — de pro-modus is bedoeld voor gevallen waarin "een marginale kwaliteitsverbetering de uitkomst wezenlijk beïnvloedt", en de standaardmodus heeft de voorkeur "voor routinematig, latentiegevoelig of grootschalig werk, en wanneer je evaluaties geen betekenisvolle winst van de pro-modus laten zien."

Wat Open​AI niet publiceert, is de multiplier. Er is geen cijfer per taak, geen bereik, en geen pro mode-vermelding op de Sol rate card. De kosten komen volledig als volume, zichtbaar in het usage-object onder reasoning tokens die als output worden gefactureerd en nooit worden teruggegeven in de response body. Bij $10,00 per miljoen output tokens kosten 10.000 extra tokens per taak een cent, dus de beslissing gaat zelden over de headline; het gaat erom of het extra werk je resultaat verandert. Dat is een meting, geen opzoeking, en het is het enige ding over deze combinatie dat een lezer kan beslechten zonder te wachten op iemands benchmark.

Het hiaat in de documentatie dat deze matchup beslist

GPT-6.1 Sol's modelpagina — degene met de contextgrootte, het prijsblok, de effort-ladder, de toollijst en de snapshotlijst — vermeldt nergensreasoning.mode, pro-modus of standaardmodus. De prozageids die pro-modus behandelt, presenteert de functie nog steeds als werkend met "elk GPT-5.6-model" en vertelt ontwikkelaars hun geselecteerde model te behouden enreasoning.mode in te stellen oppro in plaats van over te stappen naar een aparte Pro-slug. We hebben beide pagina's bekeken, en we konden op basis van OpenAI's documentatie niet bevestigen dat er een pro-modusconfiguratie bestaat voor de 6.1-tier. Het werkt misschien; de bovenliggende GPT-6-gids noemt pro-modus bij de mogelijkheden die de familie meeneemt. Maar "werkt misschien" is geen basis om een productiepad op te bouwen, en dit is de eerlijke stand van zaken per 30 september 2026.

Dat gat levert een werkelijk scheef besluit op. Als je vandaag pro-modus wilt, is de gedocumenteerde plek daarvoor GPT-6 Sol — en de prijs van die keuze is dat je $0,20 in plaats van $0,10 betaalt voor gecachte invoer bij elk hergebruikt prefix, plus wat het extra werk van de pro-modus eraan toevoegt, tegenover een model waarvan de door de leverancier gerapporteerde scores achter die van 6.1 Sol liggen in elke taakfamilie die Open​AI heeft gepubliceerd. Als je vandaag het cachetarief van het 6.1-niveau en zijn benchmarkpositie wilt, geef je een gedocumenteerde pro-configuratie op. Er is geen rij waarin je beide krijgt, want niemand heeft ons verteld of de tweede bestaat.

Het in een middag beslechten op je eigen traffic

De meting is weinig glamoureus en vereist één experiment, geen benchmark-suite. Neem een takenreeks die je moeilijke werk vertegenwoordigt, voer die drie keer uit en lees telkens het usage-object: eenmaal op gpt-6-sol met gemiddelde inspanning in standaardmodus, eenmaal op gpt-6-sol met gemiddelde inspanning met pro-modus ingeschakeld, en eenmaal op gpt-6.1-sol met gemiddelde inspanning. Houd de inspanning constant in alle drie — het hele punt is om één variabele per keer te isoleren. Vergelijk taaksucces, latentie en totaal gefactureerde tokens. Het tokentotaal van de pro-modus-run tegenover het totaal van de standaardmodus is jouw vermenigvuldigingsfactor voor je verkeer; die zal niet overeenkomen met die van iemand anders, omdat het ontwerp is dat de hoeveelheid extra werk meeschaalt met de moeilijkheid van het verzoek.

Twee praktische opmerkingen voor het uitvoeren ervan. Ten eerste: de 6.1-run en de Sol-run zijn dezelfde request body met één gewijzigde string, dus het experiment is goedkoop op te zetten en makkelijk als regressietest te behouden. Ten tweede: als de pro-mode-aanroep op de 6.1-identifier een fout retourneert in plaats van een resultaat, heb je gratis je antwoord over het gat in de documentatie — en heb je het geleerd voordat je het ook maar ergens in de buurt van productie brengt.

Beide configuraties, één sleutel

Dit is het soort vergelijking dat meer kost aan operationele overhead dan aan tokens, en dat is waar routing ophoudt een voetnoot te zijn. OrcaRouter levert GPT-6 Sol tegen Open​AI's eigen lijstprijs zonder markup, dus de tariefkaart van $2.00 / $0.20 / $10.00 hierboven — inclusief de 272K-herprijsregel — wordt exact doorgegeven zoals de leverancier die vermeldt. Dat betekent dat de drie armen van het hierboven beschreven experiment via één endpoint met één API-sleutel en zonder tweede contract kunnen draaien: de twee Sol-configuraties verschillen door één parameter, en de 6.1-tier voegt zich erbij zodra die routeerbaar is. Totdat dat het geval is, is het model dat je kunt aanroepen het model waarvan de pro-modus is gedocumenteerd. Voor moeilijk werk met een laag volume, waar een marginale kwaliteitswinst het resultaat verandert, is de pro-modus op Sol wat de eigen richtlijnen van de leverancier aanbevelen; voor alles wat een hoog volume heeft of latentiegevoelig is, is de standaardconfiguratie zowel sneller als, bij hergebruikte prefixes, nu tweemaal zo duur per gecachet token als de nieuwere tier. Een routeringsregel die het verkeer langs die lijn splitst — pro-modus voor de aanvragen die het verdienen, een goedkopere configuratie voor het gros — is een parameterwijziging in een routerings-DSL in plaats van een herarchitectuur, en het is de versie van deze beslissing die de volgende modelrefresh overleeft.

Wie moet wat kiezen, concreet. Als je al een betrouwbaarheidswinst hebt gemeten van pro-modus op je eigen taken, blijf waar je die hebt gemeten en wacht tot Open​AI het equivalent van 6.1 documenteert voordat je overstapt — de cachebesparing is reëel, maar het gaat om centen op een prefix, en het opnieuw meten van een kwaliteitswinst kost meer dan de korting waard is bij werk met een laag volume. Als je pro-modus helemaal nooit hebt gemeten, is de 6.1-tier het betere startpunt: het is het nieuwere model, de door de leverancier gerapporteerde resultaten zijn het beste op elke taakfamilie die Open​AI heeft gepubliceerd, de gecachte input is half zo duur, en de pro-vraag kan opnieuw worden bekeken wanneer de documentatie is bijgewerkt. Geen van beide keuzes is vandaag verkeerd. Wat verkeerd is, is aannemen dat het alternatieven zijn, terwijl een van beide een selectievakje op de andere is.