Decision Models vs LLMs: When to Use Jev, OpenAI's Decisions API or a Normal LLM

The short answer

A normal LLM writes. A decision model chooses. Give an LLM a customer message and it can draft a reply, summarise a contract or pull the order lines out of a messy WhatsApp note. Give a decision model the same message plus a few questions you wrote, such as "Is this an order?" or "Which team should own it?", and it returns a typed answer with a probability for each option. It writes no prose at all.

This new class of model is called a decision model. TypeSafe AI, the company behind Jev, also calls them "System One" models, after the fast, intuitive kind of thinking that answers a question at a glance instead of reasoning it out in words.

That one difference changes what each is good for. If the answer is words a person will read, use an LLM. If the answer is one of a set of options you already know, and your software has to act on it, a decision model is usually faster, cheaper and easier to build around.

What a decision model actually is

Decision models became a product category in September 2026. Jev, from the startup TypeSafe AI, launched mid-month. OpenAI's Decisions API was announced at its DevDay on 29 September, opened to all developers in public beta on 6 October, and was made widely available on 22 October.

Both work the same way from the outside. You send:

• The context: a message, a ticket, a document, or a JSON record of the current state.
• Typed questions with answers you define in advance. There are three common shapes:
  • Yes or no: the probability that a statement is true. "Does this message ask for a refund?"
  • Choice: one option from a fixed list, with a probability for each. "Route to sales, support or accounts."
  • Score: a position on a scale or rubric you define. "Urgency from 1 to 5."

You get back structured answers your code can branch on directly. There is no free text to parse and no "the model answered in a paragraph instead of JSON". The output can only ever be one of the answers you allowed.

Under the hood the two products differ. TypeSafe describes Jev as purpose-built, trained only to make calibrated decisions, and says it cannot write prose. OpenAI's Decisions API is its general GPT-6 Luna model constrained to your questions and tuned for speed. OpenAI says it decides up to ten times faster than the same model called through its normal Responses API.

Side by side

When a decision model is the right tool

Reach for a decision model when the question has a small, known set of answers and something happens automatically based on the answer. In our own work, that covers a surprising share of the steps in a real workflow:

• Triage and routing. Which team, which queue, which priority. Every inbound email, WhatsApp message or support ticket starts with this question.
• Guardrail checks. "Does this draft promise a price?", "Does this message contain personal data?", "Is this a complaint?" These are cheap yes-or-no checks that run on every message before anything goes out.
• Choosing an agent's next step. An agent loop is a series of forks: look up the order, ask the customer, or hand over to a person. A decision model makes each fork in a fraction of the time a general model takes to reason through it in text.
• Scoring against a rubric. Lead quality, how complete a document is, whether an answer covers the required points. You write the rubric and the model places each item on it.
• High volume. When a step runs thousands of times a day, the speed and cost difference stops being a detail and becomes the budget.

When to stay with a normal LLM

Keep the LLM wherever the output is language, or the answer can't be listed in advance:

• Writing anything a person reads: replies, summaries, reports, proposals.
• Extracting open values: the quantity, the date, the product name and the delivery address in a message. A decision model can tell you whether a message contains an address; it cannot copy the address out.
• Reasoning over long material: contracts, policies, a month of conversation history.
• Conversation: anything back-and-forth, in Hindi, English or both.
• Questions you haven't anticipated. If you can't write down the possible answers, it isn't a decision yet.

The best systems use both

You rarely have to choose one model. The pattern that works is to put a decision model at every fork, where the answer is one of a known set, and use an LLM only for the steps that need language. The decision model keeps the workflow fast and predictable. The LLM handles the parts only it can do.

Notice the third step. A decision model checking the LLM's own draft ("does this promise something nobody confirmed?") is one of the cheapest and most useful guardrails you can add. The writer and the checker are different models, so they are unlikely to share the same blind spot.

The probabilities are the real feature

The most useful thing a decision model returns isn't the answer, it's the probability next to it. That number lets you decide, in code, how much to trust the model on each item:

Above your threshold, the system acts on its own. Below it, the item goes to a person, with the model's best guess already attached so they decide quickly. You can tune the threshold separately for every decision. Routing a newsletter can be loose; cancelling an order should be strict.

What to be careful about

These products are weeks old. Before you put one at the centre of a workflow:

• Check calibration on your own data. A probability is only useful if 0.9 really means right nine times in ten. Early users of OpenAI's Decisions API reported that yes-or-no questions were well calibrated, while the same question asked as a multiple choice came back far more confident than it should have been. Test both phrasings.
• Option order can move the answer. Testers found that reordering the choices shifted the probabilities. Keep your option order fixed, and check whether it matters for your questions.
• Send only what's relevant. TypeSafe's own documentation warns that accuracy falls as you add irrelevant context. Give the model the state it needs for this decision, not your whole database.
• A decision is not permission. The model can say "this is a cancellation request". Whether that customer is allowed to cancel stays in your code and your rules.
• Run it in shadow mode first. For anything touching money, access or a customer, let the model decide alongside your current process for a few weeks, compare the two, and only then let it act alone.
• Don't pick a vendor from a leaderboard. Public rankings of decision models already disagree with each other. Twenty minutes on a hundred of your own real messages will tell you more.

The decision models, by name

As of late October 2026, these are the names you'll meet:

The category is weeks old, so expect new names and new versions every month.

When to use Jev, OpenAI's Decisions API, or another model

Choose Jev when:

• Your decisions are about text: messages, tickets, emails, form submissions, JSON records.
• You run them at high volume and cost per decision matters.
• You want the documented contract: published schemas, SDKs and a probability for every option, so you can set thresholds with confidence.
• You'd rather not tie the decision step to one large vendor. Access through OpenRouter makes switching easier.

Choose OpenAI's Decisions API when:

• You already build on OpenAI, so the account, billing and data agreements are already in place.
• Your decisions depend on images: photos of goods received, scanned documents, screenshots. Image input was part of it from the start. TypeSafe's 1.14 release adds images to Jev too, so compare the two on your own images.
• You want one vendor for both the decision steps and the writing steps.

Look at D1 Ultra, Elephant-1 and the others when:

• Neither of the first two is accurate enough on your own examples. The public rankings already disagree with each other, so treat them as a shortlist, not an answer.

Stay with a normal LLM when:

• You can't write down the possible answers in advance, or the output is something a person reads.

Whichever you choose, check the vendor's current documentation before you commit. Prices, limits and input types are changing month to month. Design your system so the decision model can be swapped: the questions you write and the thresholds you tune are the valuable part, and they carry over.

Where to start

Pick the one decision your team makes most often, the one someone answers fifty times a day. Write it down as a question with a fixed set of answers. Run a decision model on last month's real examples, compare its answers with what your team actually did, and set a threshold from what you see. If it holds up, let it handle the confident cases and leave the rest with your people.

If you'd like help finding that first decision, or building the workflow around it, talk to us.