Waar OpenAI's Decisions API eindigt en Jev begint: wat de eerste externe klant laat zien

Op 23:05 UTC op 2026-10-06 verscheen een plugin genaamd llm-openai-decisions op PyPI, en de README ervan bevat de zin die de lanceerberichtgeving nooit heeft afgedrukt: "Anders dan Jev ondersteunt het nieuwe gpt-6-luna beslissingsmodel naast tekst ook beeldinvoer." De auteur is Simon Willison, die ook de eerste client voor het beslissingsmodel van TypeSafe schreef, en de vergelijking die hij maakt is tussen GPT-6 Luna — het model achter de Decisions API van OpenAI — en Jev 1.13, het tekstuele System One-model van TypeSafe. Dezelfde blogpost merkt op dat de plugin zelf is geschreven door GPT-6 Astra die de documentatie van OpenAI las.

Dat is het nuttige aan een client die een week na een API uitkomt: hij is geschreven tegen de requestvorm, niet tegen de keynote, en legt zo de verschillen bloot die marketingcopy verdoezelt. Niets hier is een lek en niets hier is onbevestigd — elk cijfer hieronder komt van een pagina die is gepubliceerd door OpenAI, TypeSafe of de repository van de plugin zelf, allemaal gelezen op 2026-10-07. Wat nog ontbreekt, is een onafhankelijke meting van het endpoint zelf, en dat hiaat wordt aan het einde benoemd in plaats van verdoezeld.

De drie oppervlakken, gescheiden gehouden

Het eerste dat duidelijk moet zijn, is dat dit drie verschillende lagen zijn, en dat de berichtgeving in de pers ze door elkaar haalt.

• De endpoints.Die van OpenAI is POST /v1/decisions, een toegewijde route in plaats van een modus op de Responses API. Die van TypeSafe is POST /v1/systemone. Beide nemen een verzameling bewijsmateriaal plus een lijst met getypeerde vragen en retourneren één antwoord per vraag, gekoppeld aan de naam die je eraan hebt gegeven.

• De modellen. De Decisions API accepteert vandaag precies één model, gpt-6-luna, dat ook de goedkope variant is van de algemene GPT-6-lijn van OpenAI en op 2026-09-22 werd uitgebracht als een gewoon tekst- en beeldmodel. Jev 1.13 is van begin tot eind een beslissingsmodel — het kan helemaal geen vrije tekst genereren. TypeSafe heeft het op 2026-09-15 uitgebracht en het is sinds 2026-09-21 algemeen beschikbaar.

• De clients.OpenAI's eigen SDK's ondersteunen het endpoint al sinds het op 2026-10-06 in openbare bèta ging, dus de plugin is niet de eerste manier om het aan te roepen. Het is de eerste client buiten OpenAI's eigen SDK die we hebben kunnen verifiëren, en de eerste die is geschreven voor een opdrachtregelprogramma in plaats van een applicatiebibliotheek.

De twee meter, zij aan zij

Dit is waar de README van de klant meer waard is dan de aankondiging, omdat de cijfers naast de bewoording staan.

• Prijs — de Decisions API rekent $0,10 per miljoen invoertokens, zonder kosten voor uitvoer, zonder kosten voor cache-lezen en zonder kosten voor cache-schrijven. Jev 1.13 rekent $0,042 per miljoen invoertokens, waarbij uitvoer gratis is. Beide rekenen voor wat je verstuurt en niets voor wat terugkomt, dus een beslissing kost bij beide prijzen een fractie van een cent, en het verschil tussen beide is een factor 2,4, geen ander factureringsmodel.

• Invoer — de Decisions API accepteert tekst, of gebruikersberichten waarin tekst met afbeeldingen wordt gecombineerd, en de README van de plug-in vermeldt dat PNG-, JPEG-, WebP- en GIF-bijlagen worden ondersteund met maximaal 128 afbeeldingen per verzoek. Afbeeldingen moeten als inline base64-data-URL's worden ingevoerd; gehoste HTTP- of HTTPS-afbeeldings-URL's en file_id-invoer worden niet geaccepteerd door het endpoint, dus de plug-in converteert een URL of een lokaal pad voordat deze wordt verzonden. De documentatie van Jev 1.13 is bot in de andere richting: "Geen invoer van afbeeldingen, audio of video," en niet-tekstuele invoer moet worden voorbewerkt tot tekst of gestructureerde velden voordat ze de state bereiken.

