De Decisions API van OpenAI is nu een publieke bèta — en de prijs is niet wat de verslaggeving over de lancering had geraden.

Acht dagen nadat de leverancier de Decisions API op DevDay presenteerde, was het niet langer iets waarvoor je uitgenodigd moest worden. Het endpoint ging op 6 oktober 2026 in publieke bèta, samen met een documentatiepagina, een Playground-link en de eerste gepubliceerde prijs voor de dienst. Twee details in die release zijn belangrijker dan de rest. Het eerste is dat GPT-6 Luna het enige model is dat het endpoint accepteert — dus de mogelijkheden van de API en het plafond ervan zijn voorlopig hetzelfde. Het tweede is dat de rekensom van de lanceringsdag die bijna iedereen maakte, inclusief wijzelf, op een manier fout zat die het corrigeren waard is: de eerste golf berichtgeving leidde de kosten per aanroep af uit het token-tarievenkaartje van Luna, en die gevolgtrekking blijkt de korting met een factor vijf te onderschatten.

Niets van wat volgt is speculatie. Het is vandaag allemaal te lezen in OpenAI's eigen ontwikkelaarsdocumentatie, en dat is de verandering: op 30 september was er nergens in OpenAI's documentatie een documentatiepagina voor dit endpoint, geen changelog-item, geen tarief en geen beschreven requestvorm. Die zijn er nu alle vier.

Wat er precies is uitgebracht

De bèta is een specifiek eindpunt — POST /v1/decisions — en het is geen modus op de Responses API, waarmee het wordt vergeleken. Een verzoek bevat drie velden:

• model — momenteel gpt-6-luna en niets anders
• invoer — het gedeelde bewijs: een tekststring, of gebruikersberichten met tekst en afbeeldingen
• vragen — een of meer vragen, elk met een type, instructies en eventuele toegestane opties

Het antwoord is een antwoorden-array, één item per vraag, met als sleutel de naam die je elk ervan hebt gegeven. Dat is het hele contract, en de interessante engineering zit in de drie vraagtypes, niet in de bedrading.

• predicaat — retourneert een kans van 0 tot 1 dat aan een gestelde voorwaarde wordt voldaan. "Toont deze productfoto zichtbare schade?" Het voorbeeld in de documentatie retourneert 0,92 en zegt dat je het moet vergelijken met een drempel die je hebt gekozen.
• keuze — retourneert één waarde uit een door jou opgegeven set, plus een kansverdeling over alle opties en een apart betrouwbaarheidsveld. Het voorbeeld in de documentatie stuurt een facturatieklacht naar facturatie met 0,95.
• score — retourneert een kansgewogen gemiddelde over geordende niveaus. Geef het drie ernstniveaus — cosmetisch, tijdelijke oplossing beschikbaar, volledig geblokkeerd — en kansen van 0,1, 0,7 en 0,2 komen terug als een score van 1,1, die bewust tussen twee niveaus ligt in plaats van naar één niveau te springen.

De prijs is lager dan de voor de hand liggende gok, en de facturatiestructuur is anders.

Hier is de correctie. Toen de Decisions API in beperkte preview was, was het eerlijke standpunt dat er geen prijs bestond en dat iedereen die er een noemde, die zelf afleidde. De voor de hand liggende gevolgtrekking waren Luna's tokenprijzen: $0,10 per miljoen inputtokens en $0,50 per miljoen outputtokens. Zo factureert het endpoint echter niet.

Het gedocumenteerde tarief voor /v1/decisions met gpt-6-luna is $0,10 per miljoen inputtokens, met helemaal geen kosten voor output, en ook geen kosten voor cache-lezen of cache-schrijven. Je betaalt voor het bewijs dat je stuurt, niet voor het antwoord dat terugkomt. Afgezet tegen de eigen tariefkaart van het model — waar output vijf keer de inputprijs is en cache-leesbewerkingen een tiende daarvan — is dat een wezenlijk ander kostenprofiel, en het is een beter profiel voor precies de workload waarop het endpoint is gericht, waarbij de input een alinea of een afbeelding is en de output één token aan beslissing waard is.

Twee kanttekeningen staan bovenop dat cijfer en beide worden door OpenAI vermeld in plaats van afgeleid: regionale verwerkingsopslagen en vermenigvuldigingsfactoren voor invoer met lange context blijven van toepassing, en de vaste $0,10 is specifiek het /v1/decisions-tarief — andere verzoeken die gpt-6-luna gebruiken, volgen de gewone prijsstelling voor modellen en verwerkingsniveaus.

