For most of 2026, "a model that picks instead of writes" meant one product: Jev, TypeSafe's System One model. That changed this autumn. OpenAI announced a Decisions API at DevDay, released it in beta on 6 October, and made it generally available on 22 October with gpt-6-luna as its only model.
The idea is the one we have been building on: you define the possible answers, the model returns a typed answer plus probabilities, and no prose comes back to parse. The contracts are different enough that porting is a real job, though. This article puts them side by side, prices them, and says which one we reach for and when.
What OpenAI shipped
The Decisions guide describes a separate endpoint, POST https://api.openai.com/v1/decisions, not a mode of the Responses API. A request has three parts:
model: gpt-6-luna.input: the shared evidence. A string, or an array of user messages whose content parts can be input_text, input_image (a base64 data URL or a public image URL) or input_json for structured data.questions: an array of 1 to 400 questions. Each has a type, a unique name and instructions.
There are three question types. They will look familiar:
| OpenAI |
Jev |
What it answers |
Returns |
predicate |
noul |
Is this statement true? |
A probability from 0 to 1 |
choice |
choice |
Which of these options? |
The choice, per-option probabilities, confidence |
score |
score |
Which level on this ordered scale? |
A probability-weighted score, per-level probabilities, confidence |
OpenAI's score works the way Jev's does: it is the probability-weighted average of 0-based level indices, so it can fall between levels. A score needs 2 to 10 levels. Answers come back in an answers array, each echoing its question's name. An answer can also come back with type: "refusal", which your code must handle.
The two contracts, side by side
The concepts map one to one. The JSON does not. Pick an example, switch between request and response, edit the text, and tap a concept to see where it lives in each payload.
The differences that matter when you port:
- Objects versus arrays. Jev keys questions and answers by an id you choose. OpenAI uses arrays and echoes each question's
name. Code that reads answers.team.choice becomes a lookup by name.
- Options. Jev puts options in
criteria: a map of option to description for Choice, an ordered array of descriptions for Score. OpenAI uses choices (value plus description) and levels (label plus description).
- Yes/no criteria. A Jev Noul can carry
true and false criteria. OpenAI's predicate documents only instructions, so the definition of "true" has to move into the instruction text.
- Probabilities. Jev returns a map of option to probability. OpenAI returns an array of objects. The numbers mean the same thing.
- Ids are invisible to the model in Jev. TypeSafe is explicit that question ids are never sent to the model. Put the full meaning in
instructions either way and the port is mechanical.
Both endpoints bill input tokens only. The answer is a handful of numbers, and neither vendor charges for it.
|
Jev 1.14 |
OpenAI Decisions |
| Uncached input |
$0.042 per million tokens |
$0.10 per million tokens |
| Output |
Free |
Free |
| Caching |
Not offered |
Discounted cache reads, charged cache writes, 1,024-token minimum prefix |
So at list price OpenAI's endpoint costs about 2.4 times what Jev does for the same input. OpenAI's prompt caching narrows that when many requests share a long prefix, such as the same policy document checked against thousands of messages. OpenAI also notes that regional processing premiums and long-context multipliers apply. It has not published the cached rate on the Decisions page, so measure it on your own traffic before you count on it.
Both are a rounding error next to a general model. Move the sliders to see how far apart the options are at your volume:
Limits and capabilities
|
Jev 1.14 |
OpenAI Decisions |
| Question types |
Choice, Score, Noul, Box |
Choice, Score, Predicate |
| Questions per request |
Not capped on the models page; up to 255 options per Choice |
1 to 400 |
| Context |
64k per request, 32k per question (262k with a long-context header) |
Not published on the guide |
| Images |
PNG and JPEG with a TypeSafe-Danger-Zone-Images header |
Data URLs and public image URLs, in input and in question instructions |
| Structured input |
JSON object or array as state |
input_json content parts |
| Model versions |
Pinned ids (jev-1.14.0) and aliases (jev-latest, jev-preview) |
gpt-6-luna |
| Where |
TypeSafe API and SDKs, OpenRouter |
OpenAI API |
Two items deserve a note. Jev 1.14, released on 14 October, added image input and a fourth question type, Box, which finds where something is in an image. We cover it in Jev 1.14: images and the Box primitive. And OpenAI's endpoint can evaluate a whole conversation as input, which suits checking a chat transcript turn by turn. OpenAI also added a native Decisions integration to its GPT-Live voice sessions on 15 October.
Latency claims
OpenAI says the endpoint answers "about 10x faster than the Responses API" on the same model. That is a relative claim with no absolute numbers or workload attached, and independent write-ups treat it as an unverified vendor figure. For Jev we have our own measurements: 340 to 530 ms end to end through OpenRouter for our internal tools. Measure both on your own payloads, from your own region, before you design around either number.
Which one we reach for
We have not moved our tools off Jev, for three reasons. It is cheaper per input token. It returns answers keyed by the ids our code already uses. And we can pin an exact build, which matters because confidence thresholds are tuned against a specific model version. See Reading the numbers for why.
OpenAI's endpoint earns a look when you are already on the OpenAI platform and want one bill, when you need to judge long shared context that caching makes cheap, or when you want decisions inside a GPT-Live voice session.
The bigger point is that the category is now two vendors deep. Typed decisions with probabilities are becoming a standard API shape, the way chat completions did. Write your decision layer behind a small interface of your own, with your question definitions in one place, and switching vendors stays a weekend job, not a rewrite.
If you want help choosing or building that layer, see our AI engineering services or start a conversation.
FAQ
What is the OpenAI Decisions API?
A separate OpenAI endpoint, POST /v1/decisions, that answers typed questions about text, images or JSON with probabilities instead of generated text. It was announced at DevDay 2026, entered beta on 6 October 2026 and became generally available on 22 October 2026, with gpt-6-luna as its only model.
How much does the OpenAI Decisions API cost?
Uncached input costs $0.10 per million tokens and output tokens are free. Cache reads are discounted and cache writes are charged. Jev 1.14 costs $0.042 per million input tokens, also with free output.
Is OpenAI's predicate the same as Jev's Noul?
They answer the same kind of question and both return the probability that a statement is true. Jev returns it as noul and accepts optional true and false criteria; OpenAI returns it as probability and takes the definition in instructions.
Can I move from Jev to the OpenAI Decisions API?
Yes, mechanically. Convert the questions object to an array with a name per question, move Choice criteria into choices and Score criteria into levels, fold Noul criteria into the predicate instructions, and read answers by name. Re-tune your confidence thresholds afterwards, because a different model produces differently shaped probabilities.