Liquid AI d1-ultra vs Liquid AI d1-3B: A Rented Endpoint at $0.042 a Million, or a 2.87 GB Checkpoint You Own

Liquid AI d1-ultra is billed at $0.042 per million input tokens and runs on someone else's accelerator in someone else's data centre. Liquid AI d1-3B is billed at nothing per call and runs on a Jetson Orin Nano on a desk. Those two sentences describe models Liquid AI shipped eight days apart — d1-3B as an open-weight checkpoint announced on October 7, 2026, d1-ultra as an API-only model on October 15 — and they describe the identical job: hand the model a state made of text, images, or both, hand it a set of typed questions, and get calibrated answers back from a single forward pass without a single output token generated. Neither writes prose. Neither streams. The difference between them is not "which one is smarter" in the abstract, because the honest answer depends entirely on how many times a day you ask. For a model whose failure modes are still undocumented, the useful counterpart is the record of what has already gone wrong elsewhere: the documented AI incidents and agent failures around models in this class are collected in the OrcaRouter AI Incident Archive where each entry carries its own sources, severity, confidence grade and disputed flag.

That framing is the reason this comparison is worth more than a spec sheet. d1-3B and d1-ultra sit at opposite ends of a decision Liquid AI has now made explicit in its own documentation: you can rent the most capable model in the family by the token, or you can own a 3.12-billion-parameter one and pay in silicon, electricity and engineering hours instead. Both are current products. d1-ultra is the newest thing the company has shipped, and d1-3B is what most readers should probably start with. Which one is right for a given pipeline is an arithmetic question with a real crossover point, and it is answerable with published numbers — which is what follows.

One sourcing note before the numbers, because it matters more than the formatting of it. Almost everything below is Liquid AI's own reporting: the model cards, the October 7 open-weight post, and the October 15 d1-ultra post. We did not independently reproduce any decision-model benchmark for this article, and as far as we can tell nobody else has either. Where a figure is our arithmetic on a published number rather than anyone's measurement, it says so in the sentence that carries it.

What each model actually is, as of mid-October 2026

Liquid AI d1-3B is an open-weight, 3.12-billion-parameter decision model trained from LFM2.5-VL-3B, a decoder-only vision-language model. It carries a SigLIP2 NaFlex 400M vision encoder, a 32,768-token context window and a 128,000-token vocabulary, takes text, JSON, images or a mixture as its state, and answers one or more questions — Choice, Score, or noul, the yes/no primitive that returns a probability between 0 and 1 — in one forward pass. The weights are on Hugging Face under the LFM Open License, which the vendor describes as free to use including commercially below $10 million in annual revenue. Day-one llama.cpp support is stated, with NVFP4 builds across Apple, AMD, Qualcomm and NVIDIA.

Liquid AI d1-ultra is the same shape of product pointed at a harder problem. It is API-only — there are no weights, no GGUF, no MLX or ONNX export, and the vendor's documentation index lists it in a row whose only downloadable artifact is the word "API". It was built, per the announcement, on "a larger open-weight model with a series of Liquid-specific heavy customizations," which is the entire architectural disclosure: no parameter count, no context window and no latency figure appear on the vendor's pages. Third-party gateway listings put the context window at 32,768 tokens and one listing has described it as roughly 8.3B total parameters with about 1.5B active per token, but those are catalogue entries, not vendor statements, and we treat them as unconfirmed. The model string is d1-ultra, on the same endpoint as d1: https://api.liquid.ai/decisions/v1/systemone.

The reason those paragraphs are so lopsided is not editorial. It is the whole comparison. d1-3B is documented to a level of detail that lets you size hardware before you download anything. d1-ultra is documented to the level of detail that lets you call it and nothing more.

The two index numbers do not sit on the same ruler

Every secondary write-up of this pair will put 65 next to 48.57 and let you draw the obvious conclusion. Read the labels first, because the two numbers were published under different instruments.

• d1-3B's figure — 48.57, on the public split of Decision Index v0.2.1, in the October 7 release post. The vendor additionally states the model is ahead of everything under 10B and level with Decider 35B-A3B, a model twelve times its size.

• d1-ultra's figure — 65, described in the October 15 post as leading the Artificial Analysis Decision Index by at least eight points, with the claim that d1-ultra beats Jev 1.14 across all tasks. Press coverage of the announcement has reported Jev 1.14 at 57, which is consistent with an eight-point lead.

Two things are true and worth saying plainly. First, the index behind d1-ultra's 65 is a third party's, but the figure reached us through Liquid AI's own announcement and through press write-ups of it — we could not load a public table showing 65 ourselves — so it is vendor-reported in this article. Second, a version-0.2.1 public-split score and an unversioned index score are not guaranteed to be on one scale, and the v0.3 index has a private vision split that the open release explicitly did not report against. Treat the gap as directional — the paid model is meaningfully better — not as a 16.4-point measurement. Nobody, including us, has put these two models through a common harness.

Latency: one number is published, the other is not

The open model's speed is unusually well documented, which makes the omission on the paid model more conspicuous. d1-3B's card reports a single question in 8 ms on an RTX 4090, 9 ms on an AMD MI325X, 16 ms on a Jetson AGX Thor, 26 ms on a Jetson AGX Orin 64 GB, 30 ms on an Apple M5 Pro and 50 ms on a Jetson Orin Nano, with packed throughput reaching 1,106 decisions per second on the MI325X.

