OpenAI's Decisions API and the Rise of Decision-Only Models
Synergised Consulting Ltd
Last Updated: 3 October 2026
OpenAI now sells a decision endpoint as well as a chat endpoint. The Decisions API, announced at DevDay 2026 on 29 September, answers a question you define by picking from a fixed list of answers you allow, in about 150 milliseconds, and it arrived two weeks after TypeSafe's Jev proved that decision-only models are their own category rather than a rounding error. If your agents route requests, classify content or gate their own actions, the market for that one narrow job just gained a second giant, and the way you evaluate it matters more than which badge you pick.
What the Decisions API Actually Is
The Decisions API is an endpoint that takes context, such as a support ticket or an image, plus questions you have written in advance with a finite list of allowed answers, and returns one selection your code can act on. According to The New Stack [1], it is built on GPT-6 Luna, OpenAI's smallest and most affordable model, and OpenAI claims about 150 milliseconds per decision, against 1.6 seconds for the same choice made through a regular Luna call. OpenAI's own stated jobs are classifying content, routing requests, and choosing an agent's next action [2].
Concretely, a ticket arrives. You send its text with the question "which queue does this belong to?" and the allowed answers Billing, Shipping, Technical or Other. One selection comes back and your code routes on it. Nothing is written out word by word, which is exactly why the call is fast: the endpoint constrains the model to picking, not composing.
What it is not yet is generally available. It sits in limited preview, and independent testing found a standard API key still receiving an HTTP 403 gate on 2 October, three days after a broad release was promised for "the coming days", with no public documentation page at all [3]. Until that changes, a developer who needs the same behaviour today can get close with Luna and a strict structured-output schema that forces an answer from a fixed list.
What You Give Up by Constraining the Model
The constraint is the product, and it is also the limit. A decision endpoint cannot explain itself, draft a reply, or handle a question whose answer is not on your list. If the ticket is about something you never anticipated, the endpoint will still return one of your four answers, confidently. Designing the list, and the escape hatch for "none of these", is your job, and it is where the real work of integrating one of these endpoints sits.
Why OpenAI Moved Two Weeks After Jev
TypeSafe launched Jev on 15 September 2026 as a hosted model that answers typed decision questions and returns a probability distribution instead of text [4]. Two weeks later OpenAI shipped an endpoint for the same job. That sequence is the news: a category that did not have a name in August now has an independent vendor with published pricing and the largest model provider in the market competing in it.
According to The New Stack's report from the keynote [1], the rise of Jev made decision models "incredibly popular", and the announcement was OpenAI's direct answer. For a business owner this is the familiar and useful shape of a young market: an independent proves demand, an incumbent validates it, and the validation usually arrives with better availability and pressure on price. Jev is open to everyone today at $0.042 per million input tokens with output free, 70 to 500 milliseconds end to end, and Choice questions taking up to 255 options [4]. The Decisions API accepts images, which Jev does not, but has no published price, no published option limit, and no docs [1] [3].
Vendor Claims Against Measured Reality
Treat the headline speed numbers as starting points, not verdicts. OpenAI's 150 milliseconds is a vendor claim under unstated conditions. Jev's published 70 to 500 milliseconds range is the vendor's own span, but independent production telemetry reported by Firecrawl measured Jev at a median of 0.21 seconds and a 95th percentile of 0.34 seconds across real OpenRouter traffic [5], which lands in the same ballpark as OpenAI's claim rather than clearly ahead or behind it.
The same scepticism applies to cost claims. BigBangIndex analysed TypeSafe's launch headline of 444 times cheaper than a frontier model and found the ratio was measured against the single worst baseline on that axis [6]. Against GPT-5.6 Terra, the peer model TypeSafe itself names, the same figures give roughly 76 times cheaper, still a serious result but a sixth of the poster. BigBangIndex's more useful finding is that the advertised saving assumes every decision is handled without escalation; once low-confidence cases pass to a better model, the break-even against simply using a cheap large language model sits near an 89 percent auto-handle rate, and the durable case for a decision model becomes latency rather than price [6].
How to Benchmark One Yourself
Whichever endpoint you trial, measure it the way these figures were not assembled. Record latency from your own network position, not the vendor's; run questions through exactly as your application will ask them; and score the answers against cases where you already know the right routing. A decision endpoint is cheap enough that a 100-case shadow run costs pennies and tells you more than any launch slide.
The Question Neither Vendor Has Answered
Both products are strongest at the easy call and quietest about the hard one. Routing a ticket into the right queue is a bounded question with an observable right answer, and it is where decision models shine. Knowing when not to act, whether it is safe to auto-reply to a customer without a human reading it first, is a different and riskier judgement, and independent testing suggests it stays hard even for much larger models. In one hands-on evaluation, every setup tested picked the correct support queue 40 times out of 40, but on the question "is this safe to auto-reply?", Luna without reasoning answered correctly 33 times out of 40, and even GPT-6.1 Sol reached 39 of 40 [3].
That gap is the whole governance question in miniature. A wrong queue costs a few minutes of delay. A wrong auto-reply goes straight to a customer with nobody in the loop. Neither OpenAI nor TypeSafe has published calibration evidence, an honest measure of whether the confidence scores attached to decisions can be trusted as thresholds, for its decision product. Until one does, the confidence score is a number you must validate against your own cases before you let it gate anything a customer will see.
What an Owner Running Agents Can Take From This
In discovery workshops, the workflows that separate themselves as automation candidates are rarely the long ones. They are the small forks buried inside them: which queue, which template, escalate or proceed, approve or hold. Owners routinely describe hours lost to those forks being answered by a person, one at a time, at the centre of a process everything else waits on. Decision-only endpoints are aimed precisely at that layer, and the arrival of a second major vendor makes the option cheaper and more legitimate than it was a month ago.
The practical takeaway is to know which kind of decision you are buying. If the question is bounded, high-volume, and wrong answers are cheap to correct, a decision endpoint with a measured threshold is now a serious option, and testing one costs almost nothing. If the decision carries customer-facing risk, the evidence so far says keep a human or a stronger model on the escalation path, and treat the endpoint's confidence score as something to earn trust in, not assume.
Sources
- [1] The New Stack: OpenAI answers TypeSafe's Jev with a Decision API built on Luna.
- [2] InfoQ: OpenAI DevDay 2026 Recap for Developers.
- [3] eesel AI: OpenAI Decisions API explained: how it works and who it's for.
- [4] TypeSafe AI: Jev product site (published specifications and pricing).
- [5] Firecrawl: OpenAI's Decisions API vs Jev: Inside the Decision-Model Architecture.
- [6] BigBangIndex: Jev vs LLMs: Why TypeSafe's 444x Cost Claim Becomes 10x in Production.
