Liquid AI d1-omni-600M Is Now an Ollama Pull: A 600M Decision Model That Can Hear You

Liquid AI d1-omni-600M became an Ollama package at 22:32 UTC on 17 October 2026. That timestamp is not a guess: Ollama's registry serves an ollama-push-time header on every manifest, and the four tags behind the name d1-omni were accepted between 22:31:25 and 22:32:13 that evening, roughly four hours before this was written. The model itself is not new — Liquid AI open-weighted Liquid AI d1-omni-600M alongside Liquid AI d1-3B on 5 October 2026 and announced both in its "Open d1" post on 7 October — but until last night the only ways to run the audio-capable one on your own hardware were a transformers environment with trust_remote_code=True or a llama.cpp build you compiled yourself. Now it is ollama pull d1-omni. Nobody announced that: not Liquid AI's blog, not Ollama's.

The packaging is the story, and it is worth being precise about which parts of it are documented. Liquid AI's most recent blog posts are d1-ultra on 15 October and LFM2.5-24B-A2B on 13 October, and neither mentions Ollama; the lab's own Ollama deployment page still teaches you to run its GGUF repositories straight from Hugging Face with ollama run hf.co/LiquidAI/... and never names a d1 model. Ollama's blog is equally silent — its latest entries are Reflection's Beam on 16 October and a Fly.io integration on 13 October. What exists instead is a registry entry, four tags, a verifiable digest, and a library page that was still being authored while this article was being written: an early capture of that page returned "No readme," and a capture forty minutes later returned a full Liquid AI-written description with a benchmark table and a licence section. If you want a dated, checkable event for the last seven days, that header is it.

What the registry actually accepted

Four tags resolve to two images, which is the first thing to understand before you pull. d1-omni:latest, d1-omni:600m and d1-omni:600m-q8_0 are the same manifest — digest 1ba59f63e836 — while d1-omni:600m-bf16 is a second one, digest c1e95fce6627. There is no F16 tag, though the vendor's own GGUF repository publishes an F16 trunk.

• Weight layers (Q8_0 build) — a 407 MB trunk from d1-omni-600M-Q8_0.gguf plus a 442 MB projector from mmproj-d1-omni-600M-BF16.gguf, with a 10.5 KB licence blob and an 18-byte parameters blob, totalling 849,659,968 bytes.

• Reported size — 850 MB for the default tag and 1.2 GB for 600m-bf16, both as printed on the library page.

• Runtime floor — requires: 0.40.4 in the config blob, which also reports model_family: lfm2, model_type: 380.73M and file type Q8_0.

• Context — the parameters blob pins num_ctx to 16,384.

• Licence — the embedded text is the LFM Open License v1.0, naming Liquid AI, Inc. as licensor, matching the lfm1.0 identifier on the model card.

That projector deserves a second look, because it is bigger than the model it is attached to. Reading the GGUF metadata directly out of the registry blob shows clip.has_vision_encoder = True and clip.has_audio_encoder = True in the same file: 197 vision tensors across 12 blocks at 768-wide embeddings and 256-pixel inputs, and 641 audio tensors across 17 blocks at 512-wide embeddings with 128 mel bins. That is the SigLIP2 tower and the FastConformer encoder both travelling in the multimodal bundle, which is why a 381M-parameter trunk ships behind a 442 MB attachment. The audio capability is physically in the package you download; the question of whether the endpoint can reach it comes later.

The model is 587M parameters and the 125K badge is bigger than the truth

Ollama's page advertises "125K context window" on every tag. The package's own num_ctx is 16,384, and Liquid AI's model card says the same thing in words: 16,384 tokens spanning text, image and audio positions together, with the state and question text cut to 896 tokens whenever images are present. The 125K figure is traceable — the trunk GGUF carries lfm2.context_length = 128000 — but it is the architecture's ceiling, not the window you get, and it is the number most likely to mislead someone sizing a replacement for a long-context classifier. Treat 16,384 as the working figure and 896 tokens of text as the working figure when an image is in the state.

The rest of the metadata corroborates the model card rather than the marketing line. The trunk is 18 blocks, 1,024-wide embeddings and a 65,536 vocabulary, and it is not a decoder: lfm2.attention.causal is False. Its per-layer KV head counts read 0, 0, 8, 0, 0, 8, …, meaning most of those blocks are not attention blocks at all, which is the bidirectional encoder ancestry showing through. The decision head is two blocks (lfm2.decision.block_count = 2), and the calibration constants the vendor keeps in config.json are in this GGUF too — choice questions carry a temperature of 1.7465 at two options, 1.3999 at three to five, 1.1751 at six to ten and 1.3725 above eleven; yes/no is 1.6663; scored questions are 1.7301 at three to five levels and 1.0 at six to ten. That is the whole design in one place: a fixed set of named answers, scored in one pass, calibrated per question shape, with output_tokens: 0 at the end.

It is not a chat model and does not write text. Liquid AI lists fifteen languages, puts the audio training data in English only — requests between a speaker and an assistant — and caps clips at 30 seconds. The card also warns against bfloat16 on GPUs: on the vendor's own checks it changed the top answer on 0.8% of text rows and 1.7% of audio rows, where float16 matched float32 everywhere.

Audio is in the weights and absent from the documented API

This is the discrepancy worth knowing before you file a bug. The library page's readme, which Liquid AI wrote, documents audio by putting a base64 WAV inside the images array of a /v1/systemone request. The vendor's Hugging Face GGUF readme for the same checkpoint documents it differently, with a files array carrying data:audio/wav;base64,… into the llama.cpp server. And the endpoint reference that Ollama publishes documents neither: its request schema has state, images, questions and keep_alive, describes images as "Requires a model with vision, such as Clef," and contains no audio field and no files field at all. Ollama's own decision-model guide, meanwhile, names Nimble, Tev1, Clef and Clef Flash as the decision models and says only that the Clef models can also judge images.

