Liquid AI Releases d1 Decision Model

Liquid AI just released d1. It's their newest decision model. And it does something unusual in a field obsessed with longer and longer text: it refuses to write any, which is a strange stance for a system surrounded by competitors that keep pushing output length as the main measure of progress. The company built a system that answers structured questions with calibrated probabilities instead of prose. It's available right now. You can get it through the Liquid API under the name d1:free.

The pitch is narrow on purpose. You hand the model a block of context and a set of typed questions. It hands back a probability distribution across outcomes you defined before the call. No paragraphs. No explanations. In every response, usage.output_tokens is zero.

What Liquid AI Actually Shipped

Liquid AI describes d1 as a decision model rather than a language model. That distinction matters more than it sounds. A general LLM asked to label a support ticket will generate the label as text, which means you pay for output tokens, you wait for a decoding loop, and you occasionally get malformed JSON that forces a retry.

The d1 decision model sidesteps all of that. It evaluates a situation and returns a typed answer drawn from options you supply. The company's own migration guide offers a blunt rule: if the answer is one of N known options, use a decision model. If the model has to compose a new string, keep your LLM.

Liquid's model library lists d1 as API only. It's not trainable. There are no GGUF, MLX or ONNX weights for teams that want to self-host, and if you're a team that wants to run this thing on your own hardware, you simply don't have that option anywhere in the library. So you can't self-host it. If you want it, you go through the hosted endpoint.

Three Primitives Do All the Work

Everything d1 does runs through three question types. Liquid calls them Noul, Choice and Score.

• Noul asks a yes/no question and returns a probability between 0 and 1. In Liquid's own example, the question "Is this message a complaint?" came back at 0.999.
• Choice picks one option from a named set, returning the top pick, the full distribution and a confidence value. A double-charge ticket scored 0.9997 on billing.
• Score rates input against an ordered rubric and returns a probability-weighted position. Levels are indexed from zero, so a four-level urgency rubric spans 0 to 3. A production outage scored 2.9995.

You can mix all three in a single request. The model evaluates every question against the same state in one round trip.

How the API Call Looks

Each request carries three parts: the model, the state, and the questions. The state can be plain text or a JSON object. Calls go to POST https://api.liquid.ai/decisions/v1/systemone, and keys are issued from console.liquid.ai with a liquid_ prefix.

The Python and TypeScript clients come from TypeSafe AI, published as typesafe-sdk and @typesafe-ai/sdk. A minimal Python call sets up a TypeSafeClient with your API key and base URL, then passes the model name, a state string, and a dictionary of questions.

print(result.answers["is_complaint"].noul) # 0.999

That single line is the whole output. No text, no formatting, no parsing.

Why Teams Are Moving Classification Off LLMs

The case for switching is concrete. An LLM bills output tokens even when the answer is a one-word label.

A d1 decision model bills none. Latency becomes predictable because there is no decoding loop that stretches with output length. Schema errors disappear because answers always match the question type, which kills the malformed JSON and retry cycle that plagues structured output work.

Then there is uncertainty. A general LLM asked for a confidence number is essentially making one up. The d1 decision model returns calibrated probabilities, which makes thresholds genuinely useful.

Liquid's moderation example blocks anything above 0.8, allows anything below 0.2, and routes the middle band to human review. Its routing example drops to the most capable model tier when router confidence falls below 0.5. The company also says repeated evaluations of the same input are more consistent, which reduces verdict flips. Fewer round trips is the last piece: three sequential classification calls collapse into one.

The Road Decider Demo

Liquid's road-decider cookbook shows the idea in motion. It is a pixel-art survival racer where d1 uses a Choice question to pick left, center or right on every decision tick, roughly two to five times per second depending on game speed.

The app is vanilla JavaScript on Node.js 18 or higher, with a Vite proxy keeping the API key server-side. A "Jev vs d1" mode races d1 against TypeSafe's typesafe/jev-1.13 through OpenRouter.

But the demo's real lesson is about state design, and it cuts against the obvious approach. Per-lane summaries with distance to the first obstacle produced more confident decisions than a raw grid of the road. Feeding the model more data made it worse.

Where d1 Fits and Where It Does Not

d1 enters a small but fast-moving category of non-generative decision models. The company positions it for routing, moderation, triage, reranking and LLM-as-judge replacement. Those are bounded tasks. They've got known answer sets. And that's exactly the territory d1 was built for, because when you're dealing with tasks that have a defined set of possible answers, you don't need a model that generates anything new, you just need one that picks the right answer from what's already there.

Summarization, drafting, multi-turn chat, code generation and complex multi-step reasoning stay with conventional LLMs. That is not a limitation Liquid seems interested in hiding.

For teams currently paying for output tokens on classification work, the trade is straightforward. You give up flexibility and self-hosting. You get typed answers, no billed output, and probabilities you can actually put a threshold on. The d1 decision model is live today, and the first call costs nothing to try.

Frequently Asked Questions

What is the d1 decision model and how does it differ from a general LLM in terms of output?

The d1 decision model is Liquid AI's newest decision model that answers structured questions with calibrated probabilities instead of prose. Unlike a general LLM that generates text and bills output tokens, d1 returns a typed answer drawn from options you supply, and in every response usage.output_tokens is zero.

What are the three question types that d1 uses, and what does each return?

The three question types are Noul, Choice and Score. Noul asks a yes/no question and returns a probability between 0 and 1, Choice picks one option from a named set and returns the top pick, full distribution and confidence value, and Score rates input against an ordered rubric and returns a probability-weighted position.

How does the d1 API call work, including the endpoint, key prefix, and client libraries?

Each request carries three parts: the model, the state, and the questions, with the state being plain text or a JSON object. Calls go to POST https://api.liquid.ai/decisions/v1/systemone, keys are issued from console.liquid.ai with a liquid_ prefix, and the Python and TypeScript clients come from TypeSafe AI as typesafe-sdk and @typesafe-ai/sdk.

Why do teams move classification off LLMs when using the d1 decision model?

The case for switching is concrete: an LLM bills output tokens even for a one-word label, while a d1 decision model bills none, and latency becomes predictable because there is no decoding loop. Schema errors disappear because answers always match the question type, and d1 returns calibrated probabilities that make thresholds genuinely useful.

What does the road-decider demo reveal about state design for d1, and which tasks stay with conventional LLMs?

The road-decider demo shows that per-lane summaries with distance to the first obstacle produced more confident decisions than a raw grid of the road, and feeding the model more data made it worse. Summarization, drafting, multi-turn chat, code generation and complex multi-step reasoning stay with conventional LLMs.