• Vraagtypes — OpenAI documenteert er drie: predicate (een waarschijnlijkheid van 0 tot 1 dat een gestelde voorwaarde geldt), choice (één waarde uit je lijst, plus een verdeling en een apart betrouwbaarheidsveld), en score (een waarschijnlijkheidsgewogen gemiddelde over geordende niveaus). De drie van TypeSafe zijn dezelfde drie ideeën onder andere namen: noul voor ja/nee, choice, en score. "Noul" is een afkorting van Bernoulli, en de naam is een goede indicator van het culturele verschil — de ene leverancier levert een alledaags zelfstandig naamwoord, de andere levert een statistiekengrap.

• Score-rekenkunde — de twee komen exact overeen, wat het sterkste teken is dat dit één productcategorie is en niet twee. De documentatie van OpenAI voert drie ernstniveaus met waarschijnlijkheden van 0,1, 0,7 en 0,2 in en krijgt een score terug — bewust tussen twee niveaus in plaats van naar het dichtstbijzijnde af te ronden. De niveaus van Type zijn op dezelfde manier nulgeïndexeerd, en de plugin Jev accepteert tussen twee en tien geordende niveaus. De documentatie van OpenAI vermeldt niets dergelijks; dat is een leemte in hun documentatie, niet een beperking die we kunnen stellen.

• Budgetten — Jev documenteert zijn venster nauwkeurig: ongeveer 64.000 tokens per verzoek, waarvan ongeveer 32.000 voor de status plus de langste afzonderlijke vraag, tegenover de context van 1.050.000 tokens die onze eigen catalogus voor GPT-6 Luna als algemeen model vermeldt. De beslissingenpagina van OpenAI publiceert helemaal geen tokenbudget, alleen de opmerking dat regionale verwerkingspremies en vermenigvuldigingsfactoren voor long-contextinvoer nog steeds van toepassing zijn op het tarief.

Wat de cliënt onthult dat de aankondiging niet deed

Drie details in de plugin en de bijbehorende README zijn het uitlichten waard, omdat elk ervan verandert hoe je het endpoint zou aansluiten.

Het eerste is dat een beslissing kan terugkomen als een weigering. OpenAI's documentatie legt dit nooit in proza uit, maar elk SDK-voorbeeld vertakt erop — answer.type === "refusal" in JavaScript, een OpenAI::Models::Decision::Answer::Refusal case in Ruby — en de README van de plugin spelt uit dat een afgewezen vraag bewaard blijft als {"name":"...","type":"refusal"}. Het antwoordtype heeft dus in feite vier waarden, niet drie, en elke productie-loop moet een vierde vertakking afhandelen die geen enkele aankondiging noemde.

Het tweede is wat er aan de plug-in ontbreekt, niet wat erin aanwezig is. Willisons eigen post zet het werk neer als het laten lezen van de nieuwe documentatie door GPT-6 Astra en het daaruit laten bouwen van de client — documentatie-naar-client, in één keer, zonder menselijke tutorial. Dat is nu een normale manier waarop een client geschreven kan worden, en het betekent dat de vraag of de documentatie van een endpoint volledig genoeg is om er een werkende client uit te genereren, een praktische vraag is geworden in plaats van een redactionele. Voor dit endpoint is het antwoord grotendeels ja, met het weigeringstype als de zichtbare naad.

Het derde is de vorm van de vragenarray. Met OpenAI kun je onafhankelijke vragen in één verzoek tegen gedeelde input plaatsen — een productfoto controleren op schade en de categorie ervan in dezelfde aanroep classificeren — maar voor een vraag die van een eerder antwoord afhangt, zijn aparte verzoeken nodig. Jev neemt om dezelfde reden hetzelfde standpunt in: de vragen worden parallel tegen één state geëvalueerd, dus alles wat sequentieel is, moet twee aanroepen worden. Beide leveranciers hebben fan-out in hun ontwerp opgenomen, en beide vertellen ze je hetzelfde over waar het latentiebudget naartoe gaat.

