Liquid AI d1-3B Lands on Ollama: A Quiet Local Endpoint for a Decision Model

There is a new d1 in Ollama's library, and it is not a chat model. The entry describes it in one line — "a 3B decision model from Liquid AI, built on LFM2.5-VL-3B" — and that single sentence contains the two facts that matter most. Liquid AI d1-3B, the small model Liquid AI built on top of Liquid AI LFM2.5-VL-3B and released as open weights on 5 October 2026, is now packaged so that one pull puts it on your own machine; and it still returns calibrated probabilities over typed questions rather than generated text, exactly as the underlying checkpoint does. If you have a triage, routing, moderation or gating step in a pipeline, this is the first time that specific model family is one command away from running with no API key, no per-call price and no state text leaving your hardware.

The word "quiet" is doing real work here, though, and it is worth being precise about which half of this story is documented and which half is not. Liquid AI's own blog has never mentioned Ollama: the lab's most recent post, on 13 October 2026, covers a different model in the LFM2.5 line, and its two d1 posts — 5 October's vision announcement and 7 October's "Open d1" release — describe weights, an API and a benchmark score, not a local runtime. Ollama's library page for d1 carries no announcement either, and neither does the vendor's documentation index, which ticks GGUF as available for Liquid AI d1-3B and its audio-capable sibling Liquid AI d1-omni-600M while naming llama.cpp, Ollama and MLX only as generic deployment options. What exists is a published package, a registry entry with a digest you can verify, a working readme, and a download counter that read 10.4K when this was written on 15 October 2026. What does not exist is a vendor sentence saying "we did this."

What the listing actually contains

Three tags are listed — d1:latest, d1:3b and d1:3b-q8_0 — and all three resolve to the same manifest digest, 8c2d9ddae441. That is the first thing to understand about the page: the library's "3 models" counter is a count of tags, not of checkpoints. One artifact, three names, 3.7 GB, a 32K context window, and text and image input. If you were hoping to pick a size or a quantisation, there is nothing to pick yet.

The registry behind the page is more informative than the page. The package's config blob reports a model family of lfm2, a model type of 2.7B, a file type of Q8_0, and a minimum runtime of Ollama 0.40.4. It ships in two weight layers: a 2.87 GB generative model and a separate 856 MB projector. That second layer is the vision encoder, and its presence tells you the local build keeps the multimodal path rather than stripping d1 down to text — the model can still read a photograph alongside a support ticket and answer questions about both. The two numbers on this page that appear to disagree — "3B" in the description and "2.7B" in the registry — are best read as the trunk and the whole: Liquid AI's model card puts the checkpoint at 3.12B parameters including a 400M-parameter vision encoder, and the language trunk is the smaller figure. That arithmetic is ours, not the vendor's, and it is offered as an explanation rather than a spec.

There is no calendar date anywhere on the library page. It reports relative stamps — "Updated 2 hours ago" at the moment of capture — and a download counter, which means the day this listing first appeared is not knowable from the listing itself. The dated anchors are all on Hugging Face and at the vendor: the weights repository for Liquid AI d1-3B was created on 5 October 2026, a companion GGUF repository on 6 October, and Liquid AI published its release post on 7 October. If you need to put a date on "when did this become runnable locally," the honest answer today is that the package exists and is being pulled now, and nobody outside Ollama can say on which morning it went up.

Why a packaging event is a real event

Ollama opened a decision-model category on 29 September 2026, when it shipped the /v1/systemone endpoint and a --ask CLI flag for models that answer typed questions in a single forward pass. Nimble and Clef were the first families through that door. What the new d1 package adds is a different thing from a new benchmark row: it takes a model that until now lived either in a Python environment with a vendored model class or behind a hosted endpoint, and it makes local inference a command.

The contract is worth restating because it is not what most readers mean by "run a model." You hand d1 a state — a string, a JSON object, an array, or a string plus images — and a set of named questions, and you get answers back with no generated tokens at all. noul is a yes/no question answered as a single probability between 0 and 1. choice returns the selected label, a confidence, and a full probability map over your options. score places the state on an ordered rubric of two to ten levels and returns the probability-weighted level plus each level's probability. One state, up to 64 questions, one pass over the input. Ollama's own example response for a support ticket returns usage.output_tokens: 0, which is the cleanest possible statement of the design.

For anyone whose pipeline already calls a decision model over HTTP, the local route changes three things at once: latency, because the request stops leaving the machine; cost, because there is no per-call meter; and data handling, because the ticket text and the photograph you are classifying never cross the network. If your state is a customer's message or an internal document, that last one is usually the only argument that needs to be made.

Running it, and the limits the docs put around it

There are three supported ways in, and they are all documented on the library page. The CLI path is ollama run d1 --ask "Is a refund being requested?" with the state piped in from a file, and --choice and --level flags for the other two question types. The HTTP path is a POST to http://localhost:11434/v1/systemone with a model, a state, an optional images array and a questions object. The SDK path points TypeSafe's Python client at localhost, where the API key is ignored and any placeholder value works.

