Decision models: what fits in one pass?

Sometimes an AI application needs a very short answer. Which queue should receive this ticket? Is this passage relevant? Has the agent finished, or should it keep working?

We routinely ask a language model to answer these questions by generating text, then write code to turn that text back into a decision. Even a perfectly formatted JSON response takes tokens to produce. A reasoning model may spend considerably more tokens working out what to put in it.

This autumn’s crop of decision models offers a more direct interface: supply the situation, describe the options, get scores back. Microsoft-Decision-1, TypeSafe’s Jev, Liquid AI’s d1 family, and OpenAI’s Decisions API all sit in this space, with different architectures and deployment options.

The attraction is easy to understand. These decisions happen constantly, often inside loops where latency and cost matter. A model that can make them in one pass has a useful job waiting for it.

After playing with them, I think the interesting question is how much of our particular decision can fit into that pass.

A familiar job, with a more flexible interface

Scoring a fixed set of labels is an old machine-learning task. A BERT classifier could already read a text and produce scores for “billing”, “technical support” and “sales” without writing an answer one token at a time.

What makes the new offerings interesting is the combination of pretrained capabilities and a task you can describe at inference time. You can supply the categories, the grading rubric, or the conditions for an agent to continue. That saves some of the dataset collection and task-specific training a conventional classifier would require. Whether it saves enough training depends on the task.

The shared interface covers different internals. Microsoft’s model builds on Qwen3.5-9B; Liquid’s open releases include both a 3B model and a 600M multimodal model. Both vendors describe single-pass scoring. OpenAI documents a hosted API without specifying its architecture. Microsoft announcement, Liquid release notes.

That interface is a real improvement for application developers. It also makes it easy to confuse two things: a response that is easy for code to consume, and a decision that is easy for the model to make.

Two ways to get a better answer

For this discussion, I find it useful to separate two sources of capability.

What the model has already learned. Training puts facts, patterns and procedures into the weights. A model that has seen enough support tickets may recognise a billing issue immediately. A model trained on a particular grading task may have learned to apply that rubric very well.

Model size gives this learning more room, but parameter count is a poor substitute for knowing what was learned. The often-quoted “two bits of knowledge per parameter” comes from controlled experiments on factual knowledge storage. It is an interesting capacity result, not a universal conversion rate between parameters and intelligence.

What the model can work out at inference time. A model generating intermediate steps gets additional opportunities to transform the problem: compute a subtotal, compare it with a rule, notice a conflict, try again. Those steps cost time and tokens, and they can be wrong. They also let the model spend more computation on a difficult case.

A one-pass model still computes through many layers. It can combine evidence, apply rules, and use information supplied in the prompt. “No chain of thought” does not mean “no reasoning”. The constraint is that it has no optional sequence of generated working steps to extend the calculation before answering. Research on the computational role of chain of thought helps formalise why those extra steps can matter.

This is a large part of the appeal of System 1 models: the model does the work within a bounded inference procedure. It is also the constraint to test when deciding what work to give them.

A small test with Jev

I gave Jev a sum and three possible answers: 0, ½, 1.

The correct answer is 0. Jev assigned roughly 1% to ½, 47% to 0 and 52% to 1. Changing the wording and the order of the options did not materially change the pattern in my tests.

The low score for ½ is consistent with recognising a simple constraint: adding and subtracting integers produces an integer. Between the two integer options, however, the result was close to a coin flip, with the wrong answer narrowly ahead.

There is another shortcut available. Eight of the terms are odd, so the sum must be even; of the three proposed answers, only 0 fits. Jev’s scores did not reliably reflect that constraint either.

We cannot read the model’s computation from these probabilities. This is a small probe, not a benchmark, and it does not prove that a one-pass model cannot calculate or check parity. Addition can be grouped in parallel; a person working from left to right is only one way to do it.

What the example does show is more practical: a model can strongly reject an implausible option while still failing to distinguish the right answer from a plausible wrong one. An application that always selects the highest score would return 1.

For arithmetic, I would use a calculator. The reason to look at the example is that the same distinction matters in less easily checked decisions: recognising the kind of problem in front of you is useful, but it does not guarantee that you have resolved it.

A 9B model is substantial. Does it know your problem?

A model can know a great deal about customer support and still know nothing about your escalation policy. It has not seen last week’s contract amendment, the exception agreed with a particular customer, or the incident already affecting this account.

The usual fix is to put those facts in the input. That works here too. Decision models can be prompted; they do not need every rule baked into their weights.

