Decision models: when your AI should return a probability, not a paragraph

A support ticket comes in: "I was charged twice this month, please refund one of them."

Most teams send that to a chat model with a prompt like "Classify this ticket. Reply in JSON with is_refund, team and urgency." The model reads the ticket, writes a few dozen tokens of JSON, you parse it, and sometimes you retry because a field came back as "Billing " with a trailing space.

It works. But look at what actually happened: you used a text generator to make three small decisions, paid for every output token, waited for them to stream, and got back a label with no idea how sure the model was.

Last week Liquid AI released two open-weight models built around a different idea. They're called decision models, and they're worth understanding even if you never use these specific ones, because they change how you should think about a big chunk of the LLM calls in a typical product.

What Liquid AI shipped

On October 7, 2026, Liquid AI published Open d1, two open-weight models in its d1 family:

• d1-3B (about 3.1B parameters), trained from their LFM2.5-VL-3B vision-language backbone. It takes text and images.
• d1-omni-600M (about 587M parameters), trained from a small bidirectional encoder with added vision and audio encoders. It takes text plus an image, or text plus up to 30 seconds of audio. Liquid calls it an early research release.

The important part is what they don't do. Neither model writes text. You give it an input (the "state") and a set of named questions, and in one forward pass it returns typed answers with probabilities:

• a yes/no answer with a probability,
• a choice among options you define, with a probability for each,
• or a score on a scale you describe.

MarkTechPost's write-up sums it up as "zero output tokens", which is the cleanest way to say it.

Why one forward pass matters

A chat model's latency is mostly output tokens: it generates one token, feeds it back in, generates the next. Even a short JSON answer is dozens of sequential steps. A decision model reads the input once and reads the answers off the final layer. That's it.

Here are Liquid's own numbers for d1-3B from the Hugging Face release post:

Hardware	One question	Three questions
NVIDIA RTX 4090	8 ms	21 ms
Jetson AGX Thor	16 ms	20 ms
Jetson AGX Orin 64 GB	26 ms	35 ms
Jetson Orin Nano	50 ms	73 ms

On quality, they report a mean of 82.9 across seven public text benchmarks (reading comprehension, toxicity, intent classification, medical QA and cross-lingual tasks), and 48.57 on their Decision Index v0.2.1 public split. Treat these as vendor numbers until independent evals show up; ModelSystem.One notes the official index snapshot it checked predates these model cards.

Even with that caveat, the shape of the result is the point: a 3B model answering in milliseconds on an edge board, with no output tokens to pay for or wait on.

What it looks like in code

The release post shows the usage pattern. You define questions as data, not as a prompt that asks for JSON:

from transformers import AutoModel

model = AutoModel.from_pretrained("LiquidAI/d1-3B", trust_remote_code=True)

questions = {
    "refund": {"type": "noul", "instructions": "Is the customer asking for a refund?"},
    "team": {"type": "choice", "instructions": "Which team should handle this?",
             "criteria": {"billing": "Charges, refunds, invoices",
                          "technical": "App or site faults",
                          "fraud": "Suspected unauthorised use"}},
    "urgency": {"type": "score", "instructions": "How urgent is this?",
                "criteria": ["Can wait", "Today", "Blocking the customer now"]},
}

print(model.system_one("I was charged twice this month, please refund one of them.", questions))

(Trimmed from the official example; see the post for device and dtype setup. It needs transformers>=5.14 and trust_remote_code=True, so review the model code before you run it in production.)

Notice what's gone: no "respond only in JSON", no parsing, no retry loop for malformed output. The output space is fixed by the question, so the model can't invent a fourth team.

The real win: probabilities you can act on

A chat model says "team": "billing". A decision model says, roughly, "billing 0.91, fraud 0.07, technical 0.02". That number is the useful part, because it lets you build a confidence router:

def route(ticket, decide, escalate):
    result = decide(ticket)              # fast decision model, milliseconds
    label, p = result.top()
    if p >= 0.90:
        return label                     # act automatically
    if p >= 0.60:
        return f"{label} (needs review)" # queue for a human or a bigger model
    return escalate(ticket)              # hard case: send to a full LLM

(decide, result.top() and escalate are placeholders for your own wrappers, not the d1 API.)

This is the pattern I'd actually take away. Most production AI systems have a handful of these small, high-volume decisions: is this toxic, which intent is this, does this retrieved chunk answer the question, should this agent step continue, is this image defective. Run them on a small fast model, act on the confident ones, and spend your big-model budget only on the uncertain tail.

One honest warning: "calibrated" means the probabilities are supposed to match reality (things it calls 0.9 should be right about 90% of the time). Don't take that on faith. Check it on your own labeled data before you set thresholds, the same way you'd check any classifier.

Where this fits, and where it doesn't

Good fits:

• Moderation and safety filters on every message
• Intent and ticket routing
• RAG relevance checks ("does this chunk answer the question?") before you stuff the context
• Guardrails inside agent loops ("is this tool call safe to run?")
• On-device or edge checks where there's no network budget: visual inspection, robots, kiosks

Bad fits:

• Anything where the answer is open-ended text: summaries, drafts, explanations
• Decisions where the options aren't known ahead of time
• Long multi-step reasoning, where a bigger model's thinking actually helps

Practical caveats:

• The open models use the LFM Open License v1.0, which MarkTechPost reports is free for commercial use below $10M annual revenue. Read the license yourself before you ship.
• d1-omni-600M is explicitly an early research release, with no published latency figures.
• The benchmarks are self-reported, and audio decision benchmarks are, in Liquid's words, an open problem.

The bigger idea

The industry spent two years routing every AI problem through a chat interface because that's what the frontier models were. But a lot of what we call "LLM features" are really classifiers wearing a chat costume. When the output is a decision, a model that only makes decisions is faster, cheaper, easier to validate, and it tells you how sure it is.

You don't need to switch to d1 tomorrow. But it's worth an hour this week to list every LLM call in your product whose output is really a label, a yes/no or a score. That list is where your latency and cost savings are hiding.

References

• Liquid AI: Open d1, edge decision models for text, vision, and audio (Oct 7, 2026)
• Hugging Face blog: Multimodal open d1 decision models for the edge
• Liquid AI: Introducing d1, the hosted decision model with vision (Oct 5, 2026)
• MarkTechPost: Liquid AI releases open-weight d1-3B and d1-omni-600M
• ModelSystem.One: Liquid AI ships open d1-3B and d1-omni-600M

How many of the LLM calls in your product are really just a label, a yes/no or a score?