Var OpenAI:s Decisions API slutar och Jev börjar: Vad den första externa klienten visar

Klockan 23:05 UTC den 6 oktober 2026 publicerades ett plugin som heter llm-openai-decisions på PyPI, och dess egen README innehåller meningen som lanseringsbevakningen aldrig tryckte: "Till skillnad från Jev, den nya gpt-6-luna-beslutsmodellen stöder bildinmatning utöver text." Författaren är Simon Willison, som också skrev den första klienten för TypeSafe:s beslutsmodell, och jämförelsen han gör är mellan GPT-6 Luna – modellen bakom OpenAI:s Decisions API – och Jev 1.13, TypeSafe:s System One-modell som bara hanterar text. Samma blogginlägg noterar att själva pluginet skrevs av GPT-6 Astra när den läste OpenAI:s dokumentation.

Det är det användbara med en klient som släpps en vecka efter ett API: den är skriven mot förfrågans form, inte mot keynoten, så den synliggör de skillnader som marknadsföringstexten slätar över. Inget här är en läcka och inget här är obekräftat – varje siffra nedan kommer från en sida som publicerats av OpenAI, TypeSafe eller pluginets eget arkiv, alla lästa den 2026-10-07. Det som fortfarande saknas är oberoende mätning av själva endpointen, och den luckan anges i slutet i stället för att överskylas.

De tre ytorna, hållna åtskilda

Det första man måste reda ut är att dessa är tre olika lager, och pressbevakningen suddar ut dem.

• Slutpunkterna. OpenAI:s är POST /v1/decisions, en dedikerad rutt i stället för ett läge i Responses API. TypeSafe:s är POST /v1/systemone. Båda tar emot ett bevisunderlag plus en lista med typade frågor och returnerar ett svar per fråga, med det namn du angav som nyckel.

• Modellerna. Decisions API accepterar i dag exakt en modell, gpt-6-luna, som också är den billiga nivån i OpenAIs allmänna GPT-6-serie och släpptes den 2026-09-22 som en vanlig text- och bildmodell. Jev 1.13 är en beslutsmodell helt och hållet – den kan inte producera fritext alls. TypeSafe släppte den 2026-09-15 och den har varit allmänt tillgänglig sedan 2026-09-21.

• Klienterna. OpenAIs egna SDK:er har stött slutpunkten sedan den öppnades i offentlig beta den 2026-10-06, så pluginen är inte det första sättet att anropa den. Det är den första klienten utanför OpenAIs egen SDK som vi har kunnat verifiera, och den första som är skriven för ett kommandoradsverktyg i stället för ett applikationsbibliotek.

De två mätarna, sida vid sida

Det här är ett fall där klientens README är värd mer än tillkännagivandet, eftersom siffrorna står bredvid formuleringarna.

• Pris — Decisions API debiterar 0,10 USD per miljon indatatoken utan avgift för utdata, utan avgift för cacheläsning och utan avgift för cacheskrivning. Jev 1.13 debiterar 0,042 USD per miljon indatatoken med gratis utdata. Båda debiterar för det du skickar och inget för det som kommer tillbaka, så ett beslut kostar en bråkdel av en cent till endera priset och skillnaden mellan dem är en faktor på 2,4, inte en annan faktureringsmodell.

• Indata — Decisions API tar emot text, eller användarmeddelanden som blandar text med bilder, och pluginets README anger att PNG-, JPEG-, WebP- och GIF-bilagor stöds med högst 128 bilder i en begäran. Bilder måste skickas in som inline-base64-data-URL:er; värdbaserade HTTP- eller HTTPS-bild-URL:er och file_id-indata accepteras inte av slutpunkten, så pluginet konverterar en URL eller en lokal sökväg innan den skickas. Jev 1.13:s dokumentation är tydlig åt andra hållet: "Ingen bild-, ljud- eller videoindata," och icke-textindata bör förbehandlas till text eller strukturerade fält innan de når tillståndet.

• Frågetyper — OpenAI dokumenterar tre: predicate (en sannolikhet från 0 till 1 att ett angivet villkor gäller), choice (ett värde från din lista, plus en distribution och ett separat konfidensfält) och score (ett sannolikhetsviktat medelvärde över ordnade nivåer). TypeSafes tre är samma tre idéer under andra namn: noul för ja/nej, choice och score. "Noul" är kort för Bernoulli, och namnet är en rättvis markör för den kulturella skillnaden — en leverantör levererar ett vardagligt engelskt substantiv, den andra levererar ett statistikskämt.

• Poängaritmetik — de två stämmer exakt överens, vilket är det starkaste tecknet på att detta är en produktkategori snarare än två. OpenAI:s dokumentation matar in tre allvarlighetsnivåer med sannolikheterna 0,1, 0,7 och 0,2 och får tillbaka en poäng på 1,1 — avsiktligt mellan två nivåer i stället för att snäppa till den närmaste. TypeSafe:s nivåer är nollindexerade på samma sätt, och plugin-programmet för Jev tar mellan två och tio ordnade nivåer. OpenAI:s sida anger inget tak; det är en frånvaro i deras dokumentation, inte en gräns vi kan hävda.

