Decision Models: AI That Answers With Probabilities

Most AI in production does not write essays. It makes small decisions: is this ticket urgent, which team should get it, does this photo show a defect, is this answer grounded in the source? Decision models are built for exactly that job, and in autumn 2026 they became a product category of their own.

Why a model that does not generate?

Teams usually answer these questions with a chat LLM: write a prompt, ask for "yes" or "no", parse the reply. It works, but it has three costs that are easy to miss.

• No usable confidence. A generated "yes" carries no reliable measure of certainty. Asking the model to also print a confidence score produces a number, but that number is just more generated text and is often overconfident.
• Fragile parsing. The model may answer "Yes, this looks urgent because…", switch language, or invent a label you did not offer. Every caller needs defensive parsing and retries.
• Paying for words you throw away. Output tokens are slower and usually more expensive than input tokens, and reasoning models may spend hundreds of hidden tokens before writing a one-word answer.

A decision model removes all three. You give it the input and a set of typed questions; it returns a probability for each answer and nothing else.

What a decision model is

Under the hood, a decision model is still a neural network that reads tokens (and, for multimodal models, image patches). The difference is in the output. Instead of predicting the next token in a loop, it runs a single forward pass and reads the answer distribution straight from the network. A generative LLM also computes probabilities internally, as logits over its vocabulary, but then samples text from them. A decision model is trained to expose those probabilities for a fixed set of answers and to make them trustworthy.

TypeSafe AI markets its models as "System One" models, borrowing Daniel Kahneman's term for fast, intuitive thinking. The framing is useful: reasoning models are System Two, slow and deliberate; decision models are the fast reflex that software can branch on, millions of times a day.

The question types

Every request contains a state (the thing being judged: an email, a document, a product photo) and one or more named questions. Each question has a type, which fixes the shape of the answer. As of November 2026, the main providers support the following types.

The unusual name noul is the wire-format name for yes/no questions. Libraries smooth it over: the Vercel AI SDK's experimental evaluate API calls the same type boolean, and @typia/jev converts between the two.

Because the answer space is declared up front, the model can never return a label you did not offer. That property alone removes a whole class of production bugs.

What a request looks like

The interfaces of the two leading providers are close: a model name, a state, optional images, and a dictionary of questions with instructions. The example below calls Liquid AI's endpoint with two yes/no questions about a support email. Check the provider's API reference for the exact schema of choice and score questions, which add the list of labels or the scale.

import os
import requests

email = (
    "Hi, I was charged twice for my March invoice. "
    "Please refund one of the payments today."
)

resp = requests.post(
    "https://api.liquid.ai/decisions/v1/systemone",
    headers={"Authorization": f"Bearer {os.environ['LIQUID_API_KEY']}"},
    json={
        "model": "d1-ultra",
        "state": f"Customer support email:\n{email}",
        "questions": {
            "urgent": {"type": "noul",
                       "instructions": "Does this email need a reply within 24 hours?"},
            "billing": {"type": "noul",
                        "instructions": "Is this a billing or payment issue?"},
        },
    },
    timeout=10,
)
answers = resp.json()["answers"]
print(answers["urgent"]["noul"], answers["billing"]["noul"])
# two probabilities between 0 and 1

There is no prompt engineering around output format, no JSON repair and no retry loop for malformed answers. The application reads two numbers and decides what to do with them.

Calibration is the product

A probability is only useful if it means what it says. Calibration measures exactly that: among all the cases where a model reports 0.8, about 80% should turn out to be "yes". Generative models are notoriously overconfident when asked to state their certainty, and Liquid AI says it trained d1-ultra specifically for calibration because most decision models were also overconfident.

Good calibration turns a model into a dial you can set. Instead of a single yes/no cut-off, you pick thresholds based on how expensive each kind of mistake is, and send the uncertain middle to a person.

This is the same pattern as human-in-the-loop review in LLM automation, but with a cleaner signal. The share of cases that land in the middle band becomes a metric you can track and drive down.

The models as of November 2026

The category is young and moving fast. Two vendors define it today.

TypeSafe Jev

Jev is TypeSafe AI's structured decision model and the first of its System One models. Version 1.14 shipped in mid-October 2026 with multilingual improvements, a longer context, the new box question type and "composable images": images are attached as assets and referenced inside the state, instructions or criteria. Both image inputs and box questions are labelled beta and sit behind an explicit opt-in. TypeSafe also notes that every model, Jev included, does worse on multimodal input than on text, and recommends breaking questions into the simplest possible parts.

Jev is offered through TypeSafe's own SDK and through Cloudflare Workers AI, OpenRouter and Vercel AI Gateway. Listed pricing is $0.042 per million input tokens with no charge for output. The reported context window differs between providers, from 32K to 262K tokens, so check the one you use.

Liquid AI d1 and d1-ultra

Liquid AI released an open-weight d1 family in early October 2026: d1-3B and d1-omni-600M, published under the LFM Open License for on-device use, alongside a cheaper hosted d1. A week later it launched d1-ultra, its largest decision model, built on a larger open-weight base model with Liquid-specific modifications. d1-ultra reads text, images or both, has a 32,768-token context window and also costs $0.042 per million input tokens, with zero output cost. Images are billed as input tokens: 1.5 tokens per 32×32-pixel patch, so a 1024×1024 image counts as 1,536 tokens.

Where decision models fit

Anywhere software needs to branch on a judgement about unstructured input:

• Triage and routing. Urgency, intent, owning team or language for tickets, emails and chats.
• Moderation and policy checks. Does this post break a rule? Does this message contain personal data?
• Guardrails for LLM output. Is this answer supported by the retrieved passages? Does it follow the required tone? A cheap check after every generation in a RAG pipeline.
• Visual inspection. Defect or no defect on a production line photo; whether a document scan is legible enough for OCR.
• Agent control flow. "Smart if" statements inside workflows and harnesses: is the task done, does this tool call need approval, should the agent stop?
• Evals at scale. Grading thousands of outputs against simple criteria, where an LLM judge would be slow and expensive.

They are the wrong tool when the output must be open-ended (a draft reply, a summary), when you need to extract values rather than judge them, or when answering requires multi-step reasoning or information that is not in the state.

Decision model, LLM or classic classifier?

Decision models sit between two familiar options: prompting a general LLM, and training a dedicated classifier on labelled data.

A sensible migration path is to start with a decision model, collect its predictions and your reviewers' corrections, and only train a dedicated classifier if one narrow task becomes large enough to justify it.

Adopting one safely

1. Build a labelled sample. A few hundred real cases with known answers is enough to start. Include the awkward ones.
2. Measure accuracy and calibration. Group predictions into buckets (0.0–0.1, 0.1–0.2 and so on) and compare each bucket's average probability with the observed rate of "yes". Big gaps mean the thresholds need care.
3. Set thresholds from error costs. A false approval of a payment and a false escalation of a ticket do not cost the same.
4. Pin the model version. Aliases such as jev-latest move when a new release ships, and a new version can shift the probability distribution under your thresholds.
5. Keep questions simple. Several narrow questions beat one compound question. Remember that each question is billed as its own prompt, including any attached images, so five questions about one photo cost five times the image tokens.
6. Monitor in production. Track the share of cases in the uncertain band and sample decisions for review. A rising middle band is an early sign of drift.