The limits come from Ollama's endpoint documentation rather than from Liquid AI, and they are tighter than a generative model's: requests must fit within 64 KiB without images and 32 MiB with them, streaming is not supported, cloud-hosted models are rejected outright, and images must be base64 PNG, JPEG or WebP sent in the request body — remote URLs are refused. Images are shared by every question in a request, so a picture you only want the first answer to consider has to be sent as its own call. Input is never truncated, which means an oversized state is an error rather than a silently clipped prompt.

Two documentation details are worth flagging as unresolved. Ollama's endpoint reference describes the choice type as accepting 2 to 255 option keys, while the capability page for decision models says 2 to 26 — one of the two is stale, and it is not obvious which. And the capability page names its supported models as Nimble, Tev1, Clef and Clef Flash, with no mention of d1, even though the d1 package's own readme states that it works through /v1/systemone and --ask. The package requires Ollama 0.40.4; the documented floor for the endpoint itself is 0.35.0. None of that is a contradiction that stops you pulling the model, but read the version requirement on the package rather than the one in the capability guide.

The numbers, and who produced every one of them

Now the part that deserves the most caution. Every performance figure attached to this model is Liquid AI's, and there is no independent evaluation of Liquid AI d1-3B in existence as far as we can find. The vendor's reported results, repeated on the Ollama page and on the model card, are these:

• Decision Index 0.2.1 — 48.57 for d1-3B, against 47.11 for Decider 35B-A3B, which Liquid describes as the best score for a decision model under 10B parameters. • Vision — a mean of 74.1 across eleven public image benchmarks, against 73.9 for the LFM2.5-VL-3B base it was built from. • Latency — 8 ms per decision on an RTX 4090, 9 ms on an AMD MI325X, and 30 ms on an Apple M5 Pro. • Throughput — 475 decisions per second on the 4090 and 1,106 on the MI325X when questions are packed into batches. • Ablation — the same question set answered without images scores 45.1, which is Liquid's own measure of how much the vision path contributes.

The vision row is the one that should temper expectations. A 0.2-point improvement over the base model on a set of image benchmarks is inside the noise of most benchmark reporting; whatever the decision head buys you, it is not a materially better image encoder. The ablation row is more interesting in the other direction — a roughly 29-point swing when images are added — but it compares two different question sets, not two versions of the same one. And the Decision Index is a third-party instrument on which Liquid scored its own entries rather than submitting them for public ranking, so treat 48.57 as a vendor claim made on someone else's ruler. The speed figures are also unaudited: 8 ms on a 4090 is a plausible number for a 3B model doing one forward pass, and it is still the case that nobody has published a run they do not own.

Where OrcaRouter fits, and where it does not

OrcaRouter does not serve Liquid AI d1-3B. We checked our catalogue before writing this — 207 models, none of them Liquid AI, none of them a decision model — so if you want to call d1 from an API rather than from your own hardware, the hosted route today is the vendor's own decision endpoint at api.liquid.ai/decisions/v1/systemone, where a paid d1 tier handles images and a free d1:free tier is text-only, plus whatever third-party platforms pick it up. Nothing in this piece should be read as a claim that we host it.

What we do is adjacent to the problem this model solves. The reason a decision model exists is that pipelines need a cheap, deterministic way to choose among options, and d1's own documented example is a ticket routed to a destination team — which is a routing problem one level down from ours. When that decision gates a call to a generative model you rent rather than run, OrcaRouter is one OpenAI-compatible key for 200+ hosted models at the provider's list price, passed through with 0% markup, so a vendor price cut reaches you the day it lands rather than at the next contract renewal. And because the local half of this pipeline is the half you own, the risk sits in the hosted half: automatic failover across providers keeps a triaged request alive when the model you routed it to goes down. Neither of those is a reason to use a 3B decision model. They are reasons the thing on the other side of the decision should not be a single point of failure.

What would turn this from a packaging note into a story

Five things, any one of which would change the read. Liquid AI acknowledging the port, or its documentation index adding Ollama to the deployment row it currently fills with llama.cpp and MLX. A second quantisation: Liquid's own GGUF repository ships Q4_K_M, F16 and BF16 alongside Q8_0, so a smaller local build is technically available, just not through this package. A local path for Liquid AI d1-omni-600M, the 587M-parameter sibling that reads up to thirty seconds of audio and which the vendor labels an early research release — that one would matter more than the 3B for on-device work, and there is no sign of it in any library yet. An independent Decision Index row, or a public leaderboard entry, which is the single missing piece across this entire model family. And Ollama adding d1 to its decision-capability page, which is a one-line change that would tell you the port is blessed rather than incidental.

Until then the decision is simple enough to make on your own terms. If you already run a recent Ollama, the pull is one command, the download is 3.7 GB, and the thing it replaces is either a hosted call you would rather not make with a customer's text or a Python environment that is more work to maintain than the model is worth. If you need independent evidence of accuracy before this sits in front of real users, that evidence does not exist yet for any d1 model, and no amount of local packaging creates it.

Running the decision step on your own hardware is also a good time to look at what has already gone wrong in this class: the documented AI incidents and agent failures involving decision models are collected in the OrcaRouter AI Incident Archive, where each entry carries its own sources, severity, confidence grade and disputed flag.