• Budgetar — Jev dokumenterar sitt fönster exakt: ungefär 64 000 tokens per begäran, varav omkring 32 000 täcker tillståndet plus den längsta enskilda frågan, mot den kontext på 1 050 000 tokens som vår egen katalog anger för GPT-6 Luna som allmän modell. OpenAIs beslutssida publicerar ingen tokenbudget alls, bara noteringen att regionala bearbetningstillägg och indatamultiplikatorer för lång kontext fortfarande tillämpas på taxan.

Vad klienten avslöjar som tillkännagivandet inte gjorde

Tre detaljer i insticksprogrammet och dess README är värda att lyfta fram, eftersom var och en förändrar hur du skulle koppla upp slutpunkten.

Det första är att ett beslut kan komma tillbaka som en vägran. OpenAI:s dokumentation förklarar aldrig detta i löpande text, men varje SDK-exempel förgrenar sig på det — answer.type === "refusal" i JavaScript, ett OpenAI::Models::Decision::Answer::Refusal-fall i Ruby — och pluginets README klargör att en avböjd fråga bevaras som {"name":"...","type":"refusal"}. Så svarstypen är i praktiken fyra värden, inte tre, och varje produktionsloop måste hantera en fjärde gren som ingen tillkännagivelse nämnde.

Det andra är vad som saknas i plugin-programmet snarare än vad som finns i det. Willisons eget inlägg ramar in arbetet som att GPT-6 Astra läser den nya dokumentationen och bygger klienten utifrån den – dokumentation-till-klient, i ett svep, utan mänsklig handledning. Det är nu ett normalt sätt för en klient att bli skriven, och det innebär att frågan om en endpoints dokumentation är tillräckligt fullständig för att kunna generera en fungerande klient utifrån den har blivit praktisk snarare än redaktionell. För den här endpointen är svaret mestadels ja, med avvisningstypen som den synliga sömmen.

Den tredje är formen på frågearrayen. OpenAI låter dig lägga oberoende frågor i en enda begäran mot delad indata – kontrollera ett produktfoto för skador och klassificera dess kategori i samma anrop – men kräver separata begäranden när en senare fråga beror på ett tidigare svar. Jev intar samma ståndpunkt av samma anledning: dess frågor utvärderas parallellt mot ett enda tillstånd, så allt sekventiellt måste bli två anrop. Båda leverantörerna har designat för fan-out, och båda säger samma sak om var latensbudgeten hamnar.

Kategorin har nu tre innehavare, och två av dem är inte generella modeller

Det är värt att nämna den tredje vid namn, eftersom ramverket kring beslutsändpunkten bara är begripligt med alla tre i åtanke. Perplexity levererar ett eget Decisions API, som betjänas av pplx-decider-v1-27b — en beslutsmodell med 27 miljarder parametrar som släpptes under Apache 2.0 med vikter på Hugging Face den 1 oktober 2026. Det ger kategorin en helt annan form än OpenAIs: Jev 1.13 är stängd och enbart textbaserad, Perplexitys decider har öppna vikter och tar emot bilder, och GPT-6 Lunas bidrag är ett ramverk kring en allmän modell snarare än en modell byggd för att fatta beslut.

För en läsare som väljer idag är den praktiska uppdelningen snävare än marknadsföringen. Om ditt underlag är en mening eller en post och du vill ha lägsta kostnad per anrop med minst variation i beteende, är Jev 1.13 specialisten och dess taxa på $0.042 är den lägsta av de tre publicerade priser vi kunde verifiera. Om ditt underlag innehåller ett fotografi, eller om du vill ha ett beslut från en modell som du redan känner till från vanliga uppgifter, är Decisions API det enda av de två slutna alternativen som accepterar bilder. Alternativet med öppna vikter svarar på en annan fråga – kontroll och egen hosting – och vi har inte testat det.

Vad vi faktiskt kan mäta, och vad ingen har

OpenAI:s påstående om slutpunkten är att den "utvärderar text, bilder eller båda och returnerar typade svar ungefär 10 gånger snabbare än Responses API." Det är leverantörsuppgivet och inte reproducerat: ingen region, ingen indatastorlek, ingen samtidighetsnivå, inget servicenivåavtal, och baslinjen är Responses API i allmänhet snarare än någon specifik arbetsbelastning. En enskild uppsnabbningssiffra är fel siffra att basera en deadline på.

Det vi kan ställa bredvid det är vårt eget sjudagars serveringsfönster som slutar 2026-10-07 för de två modellerna nedan, från vår playground-trafik – och det är viktigt att säga vad dessa siffror inte är. De beskriver vanliga genereringsförfrågningar, inte beslut.