Those are forward-pass timings on named hardware, not end-to-end request timings, and the distinction is not pedantic. The last time Liquid AI published a hosted latency for a decision model — the October 5 post introducing d1 — it was 200 to 300 ms for a text decision, which is an API round trip including queueing and network, and it is not comparable to an 8 ms pass on a local card. For d1-ultra the vendor has published no latency figure at all, in either form. If your pipeline is latency-bound rather than accuracy-bound, that absence is the single most important thing on this page: you cannot currently tell whether the expensive model is fast, and the only way to find out is to measure it yourself.

The arithmetic the marketing pages do not do

Here is where the two products genuinely diverge, and it is a calculation you can do on a napkin. Take a support-triage gate that asks one noul question per ticket, 200,000 tickets a month, with roughly 1,200 input tokens per question including a small screenshot. That is 240 million input tokens a month, which is the quantity that makes the per-million rate legible.

• On d1-ultra at $0.042 per million input tokens, that is about $10.08 a month. On d1-3B at zero per call, it is $0.00 a month plus whatever the hardware costs.

• A 2.87 GB Q8_0 build fits comfortably on a Jetson Orin Nano. If you are buying that box specifically for this workload, the payback period against the hosted endpoint is measured in years, not weeks — which is the honest conclusion, and not the one a hardware vendor would print.

• Flip the volume. At 200 million questions a month — 240 billion input tokens — d1-ultra's bill is roughly $10,080 a month, and the local build is still eating the same electricity. That is where owning the checkpoint stops being a philosophical preference and becomes a line item.

Three caveats, all of which cut in the same direction. Every token count above is the one we chose; your state length and image count will differ, and images are charged as text at 1.5 tokens per 32×32-pixel patch, so a single 1024×1024 image is 1,536 input tokens. Every question is billed as its own prompt including its text and all its images, so asking three questions of the same screenshot pays for that screenshot three times. And none of this prices the engineering: the local route buys you a quantisation choice, a runtime to keep current, and a vision encoder that eats memory before the 3.12B of weights do. If you are calling a model a few thousand times a month, the hosted endpoint is cheaper than the meeting where you decide to self-host.

Where each one stops being the right answer

Liquid AI d1-3B is the right default when any of these is the binding constraint: data cannot leave the premises or the device; the network hop is unacceptable; the volume is high enough that per-call pricing becomes the dominant cost; or the state is a live camera frame or a screenshot that you would rather not ship to a third party. The vendor's own framing supports the first of those — the open release is explicitly aimed at edge and on-device deployment across NVIDIA DGX, RTX and Jetson hardware — and the 17,820 downloads the checkpoint recorded in its first month suggest a lot of people reached the same conclusion quickly.

Liquid AI d1-ultra is the right answer when the decision itself is the hard part. Knowledge-heavy questions, visual claims that need to be matched against real-world context — the vendor's own examples are circuit-board defects and matching a damage claim to a customer photo — and long-tail cases where a 3B model's confidence is simply not worth trusting. The specific claim Liquid AI makes for it is not just accuracy but calibration: most decision models are overconfident, the post argues, and d1-ultra was trained so its probabilities mean something. If you are thresholding on a probability rather than taking the argmax — routing anything above 0.8 to auto-resolve and everything else to a human — calibration is the whole ballgame, and it is also the claim in this release that is hardest for an outsider to check.

The cases where neither is right are worth naming too. If your answer is free-form text, a multi-step trace, or a summary, a decision model is the wrong tool and the vendor says so in its own documentation. If you need audio in the state rather than just text and images, the third member of the family, d1-omni-600M, is the one that takes it — using d1-ultra for that job is not an upgrade, it is a category error.

Fitting this into a stack you already run

A decision model is almost never the whole pipeline. It is the gate: the thing that decides whether a ticket is urgent, whether a photo is a defect, whether a tool call gets approved. Something still has to write the reply, and on the local route that something is a second model you now have to host — which is the real cost of going self-hosted, and the one that never appears in the per-token comparison. The pattern that actually works at small and medium volume is a local d1-3B for the high-frequency gate and a rented endpoint for the rare hard case, with an OrcaRouter key carrying the generative models those decisions fan out to: one API over 200+ models, provider list price passed through with 0% markup, and automatic failover across providers so a single upstream bad afternoon does not turn your triage queue into a backlog. It is worth being precise about what that does and does not cover — we do not host any Liquid AI model, so the decision call itself goes to Liquid AI's API or to the local checkpoint, and OrcaRouter is what sits behind it.

Once you stop treating the decision model as fixed, the comparison stops being binary. The routing DSL lets you compose a cheap gate and an expensive writer into one call, and fusion lets a panel of models answer together when a single one is not trustworthy enough. Neither of those is a reason to pick d1-ultra over d1-3B. Both are reasons the choice is worth revisiting at the volume where the arithmetic actually moves.

What would change this answer

Three things, in order of likelihood. An independent benchmark that puts d1-3B and d1-ultra through the same harness on the same tasks — at which point the 48.57-versus-65 gap becomes a measurement instead of a directional guess. A published latency for d1-ultra, without which any latency-sensitive pipeline should treat the hosted model as an unknown and measure it in a canary path first. And an eventual open-weight release built on the larger backbone, which the family's history makes less far-fetched than it sounds: every other d1 model that started hosted ended up downloadable within two days.

Until then the rule of thumb holds. Start with d1-3B because it is free to try, fast on hardware you may already own, and documented well enough to size properly before you commit. Move the specific decisions that come back unconvincing to d1-ultra. The gap between the two is real; it is just narrower than the price difference suggests, and much narrower than the index numbers imply when they are printed side by side without their version labels.