A lot of what AI agents do all day isn't writing. It's deciding. Does this invoice match the purchase order? Which of these 12 categories does this ticket belong in? Is this email a phishing attempt? Most teams send those questions to the same large model they use for everything else, and pay for a paragraph of reasoning they throw away.
That's changing fast. TypeSafe's Jev and OpenAI's Decisions API, which OpenAI opened to all developers in October, are built to answer exactly that kind of question. You give them a question and a fixed list of allowed answers, and they return a probability for each one. No paragraph, no reasoning to parse. Just the answer and how confident the model is.
The numbers on cost are striking. But the more useful finding from the early public tests isn't about price. It's that how you write the question matters more than which model answers it.
What is a decision model?#
A decision model answers a bounded question you define, like yes or no, pick one from this list, or score this on a rubric, and returns a probability instead of text. It can't write, explain or critique. It's built for the narrow, repeated choices inside a workflow.
Think of the difference between asking a senior analyst to write you a memo on whether an invoice looks right, and handing a trained clerk a checklist. The clerk is faster, cheaper and, on the checklist, often just as good. The clerk also can't tell you why something feels off. You need both, for different jobs.
OpenAI's version runs on a model called gpt-6-luna, and it's priced at $0.10 per million input tokens with no charge for output. Jev came first and has the most public testing so far, so most of the numbers below are Jev's.
How close is it to a frontier model?#
Close, on the right kind of question. In one public test on 3,080 banking support messages, Jev sorted 81% correctly and Claude Opus sorted 84%. Jev was about 13 times faster and cost about 1/22 as much.
The test, published by OpenRouter, used Banking77, a standard set of customer support messages sorted into 77 intents like "card not working" or "refund not showing." Both models got the same one-line description of each intent.
Opus came out 3.3 points ahead, which is a real gap. The two agreed on 89% of messages. Jev's median response time was 175 milliseconds against Opus's 2.3 seconds. On cost, Jev ran $0.11 per thousand messages against $2.42 for Opus with prompt caching, and about $19 per thousand without it.
At a million messages a month, that's roughly $110 against $2,400 to $19,000. For one step in one workflow.
What does a handoff buy you?#
Most of the accuracy at a fraction of the cost. Let the decision model answer when it's confident and send only its unsure cases to the larger model. In the same test, that handled about three quarters of messages with Jev and matched Opus to within half a point, at about 28% of Opus's cost.
This pattern is called a cascade, and it's the most useful thing in these early results. The decision model returns a probability with every answer. Above a threshold you set, you take its answer. Below it, the case goes to the larger model, or to a person.
At a 0.90 threshold, Jev handled 76% of the messages on its own, overall accuracy was 84.0%, and the cost was $0.69 per thousand. The author is careful to note the threshold was set on the same messages it was scored on, so treat that as a best case. Builders are reporting the same shape on their own work. One tested a client follow-up agent on 40 requests and matched Opus at a fraction of the decision cost, with low-confidence matches going back to Opus for review. That review caught 5 wrong matches.
Where you set the threshold matters as much as the model. A research team summarized by DAIR.AI found a threshold fitted to the agent's own past work cut cost 14.2% without changing the outcome of any of 500 tasks. A fixed threshold of 0.5 lost 21.5 points of accuracy.
Why does the question matter more than the model?#
Because the same model, on the same kind of emails, scored 63% when asked once whether an email was phishing and 95% when the question was split into five narrow checks. Nothing about the model changed. The question did.
That result comes from a set of tests by Rajesh Beri. Asked "is this phishing?" on 2,000 synthetic emails, Jev scored 62.6%. Split into five specific questions, such as whether the links point to shortened URLs or free hosting, and whether the sender uses a free email address while claiming to be an organization, it scored 95% on a fresh set of 1,000 emails. Anthropic's smaller Claude Haiku model scored 93.2% on the same five checks.
The same tests found that a badly worded description of what each answer means scored below random. The model didn't fail. The question did.
So the model call was never the hard part. Writing the question, the allowed answers and the threshold is. That's business logic, and it belongs somewhere you own: written down, reviewed by the person who owns the decision, and kept outside any one model. We wrote more about that in Swap the Model, Keep the Logic.
Where does it break?#
When the rule isn't in the text. A decision model can only judge what it can see. Beri found one ticket-priority question where the rule lived outside the ticket, and Jev was right 45% of the time while reporting 74% confidence. It also can't tell you why it decided.
Confidence scores are useful, but they aren't guaranteed to be honest on your data. In the same tests, Jev's yes-or-no answers were underconfident and its pick-one and score answers were overconfident. That's why the threshold has to be fitted on your own decisions, not taken from a blog post.
The other limit is the one practitioners mention most. A decision model gives you a verdict, not a critique. When it gets something wrong, you don't get the reasoning. For steps where a person needs to see why, keep a model that writes, or keep the person.
Where does it fit in a build?#
In the narrow, repeated choices inside a workflow: routing, matching, classifying, checking a document against a rubric. Not in the steps that need judgment across many sources or a written explanation.
We've started putting Jev into our builds for exactly these steps. In a typical finance workflow, a larger model still reads the messy documents and pulls out the fields. Ordinary code does the math and the purchase order match. The decision model sits in between, answering the dozens of small questions that used to cost a full model call each: which cost center, which vendor, is this a duplicate.
How do you try it?#
Run it in shadow on decisions you've already made. Pull 1,000 to 2,000 past decisions where a person made the final call, run the decision model alongside without acting on it, and find the confidence level where it clears your accuracy bar.
Beri's article lays out a version of this. Pin the model version so it doesn't change under you. Add a "none of these" option to every pick-one question. Have the person who owns the decision review the wording. Fit the threshold on half the set and score it on the other half. Then compare the cost per correct decision against the cheapest model you use today.
If you can't write the list of allowed answers for a step, that's useful to learn too. It means the step isn't ready to automate yet.
For the other side of this, why getting the same answer twice isn't the same as getting the right one, read Repeatable Isn't Right.
Sources#
- OpenRouter, Is Jev as accurate as frontier models at classification? (updated Oct 16, 2026)
- Rajesh Beri, TypeSafe's Jev scores 62.6% asked once and 95% split five ways (Sept 20, 2026)
- AI Weekly, OpenAI opens Decisions API to all at $0.10 per million tokens
- The New Stack, OpenAI's Decisions API
- Akshay Pachaar on X, Jev in an agent harness (Oct 13, 2026)
- DAIR.AI on X, decision models in agent harnesses (Oct 17, 2026)