So the honest position on audio in Ollama today is: the encoder is verified present in the blob, the vendor's readme says it works through images, and the published schema does not admit it. Image input on the same model is on firmer ground — vision is a documented System One capability and d1-omni appears in Ollama's vision category listing. Two smaller documentation gaps sit alongside that one: the endpoint reference allows up to 255 option keys in a choice question while the decision guide says 2 to 26, and the package's runtime floor of 0.40.4 is higher than the 0.35.0 the endpoint documentation quotes.

Filed under vision, not under decision

Ollama's model search filters decision models into their own category. It contains nine entries — nimble-v3, pplx-decider, kev, tev1, nimble, clef-flash, clef, laya and strands-decider — and neither d1 nor d1-omni is among them. The d1-omni page is tagged vision and 600m, and it does appear in the vision listing, so a reader browsing for "decision model" will not find the newest one. That is a discoverability problem rather than a capability one, but it matters if you were planning to compare the decision families in Ollama's own catalogue and concluded this one did not exist.

What it also means is that d1-omni is the first decision model in Ollama's library that can take speech at all — the audio encoder is in the package and nothing else in that nine-model list carries one. Whether the endpoint will hand it your WAV is the open question from the section above, and it is the single thing most likely to have changed by the time you read this.

The numbers, and who produced every one of them

Every accuracy figure attached to Liquid AI d1-omni-600M is Liquid AI's, and there is no independent evaluation of any d1 model in existence as far as we can find — no leaderboard row, no third-party run, no published rejection of the vendor's scoring. The vendor scored both d1 checkpoints itself with the official Decision Index scorer rather than submitting them to the public leaderboard, and says so on the card; every competing row in its table comes from leaderboard v0.2.1, which means the comparison is a self-scored number sitting next to externally-scored ones.

• Decision Index 0.2.1 — 15.95 for d1-omni-600M (knowledge 8.3, language 12.9, retrieval 35.0, tools 15.1, arts 6.8) against 48.57 for d1-3B.

• Benchmarks as decisions, mean of seven — 78.4 for d1-omni-600M against 82.9 for d1-3B, with the 600M model ahead on Civil Comments (95.8 vs 93.0) and PAWS-X (79.5 vs 76.9) and behind on BoolQ (77.7 vs 86.7) and SQuAD 2.0 (74.0 vs 85.3).

• Fast Decisions, dev split — 76.9, vendor-reported, no comparison row published.

• Speed — nothing. The card states plainly that inference numbers are not reported because this is an early research release under active development, so any latency claim you see for it elsewhere is somebody's own measurement.

• Fixture numbers on the Ollama page — the readme's worked example shows urgent answered at 0.998 and technical at 0.995. Those are illustrative outputs of one request, published by the runtime, and they are not a benchmark.

The gap between 15.95 and 48.57 is the most useful thing on the card, because it settles the buying question in the vendor's own words: the readme tells you to use d1 when accuracy over text and images is what matters and to reach for d1-omni when size matters or you need audio. A 587M model that scores 78.4 across seven public benchmarks recast as decisions is a plausible edge classifier. It is not a smaller version of the 3B.

Where OrcaRouter fits, and where it does not

We do not serve this model. A check of our catalogue on 18 October returned 208 model ids and not one of them is from Liquid AI, so nothing here is an availability claim and there is no route on our side to pull it from. If you want Liquid AI d1-omni-600M, the local path is the one described above, and the hosted path is the vendor's own API and whatever third-party platforms pick it up.

What the packaging changes is the shape of the system around it, and that is where we are useful. A decision model is almost never the whole pipeline: the ticket it labels, the frame it flags and the transcript it routes still have to be answered, summarised or escalated by something that writes text. Those generative calls sit behind one OpenAI-compatible key for 200+ hosted models at the provider's list price, passed through with 0% markup, so a vendor price change reaches you the same day rather than on a new contract. And because d1-omni-600M ships with no independent accuracy evidence and no published latency, the right way to put it in front of real traffic is behind automatic failover across providers — let it handle the calls it is confident about, and keep a route out when it is not, instead of making 587M parameters a single point of failure for your triage step. The decision stays local; the fallback does not have to be.

What would change this read

Four things, any one of which would turn a packaging note into a different article. Ollama documenting audio in the System One request schema, which would convert the readme's WAV-in-images trick into a supported input and make this the first speech-capable decision model you can run with one command. Either company acknowledging the port — Liquid AI adding d1-omni to the Ollama page of its deployment docs, or Ollama listing it under decision models instead of vision. A speed figure from anyone, vendor or not, since none exists today. And an independent Decision Index row for any d1 model, which remains the single missing piece across the whole family.

Until then the decision is straightforward. If you already run Ollama at 0.40.4 or later, the pull is one command, the download is 850 MB, and what you get is a 587M classifier that answers typed questions in a single forward pass over text and images — and, if the readme is right, over 30 seconds of English speech. If your state is long, keep the 16,384-token window and the 896-token text budget in mind rather than the 125K badge. And if you need evidence that it is accurate before it labels anything a customer sees, that evidence does not exist yet, for this model or any of its siblings.

The documented AI failures and agent incidents behind releases like this one are collected in the OrcaRouter AI Incident Archive, where each entry carries its own sources, severity, confidence grade and disputed flag.