GPT-5.6 Sol Ultrafast vs GPT-5.6 Sol: dezelfde gewichten, andere servicelaag

GPT-5.6 Sol Ultrafast is geen nieuw model, en dit is geen lanceringsverhaal. De leverancier kondigde de modus aan op 13 augustus 2026, en dezelfde dag verscheen de waarde ultrafast in het publieke OpenAPI-schema van het bedrijf, in de ServiceTierResponses-beschrijving van de specificatie — die de tier volgens zijn eigen formulering beperkt tot het gpt-5.6-sol-endpoint en als toegangsgecontroleerd markeert. Wat deze pagina weer in onze wachtrij zette, is kleiner en specifieker: op 25 september 2026 breidde commit fe4f7a1 die waarde uit naar twee verdere enumeraties, de servicetierparameter op verzoekniveau en het veld voor servicetierbeleid van de agent. Zes weken na de aankondiging staat de tier nog steeds op de wachtlijst, heeft hij nog steeds geen gepubliceerde prijs, en is hij nu ingebouwd in meer van het API-oppervlak dan hij daadwerkelijk kan bedienen. GPT-5.6 Sol Ultrafast en GPT-5.6 Sol zijn hetzelfde model; het enige wat deze vergelijking kan bepalen, is wie de pointer beheert en wie je de kosten heeft meegedeeld.

De confrontatie in de kop is dus ongebruikelijk. GPT-5.6 Sol Ultrafast en GPT-5.6 Sol zijn hetzelfde model. Dezelfde gewichten, dezelfde checkpoint, hetzelfde redeneergedrag, hetzelfde contextvenster van 1,05 miljoen tokens, dezelfde maximale output van 128K, dezelfde antwoorden. De eigen framing van OpenAI is "meer nuttig werk per seconde", geen slimmer model. Het enige dat verschilt tussen de twee kolommen van deze vergelijking is hoe de tokens worden geproduceerd en hoe de tier in je request body heet — wat het het zuiverste controle-experiment in de huidige line-up maakt, en ook het moeilijkst om er een uit te kiezen, omdat een van de twee tiers helemaal geen gepubliceerde prijs heeft.

Wat is er deze week eigenlijk veranderd?

Het bewijs voor de wijziging van september is een commit, geen blogpost. OpenAI onderhoudt openai-openapi, de repository die het machineleesbare schema voor zijn API publiceert, en commit fe4f7a1 — gedateerd 2026-09-25 — voegt ultrafast toe aan twee enumeraties: het service-tierbeleid dat aan agents is gekoppeld, en het veld op verzoekniveau dat de spec beschrijft als "de servicelaag die voor modelaanvragen wordt gebruikt." Dat is een uitbreiding, geen debuut: vóór deze commit stonden in die twee lijsten auto, default, flex, priority, fast, en de tier stond al sinds 13 augustus in het schema. De commit is het vermelden waard vanwege het veld dat hij bereikte — het beleidsveld waarmee een agent wordt geconfigureerd, wat een ander oppervlak is dan een override per verzoek.

De beschrijving die ertoe doet, dateert van de commit van 13 augustus, niet van deze, en het is de meest specifieke verklaring die OpenAI ergens over deze servicelaag heeft gepubliceerd. Naast de nieuwe waarde staat in de spec: "Als deze op 'ultrafast' is ingesteld, wordt het verzoek verwerkt met de toegangsgecontroleerde Ultrafast Processing-servicelaag. Deze servicelaag is momenteel beschikbaar voor gpt-5.6-sol; een antwoord dat via deze laag wordt geleverd, toont service_tier=ultrafast."

Lees die zin twee keer, want hij beslecht twee vragen waar deze vergelijkingspagina zich anders over zou moeten indekken. De tier is beperkt tot één model — het GPT-5.6 Sol-vlaggenschip en niets anders in het aanbod — en is toegangsgecontroleerd in plaats van open, wat aansluit bij hoe OpenAI een preview met wachtlijst framet. Hij vertelt je ook hoe je zou weten dat je toegang hebt gekregen: de response echoot terug welke tier het verzoek daadwerkelijk heeft bediend, zodat een terugval naar standaardverwerking zichtbaar is in de response body in plaats van iets dat je uit latentie moet afleiden. Dezelfde beschrijving staat in zowel de standaard- als de Beta Responses-schema's, en dat is al sinds 13 augustus het geval.

De volgende dag kwam er een tweede, zwakker signaal binnen. Een bericht van 26 september beschrijft een nieuwe Speed-selector — Fast, Standard en Ultrafast — die naar de Responses API Playground komt, waarbij een bredere beschikbaarheid van Ultrafast wordt verwacht na OpenAI's DevDay-ontwikkelaarsconferentie. We hebben de selector zelf niet gezien en OpenAI heeft geen uitrolbericht gepubliceerd, dus beschouw dit als een rapport uit één bron en niet als een reeds uitgebrachte functie. De onderdelen die vandaag te controleren zijn, zijn de twee plekken in het openbare schema en het feit dat er geen tariefkaart voor de tier is verschenen.