Als je dit aan het afwegen was tegen de Luna-tarievenkaart op basis van de veronderstelling dat een beslissing één input plus één output kost, herbereken dan het getal. Het is ongeveer een vijfde van wat dat model impliceert, nog voordat het long-context-niveau in aanmerking wordt genomen.

De latencyclaim, opnieuw geformuleerd

Het andere dat is veranderd, is de formulering van de centrale prestatieclaim, en de verandering is subtiel genoeg om te signaleren, omdat die verschuift wat er wordt vergeleken.

In de lanceringstekst van OpenAI stond dat de Decisions API beslissingen neemt "tot 10x sneller dan GPT-6 Luna via de Responses API." De documentatie begint nu met: de API "evalueert tekst, afbeeldingen of beide en retourneert getypeerde antwoorden ongeveer 10x sneller dan de Responses API."

Dat zijn niet dezelfde uitspraken. De eerste vergelijkt een endpoint voor beperkte besluitvorming met een volledige generatieve aanroep en schrijft het verschil toe aan het endpoint. De tweede vergelijkt het endpoint in het algemeen met de Responses API. Hoe dan ook blijft het getal door de leverancier opgegeven en niet gereproduceerd — geen verdeling, geen regio, geen invoergrootte, geen gelijktijdigheidsniveau, geen service-level agreement — en één mediaan is nog steeds het verkeerde getal om een deadline op te baseren. Als je beslissing tussen een klik en een betaling ligt, meet dan je eigen p95 en p99 met je eigen afbeeldingen.

Wat echt is verbeterd, is dat de vraag nu überhaupt beantwoord kan worden. In preview kon je dit niet testen zonder toegang. In de publieke bèta kan dat wel.

Waar hij draait, en het ene ding dat je ernaast moet houden

Twee operationele notities uit de documentatie die je gemakkelijk over het hoofd ziet. Het endpoint ondersteunt Zero Data Retention en HIPAA-gebruik voor klanten die daarvoor in aanmerking komen, en dataresidentie wordt aangeboden in de Verenigde Staten en Europa — specifiek de EER plus Zwitserland. Die gelden niet standaard, maar alleen als je daarvoor in aanmerking komt, dus lees de data-controls-pagina voordat je ervan uitgaat dat een van beide op je account van toepassing is.

Er is ook een begeleidende gids voor het koppelen van het endpoint aan de Live API, zodat een spraakverzoek kan worden omgezet in een gekozen actie waarvan het resultaat vervolgens aan de spreker wordt teruggekoppeld. Dat is het interessantste tweede-ordegebruik van de primitieve: niet "classificeer dit ticket", maar "beslis wat de agent vervolgens moet doen, hardop, in een gesprek."

De API is OpenAI's eigen packaging en wij routeren die niet; als je dit specifieke endpoint wilt, zit het bij OpenAI. Het onderliggende model is een ander verhaal — GPT-6 Luna is een live route op OrcaRouter tegen OpenAI's listprijs met nul markup doorberekend, en omdat de limieten van het endpoint zelf kunnen verschuiven tijdens een bèta, is de verstandige vorm voor een productie-uitrol een beperkte beslissing op het kritieke pad met een op prompts gebaseerde fallback die al warm achter de hand ligt. Die fallback op dezelfde sleutel houden als al het andere betekent geen tweede contract en geen herschrijving van het fallback-pad wanneer een preview zijn limieten wijzigt.

Wat deze week te doen, en wat er nog ontbreekt

De eerlijke samenvatting van de stand van zaken: twee van de vier open plekken sinds de lancering zijn ingevuld en twee niet. De prijs is gepubliceerd, de vorm van het verzoek is gepubliceerd, de drie vraagtypen zijn gedocumenteerd met uitgewerkte voorbeelden, en het verhaal rond gegevensverwerking is op zijn minst uiteengezet. Wat nog ontbreekt, is een gepubliceerde limiet op hoeveel kandidaatantwoorden één verzoek kan bevatten, enige uitspraak over of je het ding kunt afstellen op je eigen gelabelde data, en — omdat het volgens OpenAI's eigen beschrijving een bèta is — enige toezegging dat het tarief dat je vandaag leest, behouden blijft tot de algemene beschikbaarheid.

Dat maakt de afweging eenvoudig in plaats van dramatisch. Als je probleem classificatie of routing op schaal is, waarbij een verkeerde vertakking goedkoop en omkeerbaar is, is publieke bèta nu echt bouwbaar en maakt de prijsstelling voor alleen invoer de rekensom ongewoon vergevingsgezind. Als je beslissing geld goedkeurt of berichten naar een klant stuurt, is het endpoint niet langer onkenbaar, maar het is nog niet opgehouden een bèta te zijn, en het verschil tussen die twee dingen is het verschil tussen een prototype en een dragende afhankelijkheid.