But supplying information and applying it are different jobs.

“Route invoices to billing” is a shallow rule. “Route invoices to billing unless this is a duplicate charge on an enterprise account, except when the refund has already been approved by the account owner” requires more relationships to be resolved. If that approval was later withdrawn in the conversation history, the model must also work out which state is current.

Some of these decisions will still fit comfortably in one pass. Others will depend on enough interacting conditions that additional computation helps. A longer context window gives the model access to more evidence; it does not establish that it can use that evidence reliably.

This changes how I would evaluate the models. A generic classification benchmark tells me something about their starting capabilities. I also want examples with our rules, our exceptions, and the amount of history our application actually sends.

Fine-tuning can move more of that work into the weights. An upstream process can also simplify the state: resolve the current approval status, retrieve the applicable policy, compute the account balance. Then the decision model receives a problem it has a better chance of handling. Of course, the cost of preparing that input belongs in the overall bill.

What did the 28% confidence mean?

Jev also reported 28% confidence on the arithmetic question. At first glance, this makes a satisfying story: it got the answer wrong, but knew it was unsure.

The TypeSafe documentation gives a more precise explanation. For a Choice question, confidence rescales the highest option probability relative to a uniform distribution. With three choices and a top score of 52%, the calculation is:

confidence = (0.52 − 1/3) / (1 − 1/3) = 0.28

The 28% is derived from the option scores. It is not a separate estimate of whether the selected answer is correct. For a fixed number of choices, thresholding it is equivalent to thresholding the highest probability.

It is still useful. The application has a signal on which it can decline to act. In this example, a suitable threshold would have sent the question elsewhere instead of returning the wrong answer.

But having probabilities is not the same as having calibrated probabilities. Calibration means that, across many comparable cases, predictions assigned 80% probability are correct about 80% of the time. It is something to measure on labelled examples, including the data your application sees. A convincing result on one question cannot establish it. Guo et al., “On Calibration of Modern Neural Networks”.

The reverse matters too: a model can be confidently wrong. An escalation policy catches uncertainty expressed in the scores; it cannot catch every mistake the model fails to signal. Even a very concentrated distribution says nothing by itself about whether the right option was included in the first place.

Where I would use them

The strongest candidates are frequent, bounded decisions with a clear evaluation target: classify a ticket, score a retrieved passage, apply a familiar rubric, choose which workflow should receive a request. Tasks that the model knows well, or that we can teach it well, are particularly attractive.

I would start with one such decision and a labelled sample of real inputs. Then I would measure two things together: how much work the model can accept, and how often it is wrong on the work it accepts. Raising a confidence threshold usually reduces coverage; the useful question is whether the remaining decisions are reliable enough to automate.

Cases below the threshold can go to a reasoning model, a deterministic tool, or a person. The destination depends on what is missing. A calculator solves the arithmetic example. A missing approval may require more evidence. An ambiguous policy may need its owner.

The economics also need that full path. An escalated case pays for both the decision call and the fallback, in cost and latency. The cheap first pass earns its place when it handles enough cases correctly to make the combined system worthwhile. This is the same system-level question we explored in the article on model routing.

That is how I would use these models as a System 1: a fast first judgement for familiar decisions, with a deliberate way to hand over the cases it should not settle. The name is a useful analogy, rather than a claim that the model reproduces human cognition.

A decision model can remove a great many expensive calls from an application. I would judge it by how much work it takes off the rest of the system, and by the mistakes that remain after the handover policy is in place.

Sources and further reading

• Microsoft-Decision-1 announcement: backbone, supported tasks and inference interface.
• TypeSafe documentation and confidence calculation: Jev’s decision interface and the distinction between option probability and confidence.
• Liquid AI, open d1 releases: model sizes, architectures and scored decision tasks.
• OpenAI Decisions guide: typed predicates, choices and rubric scores; public beta at the time of writing.
• Jacob Devlin et al., “BERT: Pre-training of Deep Bidirectional Transformers for Language Understanding”, 2018.
• Zeyuan Allen-Zhu and Yuanzhi Li, “Physics of Language Models: Part 3.3, Knowledge Capacity Scaling Laws”, 2024.
• William Merrill and Ashish Sabharwal, “The Expressive Power of Transformers with Chain of Thought”, 2024 conference version.
• Chuan Guo et al., “On Calibration of Modern Neural Networks”, 2017.

Product documentation checked 21 October 2026. The Jev scores are reproduced from my test notes; they are not a fresh evaluation of the current service.