Wat niet is veranderd, is net zo belangrijk. Er is nog steeds geen Ultrafast-prijs. De prijzenpagina van OpenAI, gelezen op 27 september, bevat de vier tabbladen die er eerder ook waren — Standard, Batch, Flex en Fast — en de tekstreeks "ultrafast" komt er nergens op voor. Toegang wordt nog steeds omschreven als een beperkte preview voor geselecteerde klanten, die wordt uitgebreid naarmate de capaciteit groeit. De tier staat in het contract en tegelijkertijd niet in de prijslijst, en dat is de eerlijke stand van zaken.

De twee niveaus, naast elkaar

Omdat geen enkele capaciteit deze twee onderscheidt, komt de vergelijking vrijwel volledig neer op serveren en factureren. Elke regel hieronder bevat beide zijden op één rij.

• Model — GPT-5.6 Sol Ultrafast draait op het identieke GPT-5.6 Sol-checkpoint als de standaardverwerking van GPT-5.6 Sol, hetzelfde checkpoint, geen distillatie, geen grootteverkleining.

• Outputdoorvoer — tot 750 outputtokens per seconde, tot 14× standaard, volgens de aankondiging van OpenAI op 13 augustus, tegenover standaard GPT-5.6 Sol-verwerking op GPU-clusters, wat het cijfer is waartegen de 14× wordt gemeten.

• Hardware — Cerebras-waferschaalchips, gewichten die in on-chip SRAM verblijven, het eerste product van OpenAI's compute-partnerschap van januari 2026 met Cerebras, naar verluidt ongeveer 10 miljard dollar waard over drie jaar, tegenover conventionele GPU-inferentie, waarbij veel van de tijd opgaat aan het verplaatsen van gewichten tussen geheugen en rekenkracht.

• Prijs — per 27 september 2026 nog niet gepubliceerd, tegenover $4,00 voor invoer / $20,00 voor uitvoer per miljoen tokens, het huidige promotietarief van OpenAI, plus $0,40 per miljoen voor gecachte invoer.

• Beschikbaarheid — beperkte preview met wachtlijst voor geselecteerde klanten versus de standaardroute, aanroepbaar door iedereen met een API-sleutel.

• Antwoorden die je terugkrijgt — identiek, in principe vs identiek, in principe; als ze bij dezelfde prompt uiteenlopen, is dat een bevinding, geen functie.

De snelheidsclaim, en het plafond daarop

Het kerncijfer is 14× en het verdient dezelfde zorg die de rest van deze pagina krijgt. OpenAI stelt tot 750 output tokens per seconde tegenover standaardverwerking — een doorvoercijfer voor output tokens, niet de bewering dat elk verzoek 14 keer sneller klaar is. End-to-end tijd bevat ook inputverwerking en de eigen redenering van het model, die geen van beide door de wafer-scale hardware in dezelfde verhouding worden gecomprimeerd. Daarom bestempelt het bedrijf 14× als een maximum in plaats van een meting.

De gepubliceerde vergelijkingen zijn afkomstig van leveranciers aan beide zijden van de tabel, en één ervan bestrijkt de stacks van twee leveranciers. Een Humanity's Last Exam-run van 2.500 vragen zou op Ultrafast in 11 uur 11 minuten zijn afgerond, tegenover 78 uur 27 minuten voor Claude Fable 5, met vergelijkbare nauwkeurigheid — dat wil zeggen dat OpenAI en Cerebras ons vertellen over een benchmark waarin het model van een concurrent is opgenomen, en onafhankelijke berichtgeving over de lancering citeerde voor dezelfde run een nauwere vergelijking van ruwweg 11× de generatiesnelheid, terwijl Cerebras' eigen cijfers ongeveer 7× impliceren voor de totale testtijd. Het verschil tussen 14×, 11× en 7× is geen tegenstrijdigheid; het is wat er gebeurt wanneer drie partijen verschillende delen van één workload meten. Cerebras rapporteert afzonderlijk 5,6× end-to-end op GDP-Val zonder meetbaar kwaliteitsverlies. Niets ervan is door een derde partij gereproduceerd.

De prijslijst heeft een gat

Hier houdt de symmetrie tussen de twee niveaus op. GPT-5.6 Sol heeft vier gepubliceerde tariefkaarten en Ultrafast is er daar niet een van.

• Standaard GPT-5.6 Sol — $4,00 / $20,00 per miljoen tokens, met gecachte invoer tegen $0,40 en een long-contextniveau van $8,00 / $30,00 zodra de invoer ongeveer 272K tokens overschrijdt.

• Fast mode — $8,00 / $40,00, precies het dubbele van het standaardtarief. Dit is het niveau dat op 30 juli 2026 is hernoemd van Priority processing, en de API accepteert zowel service_tier: "priority" als service_tier: "fast". Het biedt tot ongeveer 2,5× de outputsnelheid.

• Batch en Flex — $ 2,00 / $ 10,00, een vaste 50% korting op de standaardprijs in ruil voor lossere planning.

• Ultrafast — geen tariefkaart. Geen leemte die wij met een gok hebben opgevuld; een leemte die OpenAI heeft achtergelaten.