De categorie heeft nu drie bezetters, en twee daarvan zijn geen algemene modellen.

Het is de moeite waard de derde te noemen, want het kader van het beslissings-eindpunt is alleen zinvol als alle drie in beeld zijn. Perplexity levert een eigen Decisions API, bediend door pplx-decider-v1-27b — een beslissingsmodel met 27 miljard parameters, uitgebracht onder Apache 2.0 met gewichten op Hugging Face op 2026-10-01. Dat geeft de categorie een werkelijk andere vorm dan die van OpenAI: Jev 1.13 is closed en alleen tekst, de decider van Perplexity heeft open gewichten en accepteert afbeeldingen, en de inzending van GPT-6 Luna is een harness rond een algemeen model in plaats van een model dat is gebouwd om te beslissen.

Voor een lezer die vandaag moet kiezen, is het praktische onderscheid smaller dan de marketing. Als je bewijs een zin of een record is en je wilt de goedkoopste kosten per aanroep met de minste variatie in gedrag, is Jev 1.13 de specialist en het tarief van $0.042 is het laagste van de drie gepubliceerde prijzen die we konden verifiëren. Als je bewijs een foto bevat, of je wilt een beslissing van een model dat je al kent van gewone taken, is de Decisions API de enige van de twee gesloten opties die afbeeldingen accepteert. De open-weightoptie beantwoordt een andere vraag — controle en self-hosting — en we hebben die niet getest.

Wat we daadwerkelijk kunnen meten, en wat niemand heeft

De bewering van OpenAI over de endpoint is dat deze "tekst, afbeeldingen of beide evalueert en getypeerde antwoorden retourneert, ongeveer 10x sneller dan de Responses API." Dat is door de leverancier beweerd en niet gereproduceerd: geen regio, geen invoergrootte, geen gelijktijdigheidsniveau, geen service-level agreement, en de baseline is de Responses API in het algemeen in plaats van een specifieke workload. Een enkel cijfer voor de snelheidswinst is het verkeerde getal om een deadline op te baseren.

Wat we ernaast kunnen leggen, is ons eigen serveervenster van zeven dagen dat eindigt op 2026-10-07, voor de twee onderliggende modellen, op basis van het verkeer in onze playground — en het is belangrijk te zeggen wat die cijfers niet zijn. Ze beschrijven gewone generatieverzoeken, geen beslissingen.

• GPT-6 Luna, alle soorten aanvragen: een mediaan van 1.448 ms en een p95 van 4.912 ms, een foutpercentage van 1,31% over 643.394.111 tokens in zeven dagen, wat eruitziet als een doorvoer van ongeveer 125 uitvoertokens per seconde wanneer het model aan het schrijven is.

• Jev 1.13: een mediaan van 149 ms en een p95 van 245 ms, een foutpercentage van 0,10% over 110.193.080 tokens. Dat is een werkelijk snel eindpunt, en het is snel omdat het geen antwoord genereert — het retourneert getallen voor een toestand die eenmalig wordt ingelezen.

Tegen elkaar afgezet zijn die twee rijen een waarschuwing, geen vergelijking. Een beslissingsverzoek genereert een handvol tokens, dus op de Decisions API is de output-throughputwaarde die het algemene profiel van Luna domineert niet langer de bindende beperking, en het getal dat belangrijk begint te worden is hoe lang het model erover doet om het bewijsmateriaal te lezen. We hebben dat niet gemeten op het decisions-endpoint, en voor zover wij kunnen nagaan heeft niemand buiten OpenAI het gepubliceerd.