• GPT-6 Luna, alla typer av förfrågningar: en median på 1 448 ms och en p95 på 4 912 ms, en felfrekvens på 1,31 % över 643 394 111 token under sju dagar, vilket är hur en genomströmning på omkring 125 utdatatoken per sekund ser ut när modellen skriver.

• Jev 1.13: en median på 149 ms och en p95 på 245 ms, en felfrekvens på 0,10 % över 110 193 080 tokens. Det är en genuint snabb slutpunkt, och den är snabb eftersom den inte genererar något svar – den returnerar tal för ett tillstånd som läses in en gång.

Läser man de två raderna mot varandra är de en varning, inte en jämförelse. En beslutsförfrågan skickar ut en handfull tokens, så i Decisions API slutar siffran för utdatagenomströmning som dominerar Lunas allmänna profil att vara den bindande begränsningen, och den siffra som börjar spela roll är hur lång tid modellen tar på sig att läsa bevisningen. Vi har inte mätt det på decisions-endpointen, och såvitt vi kan bedöma har ingen utanför OpenAI publicerat det.

Den djupare frågan som inte mäts är kalibrering, och det är den som avgör om något av detta är användbart. En sannolikhet på 0,92 för synlig skada är bara värd att routa på om fotona i hela din trafik som fick en poäng nära 0,92 är skadade ungefär 92 % av gångerna. OpenAIs dokumentation säger att du ska ställa in tröskelvärden utifrån märkta exempel och välja dem efter kostnaden för falska positiva jämfört med falska negativa. Det är ett korrekt råd, och det är också ett medgivande att kalibreringen av dessa siffror är något du måste fastställa själv. Som en första ansats: mät fördelningen av returnerade sannolikheter i ett urval där du redan vet svaren. Om allt kommer tillbaka på 0,99 eller 0,01 gör tröskelvärdet ingen nytta och endpointen är ett mycket dyrt booleskt värde.

Så här provar du endera utan att satsa en produktionsväg på det

Källor, rakt på sak: endpoint-kontraktet, priset och bildreglerna i den här artikeln kommer från OpenAI:s egen dokumentation för Decisions API och pluginets README, båda lästa 2026-10-07; specifikationen för Jev 1.13 kommer från TypeSafe:s egen modelldokumentation; serving-siffrorna är våra egna playground-data över det sjudagarsfönster som slutar 2026-10-07; paketens tidsstämplar kommer från PyPI och projektets Git-historik. Påståendet om 10x hastighet är OpenAI:s och märks som sådant. Licensen och releasedatumet för öppenviktsbeslutaren kommer från dess modellarkiv.

Decisions API i sig är OpenAI:s egen paketering och vi dirigerar inte den; om du vill ha just den slutpunkten är det hos OpenAI den finns. De underliggande modellerna är en annan sak. GPT-6 Luna är en aktiv rutt på OrcaRouter till OpenAI:s listpris utan påslag, och typesafe/jev-1.13 till listpris finns på samma plattform, vilket gör jämförelsen i den här artikeln till något du kan köra snarare än läsa: samma tillstånd, samma frågor, två slutpunkter, ett kontrakt att hantera och ingen andra faktura.

Det är också det förnuftiga sättet att införa en obeprövad yta. Lägg beslutet bakom en fallback så att en vägran, en timeout eller en betagräns som ändras under fötterna på dig degraderas till ett promptbaserat anrop i stället för ett avbrott, och behåll den fallbacken på samma nyckel som den primära så att det inte finns något att koppla om när slutpunkten närmar sig allmän tillgänglighet. OpenAI säger att GA förväntas inom de kommande veckorna och att gpt-6-luna är den enda modellen som är tillgänglig under tiden; båda dessa är skäl att bygga mot utformningen och instrumentera den nu, och inget av dem är ett skäl att lägga en betalningsauktorisering bakom den ännu.

Vad du ska titta på härnäst

Tre saker skulle avgöra de frågor som den här artikeln inte kan. En publicerad tokenbudget för decisions-endpointen, så att en förfrågan kan dimensioneras i stället för gissas. Ett GA-tillkännagivande, vilket är den punkt där input-only-taxan slutar vara ett beta-löfte. Och en oberoende mätning av latens och kalibrering på själva endpointen — den första personen som kör några tusen märkta par genom den och publicerar tillförlitlighetskurvan kommer att göra mer för kategorin än något av lanseringsinläggen gjorde.

Fram till dess är den ärliga sammanfattningen snäv och användbar: om det du behöver fatta beslut om är text, är Jev 1.13 billigare och den returnerar siffror på cirka 150 millisekunder i vår trafik. Om det du behöver fatta beslut om innehåller en bild, är OpenAI:s Decisions API den som kommer att titta på den, till 2,4 gånger indatapriset, med en beta-etikett på förpackningen. Båda kan anropas från en kommandorad från och med den här veckan, och det är en bättre position än den någon av dem befann sig i för sju dagar sedan.