Die Fast-mode-rij is de enige echte prior waartegen iemand Ultrafast kan afzetten, en die is ontnuchterend voor iedereen die een budget wil plannen: het enige snelheidsniveau waar OpenAI daadwerkelijk een getal aan heeft verbonden, kost precies het dubbele van het standaardtarief voor tweeënhalf keer de snelheid. Ultrafast is een grotere snelheidsclaim die op schaarsere hardware berust — Cerebras-wafercapaciteit is geen commodity — dus de richting van de uiteindelijke meerprijs staat niet ter discussie. De omvang ervan wel. Zolang er geen tariefkaart bestaat, is elk "GPT-5.6 Sol Ultrafast price"-cijfer dat je ergens ziet geciteerd iemands inferentie, met inbegrip van elke inferentie van ons.

Hoe je het eigenlijk zou noemen

De schemawijziging vertelt je de vorm van de uiteindelijke aanroep. Als de tier het patroon van de andere volgt, komt die binnen als een extra veld op een request die je al doet: je behoudt model gpt-5.6-sol, behoudt je prompt, en voegt de tier-selector toe — op dezelfde manier waarop Fast mode vandaag wordt geselecteerd door priority in te wisselen voor fast. Er verandert niets aan het parsen van je respons, omdat er niets aan het model verandert. Dat is precies de aantrekkingskracht van een serving tier ten opzichte van een modelwissel, en de reden dat een vergelijkingspagina als deze zo weinig te vergelijken heeft.

Wat je vandaag niet kunt doen, is het aanroepen. De enumeratiewaarde bestaat; de capaciteit erachter niet, voor de meeste accounts. De praktische vraag voor de komende weken is dus niet welke van de twee tiers je moet kiezen — het is wat je moet draaien zolang die keuze niet beschikbaar is.

Dat is een vraag die een gateway beter beantwoordt dan een wachtlijst. De standaardlaag van het model is nu live op OrcaRouter als openai/gpt-5.6-sol, geleverd tegen het eigen tarief van de provider met nul toeslag op tokens, via het OpenAI-compatibele endpoint op api.orcarouter.ai/v1 — dus OpenAI's promotionele tarieven van $4 / $20 en zijn long-contextstap van $8 / $30 worden rechtstreeks doorgegeven in plaats van door ons opnieuw geprijsd, en een wijziging daarin komt bij ons aan op dezelfde dag dat die bij OpenAI aankomt. Dezelfde sleutel draagt 200+ modellen, wat hier meer dan anders uitmaakt: omdat je service_tier: "ultrafast" niet kunt instellen en dan een antwoord krijgt, is de manier om vandaag latentie te kopen het werk anders te routeren — stuur de interactieve calls naar het model in de catalogus dat jouw kwaliteitslat het snelst haalt, en houd de nachtelijke batches op de goedkoopste route die voldoet. Wanneer de laag daadwerkelijk opengaat, is de router de plek waar je de schakelaar zou omzetten, en tot dan is het het verschil tussen een wachtlijst en een plan.

Welke hoort in productie?

Negeer het woord 'versus' even, want hier valt geen kwaliteitsbeslissing te nemen. Als je optimaliseert voor kosten per token, is standaard GPT-5.6 Sol het antwoord, en de Batch-lane met 50% korting is het antwoord voor alles wat kan wachten. Als je optimaliseert voor hoe lang een mens naar een laadspinner zit te kijken, is Ultrafast het antwoord zodra je het kunt krijgen — en de workloads die OpenAI voor de preview noemt, laten precies zien waarom: incidentrespons met logs en diffs open tijdens een live storing, fraudedetectie op data die voortdurend verandert, supportgesprekken waarin een halve seconde stilte aanvoelt als een kapot product, en onderzoeksloops die vroeger 's nachts draaiden en nu in één werksessie worden samengeperst.

De aanwijzing is de vorm van je requestgraaf, niet de grootte van je prompt. Een enkele lange generatie levert op papier 14× winst op en in de praktijk een stuk minder, omdat invoerverwerking en redeneren niet in die verhouding comprimeren. Veertig sequentiële toolaanroepen achter één voor de gebruiker zichtbare actie leveren winst op die veel dichter bij de volledige multiplier ligt, omdat elk van die roundtrips latentie is die de gebruiker moet uitzitten. Als je workload op de tweede lijkt, is de tier op jou gericht; als die op de eerste lijkt, zou het standaardpad altijd al prima zijn geweest.

Twee dingen om in de gaten te houden, en geen van beide is een gerucht dat we van hieruit kunnen beslechten. Ten eerste de tariefkaart: een premiumlaag zonder prijs valt niet te budgetteren, en het precedent van Fast-mode suggereert dat die niet klein zal zijn. Ten tweede of de wachtlijst rond DevDay daadwerkelijk wordt opgeheven zoals gemeld — want een service_tier-waarde die de meeste accounts niet kunnen gebruiken is documentatie, geen beschikbaarheid, en het verschil tussen die twee is het verschil tussen een plan en een belofte.