De diepere, ongemeten vraag is calibratie, en die bepaalt of hiervan überhaupt iets bruikbaar is. Een waarschijnlijkheid van 0,92 voor zichtbare schade is alleen de moeite waard om op te routeren als, in je verkeer, de foto's die rond 0,92 scoorden in ongeveer 92% van de gevallen beschadigd zijn. De documentatie van OpenAI zegt dat je drempelwaarden moet instellen op basis van gelabelde voorbeelden en ze moet kiezen op basis van de kosten van fout-positieven tegenover fout-negatieven. Dat is goed advies, en het is ook een erkenning dat de calibratie van deze getallen iets is dat je zelf moet vaststellen. Meet voor een eerste verkenning de verdeling van de geretourneerde waarschijnlijkheden op een steekproef waarvan je de antwoorden al kent. Als alles terugkomt op 0,99 of 0,01, doet de drempel geen werk en is het endpoint een zeer dure booleaanse waarde.

Hoe je een van beide kunt uitproberen zonder daarmee een productiepad op het spel te zetten

Bronvermelding, simpel gezegd: het endpointcontract, de prijs- en afbeeldingsregels in dit stuk komen uit OpenAI's eigen Decisions API-documentatie en de README van de plugin, beide gelezen op 2026-10-07; de Jev 1.13-specificatie komt uit TypeSafe's eigen modeldocumentatie; de serveercijfers zijn onze eigen playgroundgegevens over het venster van zeven dagen eindigend op 2026-10-07; de pakket-tijdstempels komen van PyPI en de Git-geschiedenis van het project. De 10x-snelheidsclaim is van OpenAI en is als zodanig gelabeld. De licentie en releasedatum van de open-weight decider komen uit de modelrepository.

De Decisions API zelf is OpenAI's eigen verpakking en wij routeren die niet; als je dat specifieke endpoint wilt, dan is OpenAI waar het zit. De modellen daaronder zijn een ander verhaal. GPT-6 Luna is een live route op OrcaRouter tegen OpenAI's lijstprijs, met nul markup die wordt doorberekend, en typesafe/jev-1.13 tegen lijstprijs staat op dezelfde key, waardoor de vergelijking in dit artikel iets is dat je kunt uitvoeren in plaats van lezen: dezelfde state, dezelfde vragen, twee endpoints, één contract om te beheren en geen tweede factuur.

Dat is ook de verstandige manier om een onbewezen oppervlak te adopteren. Zet de beslissing achter een fallback, zodat een weigering, een time-out of een bètalimiet die onder je voeten verandert, degradeert naar een op prompts gebaseerde aanroep in plaats van een storing, en houd die fallback op dezelfde sleutel als de primaire, zodat er niets opnieuw bedraad hoeft te worden wanneer de endpoint richting algemene beschikbaarheid beweegt. OpenAI zegt dat GA in de komende weken wordt verwacht en dat gpt-6-luna in de tussentijd het enige beschikbare model is; beide zijn redenen om tegen de vorm te bouwen en het nu te instrumenteren, en geen van beide is een reden om er al een betalingsautorisatie achter te zetten.

Wat nu te kijken

Drie dingen zouden de vragen kunnen beslechten die dit stuk niet kan. Een gepubliceerd tokenbudget voor het decisions-endpoint, zodat een verzoek kan worden gedimensioneerd in plaats van gegokt. Elke GA-aankondiging, het punt waarop het input-only tarief ophoudt een bèta-belofte te zijn. En één onafhankelijke meting van latentie en kalibratie op het endpoint zelf — de eerste persoon die er een paar duizend gelabelde paren doorheen haalt en de betrouwbaarheidscurve publiceert, zal meer voor de categorie doen dan beide launchposts deden.

Tot dan is de eerlijke samenvatting beperkt en nuttig: als hetgeen je moet beslissen tekst is, is Jev 1.13 goedkoper en geeft het getallen terug in ongeveer 150 milliseconden in ons verkeer. Als hetgeen je moet beslissen een afbeelding bevat, is OpenAI's Decisions API degene die ernaar zal kijken, tegen 2,4 keer de invoerprijs, met een bètalabel op de doos. Beide zijn vanaf deze week aanroepbaar vanaf de opdrachtregel, en dat is een betere positie dan die waarin een van beide zich zeven dagen geleden bevond.