# Clef-omni and Microsoft-Decision-1: open weights that hear video, and a closed model timed on a different clock
> Satyajit Ghana — Head of Engineering @ Inkers Technology
> canonical: https://ai.thesatyajit.com/articles/clef-omni-and-microsoft-decision-1
> date: 2026-10-10
> tags: benchmarks, multimodal, mixture-of-experts, audio, calibration, qwen
Two decision models came out on 9 October, a few hours apart. Julien Chaumond [posted](https://x.com/julien_c/status/2108650927288918084) "new clef drop from cloudflare!" with a link to [Cloudflare/clef-omni](https://huggingface.co/Cloudflare/clef-omni), and Satya Nadella [introduced](https://x.com/satyanadella/status/2108627923888754862) Microsoft-Decision-1, which "delivers top performance on structured decision tasks, outperforming both LLMs and other decision models in latency and quality."
I wanted to read them side by side because they are opposite bets. Cloudflare put Apache-2.0 weights on the Hub for a model that takes text, images, audio and video. Microsoft put a text-only model behind an API and called it the fastest and most accurate in the category. One of them I can open. The other I can only check against what it was compared to.
Both turned out to be more interesting than the announcements. Clef-omni's weights say exactly which part of a 35-billion-parameter checkpoint Cloudflare trained, and it is a smaller part than "omni" suggests. Microsoft's latency chart is honest about its sources in a footnote, and the footnote is the story: the open models it beats were timed with a penalty added on purpose.
If the vocabulary is new, [the llama.cpp piece](/articles/llamacpp-decision-models) walks a decision request from JSON to probabilities, and [Unsloth's trainer](/articles/unsloth-train-a-decision-model) is where this site read Clef's joint schema head line by line. I lean on both.
## What is in the clef-omni repository
The card says Clef-omni "is post-trained from Qwen/Qwen3-Omni-30B-A3B-Instruct" and keeps "the Qwen/Qwen3-Omni-30B-A3B-Instruct thinker with its vision and audio encoders". Qwen3-Omni is two models in one checkpoint: a *thinker* that reads everything and writes text, and a *talker* plus a `code2wav` vocoder that turn the thinker's output into speech. A decision model never writes anything, so the talker is dead weight. The card says it is "included unchanged but are not used".
I read all fifteen shard headers and the head's by HTTP range request and summed the tensors by name prefix. All 28,132 tensors are bfloat16.
| Part | Parameters |
|---|---:|
| Text decoder experts (48 layers x 128 experts) | 28,991,029,248 |
| Text decoder attention, routers, norms | 918,763,520 |
| Audio encoder | 647,927,168 |
| Vision encoder | 538,631,408 |
| Token embeddings | 311,427,072 |
| LM head (kept; its rows are read, never projected onto) | 311,427,072 |
| Joint schema head (`joint_head.safetensors`) | 109,175,812 |
| Talker and `code2wav`, unused | 3,540,613,057 |
| **Total in the files** | **35,368,994,357** |
So the download is 70.7 GB in bfloat16, and 7.1 GB of it is a speech generator the loader skips: `load_release_model` sets `enable_audio_output = False` and only complains about unexpected keys that do not start with `talker.` or `code2wav.`. What actually runs is the thinker plus the head, 31,828,381,300 parameters, which is the 31.83B the Decision Index lists. The thinker alone is 63.4 GB, and the card's "about 64 GB of GPU memory in bfloat16" is that number.
The "A3B" holds up. Each text layer routes a token to 8 of its 128 experts (`num_experts_per_tok: 8` in `config.json`), each expert three 2,048 by 768 matrices. Eight experts across 48 layers is 1.81B parameters, plus 0.92B of attention and routing, so about 2.7B weights touch each text token. That is why an MLX conversion runs on a laptop at all: [mlx-community/clef-omni-4bit](https://huggingface.co/mlx-community/clef-omni-4bit) is 19.8 GB with the talker dropped (its header total is 31,719,205,488, the thinker to the parameter) and its card claims 0.19 s for a 1k-token request on an M5 Max.
The head is the one Clef uses. Its class definition in `joint_schema_model.py` is byte-identical to the one in `Cloudflare/clef`, and its size follows from the formula this site checked against Clef and clef-flash: width 1,024, two routing layers, four decoder layers, 16 heads, and an input projection sized to the backbone's hidden width. Clef's 5,120-wide backbone gives 128,056,324 parameters; Qwen3-Omni's thinker is 2,048 wide, which removes 18,880,512 from the input projections and norms and leaves exactly 109,175,812.
## What the training touched
Cloudflare's [blog post](https://blog.cloudflare.com/clef-faster-cheaper-multimodal) describes the recipe in one sentence: "freezing the Qwen3 backbone, training low-rank adapters (LoRA), and applying our standard post-training approach: combining label-smoothed cross-entropy loss with Brier score calibration." The release ships no adapter, so the LoRA must have been merged. I wanted to know where.
Qwen's base checkpoint has the same 28,010 tensor names, so I read the first 64 KB of a sample of tensors from both repositories and compared them value by value.
| Tensor | Identical values | Relative change |
|---|---:|---:|
| layer 0 attention `q_proj` | 1.1% | 16.2% |
| layer 0 attention `k_proj` | 1.6% | 11.0% |
| layer 24 attention `q_proj` | 2.6% | 5.9% |
| layer 47 attention `v_proj`, `o_proj` | 2.6%, 4.5% | 6.6%, 4.3% |
| experts 0, 5, 64, 127 in layers 0, 10, 33, 47 | 5.3% to 8.9% | 2.0% to 3.4% |
| expert router `mlp.gate` (layer 20) | 100% | 0 |
| layer norms, `q_norm`, final norm | 100% | 0 |
| token embeddings, LM head | 100% | 0 |
| audio encoder, layer 0 | 100% | 0 |
| vision encoder, block 0 | 100% | 0 |
| talker, layer 0 | 100% | 0 |
The pattern is clean. Every attention projection and every expert I sampled moved, by a few percent, which is what a merged LoRA on all linear layers of the text decoder looks like. The routers did not move, so tokens go to the same experts Qwen chose. And the audio and vision towers are bit-identical to Qwen's.
That last fact changes how to read "omni". Cloudflare did not teach this model to hear. Qwen3-Omni already could, and its audio encoder turns a clip into embeddings exactly as it did before. What Cloudflare trained is the text decoder's habit of carrying evidence from those embeddings to the positions where the head reads options, plus the head itself. That is a sensible division of labour, and it means the model's audio understanding is bounded by Qwen's, for better and worse. Nothing in the repository says what the training data was, or whether any of it had audio or video in it. I could not check that.
## One prompt, every modality
The mechanism is Clef's, with a media prefix bolted on. `encode_record` builds a single chat-formatted prompt: a fixed system message ("Decide every field jointly"), then `STATE:`, then the media placeholders, then the state as text, then every question and every option written out under `SCHEMA FIELDS:`, and finally an assistant turn holding an empty `` block and `JOINT SCHEMA DECISIONS:`. Nothing is generated after that colon.
```python
# Cloudflare/clef-omni, joint_schema_model.py:262-268 (abridged)
prefix_ids = _tokens(tokenizer,
f"<|im_start|>system\n{SYSTEM_PROMPT}<|im_end|>\n<|im_start|>user\nSTATE:\n")
suffix_ids = _tokens(tokenizer,
"\n<|im_end|>\n<|im_start|>assistant\n\n\n\n\nJOINT SCHEMA DECISIONS:")
media_ids, media = _encode_media(processor, record)
prefix_ids = prefix_ids + media_ids
```
Images, audio and video become Qwen's placeholder tokens, which the processor expands into one position per patch or audio frame. Video is decoded at 2 frames per second (`VIDEO_FPS = 2.0`), with each frame capped at 262,144 pixels. The one genuinely omni detail is in `_encode_media`: if every video in a request has a soundtrack, the soundtracks are appended to the audio list and `use_audio_in_video` is set, so Qwen's thinker interleaves the sound with the frames on a shared time axis. A dashcam clip is heard and seen as one stream, not as a picture and a separate recording. Liquid's d1-omni, by contrast, raises a `ValueError` if you pass an image and audio together.
Then the thinker runs once, with its LM head swapped for an identity so the "logits" it returns are hidden states (`ClefModel.__init__`). The joint schema head reads them: each question becomes the mean hidden state over its instruction span, each option the mean over its own span plus the mean of the LM head's rows for its tokens, two routing layers let every option attend over the whole sequence (media positions included), and four decoder layers let the questions inform one another. The [Unsloth piece](/articles/unsloth-train-a-decision-model#what-a-clef-head-is) walks that forward pass slowly; nothing in it changes here.
One small thing I did not expect. The score for each option is `prior + sigmoid(residual_gate) * joint`, with two learned scales inside. The code initialises all three scalars to zero. In the released head they are `prior_logit_scale = 2.296875`, `joint_logit_scale = 2.296875` and `residual_gate = -2.0`, and I read the same three values, to the bit, out of Clef and clef-flash too. Three separately trained heads do not land on identical bfloat16 values; these look like settings fixed during training, about ln 10 for the scales and a gate near 0.12. If so, the cosine prior between an option's embedding rows and the question carries roughly eight times the weight of the learned matching term. I am reading that off the weights; the training code is not published.
Two practical limits sit in the same file. The default `max_length` is 64,000 tokens and the schema is never cut, only the state, so a long option list eats the room media needs. And `ClefModel.forward` scores one record at a time ("so padding never changes a record's probabilities"), which matters for the latency numbers below.
## Cloudflare's tables, and the board that is not Cloudflare's
The card has two tables. The first is 41 benchmarks from Cloudflare's "internal run of the Decision Index 0.2.1 suite", with Clef-omni beside Clef, clef-flash and Jev. Counting the bold cells, Clef-omni is best on 8 rows, Clef on 9, clef-flash on 14 and Jev on 12. Against its own dense sibling Clef, Clef-omni is ahead on 17 rows and behind on 24. The worst drop is RAGTruth, hallucination F1 of 42.0 against Clef's 79.4. It is ahead where the task is intent classification (BANKING77 94.8, CLINC150 97.7) and behind on most of what needs careful reading. The blog prints a ten-row subset of the same table, which leaves RAGTruth out.
The second table is five rows from four TypeSafe workflow evals, and Clef-omni is below Clef on all five and below or tied with Jev on all five. Those are the same four workflows the [typed-decisions](https://huggingface.co/datasets/LocalLLaMA/typed-decisions) benchmark is built from, but scored as "exact actions" and "primary action" against TypeSafe's reference labels, so the numbers do not sit on typed-decisions' leaderboard. Neither model is on that leaderboard yet. So by Cloudflare's own numbers, the multimodal model is a step down from Clef on text. That is not a criticism. A 3B-active mixture of experts against a 27B dense model, on text, should lose; what you buy is the other inputs.
The independent check is the [Decision Index Space](https://huggingface.co/spaces/multimodalart/jev-decision-index), the community board the [Open d1 piece](/articles/liquid-open-d1) and the [pplx-decider piece](/articles/pplx-decider-v1-1) relied on. It has already run Clef-omni. Its notes say it ran "the model card's joint_schema_model path (load_release_model, encode_record, one record per forward), bf16", with "No Decision Index submission" from Cloudflare.
On edition 0.3.1, as of the board's 10 October data, Clef-omni scores 49.32 and ranks 27th of 117. Clef is 19th at 53.08 and clef-flash 33rd at 47.61. Jev is at 60.11 and Perplexity's decider leads at 62.75.
The more telling number is the split. Version 0.3's full score is 20% public benchmarks, 50% private tests of the same skills and 30% private tasks from new domains. On the public part alone, Clef-omni scores 56.54, so it loses 7.22 points when the private tests come in. Across the board, the median entrant loses 1.11. Clef loses 8.63 and clef-flash 8.54, and all three Cloudflare models are among the dozen biggest drops on the board. Clef's public score, 61.71, is the third best of all 117. Its full score is 19th. A model that does that well on public benchmarks and that much worse on unseen tests of the same skills was, at the least, tuned closer to the public sets than most. I cannot tell from outside whether that is contamination or just aggressive selection on public numbers, and the Space does not say either.
The board also has an image track, and there Clef-omni does better: 59.54 on the 0.3.1 vision board, sixth of 21, behind Perplexity's decider (70.58), JEV-27B-VL, Solomon, Xor and JPT-9B. Its calibration on the image rows is good (ECE 0.0422 over 13,695 answers). There is no audio or video track on the board at all, so Cloudflare's headline modality has no independent number yet. The closest thing is a reply under Julien's post, from Sebastian B., who turned BANKING77's test set into speech with six text-to-speech models and asked Clef-omni about the audio.
That is a useful sanity check and a narrow one. Text-to-speech of a one-line banking query is clean audio of exactly the words the text version had. It says the audio path works, and it says nothing about a noisy call or the 21-second dashcam clip the blog times at "about 1.5 seconds".
On speed, two numbers disagree and both are probably right. The blog says text-only decisions return "in about 130 ms at the median" on Workers AI. The board, on one RTX PRO 6000 with Cloudflare's reference code, measured a 191.3 ms median, slower than the board's run of the 27B dense Clef (102.1 ms). A 3B-active model should be faster than a 27B dense one, and it is in Cloudflare's own serving and in the MLX card's numbers. The reference path loads the mixture of experts through plain `transformers` and scores one record per forward, which is the slow way to run one. Cloudflare's README says "Use SGLang (coming soon!)" for Clef-omni; the blog says Clef's own SGLang support ships in SGLang 0.5.22. Until then, self-hosted Clef-omni is a 64 GB, roughly 200 ms model.
## Is it a rival to d1-omni-600M?
Liquid's d1-omni-600M is the other open decision model that hears audio, and [the Open d1 piece](/articles/liquid-open-d1#d1-omni-600m-grows-a-head) read it to the parameter. Put the two cards next to each other and they turn out to share a word and not much else.
| | Clef-omni | d1-omni-600M |
|---|---|---|
| Parameters in use | 31.83B (about 2.7B active per text token) | 587M, all dense |
| Trunk | Qwen3-Omni thinker, causal, merged LoRA | LFM2.5-Encoder-350M, bidirectional |
| Readout | joint schema head over spans, questions decided together | score per option marker, one sequence per question |
| Inputs | text plus any mix of images, audio, video with sound | text plus images *or* audio, never both, no video |
| Weights | bfloat16, 70.7 GB download | float32 |
| Decision Index 0.3.1, full / public | 49.32 / 56.54 | 9.45 / 17.9 |
| Board latency, median | 191.3 ms | 10.9 ms |
| Licence | Apache-2.0 | Liquid's custom licence |
At 54 times the parameters, Clef-omni scores five times higher and is 18 times slower on the board's GPU. Those are different products. d1-omni is for a device: FluidInference already runs its text path on a Mac's Neural Engine at 224 comments a second. Clef-omni is for a GPU server, or a 32 GB Mac at the bottom end, deciding about a call recording or a camera clip where the quality of the reading matters more than the milliseconds. If you are choosing between them, the question is where the model has to run, and that decides it before any benchmark does.
## Microsoft-Decision-1, from what Microsoft published
There are no weights to read. The [Foundry catalogue page](https://ai.azure.com/catalog/models/Microsoft-Decision-1) says so in its "Distribution channels" section: "Model weights are not distributed." Everything below comes from that page, the [launch post](https://commandline.microsoft.com/microsoft-decision-1-model-foundry/) and [OpenRouter's listing](https://openrouter.ai/microsoft/microsoft-decision-1).
The model is "built on Alibaba's open-weight Qwen3.5-9B and post-trained by Microsoft". The page calls Qwen3.5-9B "a dense, decoder-only Transformer"; it is dense in the sense of not being a mixture of experts, though 24 of its 32 layers are linear attention (its `config.json` lists 8 `full_attention` layers). The base is 9,653,104,368 parameters by the Hub's header count, and the Foundry page says only that the model "falls within the 5B-15B parameter range". It is text-only, takes up to 32,768 input tokens (the base supports 262,144), and was trained "September 2026 to October 2026" on public datasets and synthetic data, between 1 billion and 1 trillion tokens. That range spans three orders of magnitude, so it tells you nothing. OpenRouter's description adds a line that matters for anyone building on it: "Weights are updated continually while the API shape stays the same."
The price is \$0.042 per million input tokens, with output free. That is exactly the price the [typed-decisions](https://huggingface.co/datasets/LocalLLaMA/typed-decisions) card lists for Jev. Cloudflare cut clef-flash to \$0.038 on the same day, and launched Clef-omni at \$0.15.
The same base is worth dwelling on. Qwen3.5-9B is also the base of Cloudflare's clef-flash, which is open, Apache-2.0, and on the Decision Index at 47.61. The board lists five more entrants built on it, Bespoke Nimble 9B v3 (54.67) the best of them. Microsoft did not include any of them in its comparison.
## The 85 milliseconds
Satya's video and the post carry the same chart. Here is how it looked when the post went out, taken from the video.
The first reply under the post, with 298 likes, was "How is Jev not ranked? That's literally the #1 model people are going to compare this to." The post now carries an editor's note, "updated from the original to add benchmarks for Jev on accuracy and calibration", and the chart changed.
Two things happened in the edit. Microsoft-Decision-1 went from second to third on calibration. And the speed sentence changed its runner-up: "4.5x quicker than Quyet-1.0-Large, the runner-up" became "2.5x quicker than H2O-Lightning-4B v1.1, the runner-up", because Quyet was the runner-up on accuracy and is no longer once Jev is in.
Now the footnote: "Latency: JevBench v1.6.1 adjusted median (p50), checked Oct 7, 2026. * Microsoft-Decision-1 measured through Foundry in the same region." JevBench is Benchmark Heaven's board, separate from the Decision Index. Its v1.6.1 results file publishes, for every self-hosted model, a raw median and an adjusted one, with the rule written in the row: `"adjustment": "x2 + 0.15 s (assumption, not measured)"`. Its methodology says the same in a sentence: "The standard x2 + 0.15 s self-hosted adjustment is an assumption, not a hardware normalization." Hosted APIs such as Jev get `"none (API)"`.
The adjustment exists for a fair reason. A model timed on the benchmark's own GPU skips the network, queueing and load balancing that a hosted API pays, so JevBench doubles the self-hosted time and adds 150 ms to put both kinds on one axis. Apply the rule backwards to Microsoft's chart and every open model's bar comes apart:
- H2O-Lightning-4B v1.1: 210 ms plotted, 29.3 ms measured.
- Quyet-1.0-Large: 380 ms plotted, 115.8 ms measured.
- Surogate Rune 26B-A4B: 380 ms plotted, 116.2 ms measured.
- deck-31B: 400 ms plotted, 127.5 ms measured.
- Jev 1.13.0: 240 ms plotted, 239.1 ms measured, unadjusted, because it is an API.
Microsoft-Decision-1 is also a hosted API, and its 85 ms got neither treatment. It was not measured by JevBench's client as Jev was, and it was not given the self-hosted penalty. It was measured by Microsoft, from inside the same Azure region as the model. So the chart compares Microsoft's network-free number with open models that carry a 150 ms surcharge for a network they never touched, and with Jev measured across the internet.
There is one public number from outside Microsoft's region. OpenRouter, which forwards every request to Azure, shows a P50 of 0.26 s for Microsoft-Decision-1 over its first days. That includes OpenRouter's own hop, so it overstates the model's time. But it sits beside Jev's 239.1 ms measured by JevBench's client, not 2.8 times below it. By raw time, a 4B model on a single GPU answered in 29.3 ms. The fair reading is that Microsoft-Decision-1 is fast, about as fast as the other hosted decision APIs, and that the chart's "fastest measured" is a product of which clock each row was timed on. GPT-6 Sol's 3.01 s and Luna's 300 ms I could not trace to any published run.
The "35x faster than GPT-6 Sol" is the comparison Microsoft leads with in the use cases as well: 14 times faster than Sol at labelling Xbox feedback, 100 times faster than GPT5.6 Luna at Copilot's quality checks. Those are decision models against generative ones, and they will be true in the way that a lookup is faster than an essay. They do not distinguish Microsoft-Decision-1 from any other decision model.
## The accuracy column
"Microsoft-Decision-1 achieved the highest accuracy in our 36-benchmark comparison, spanning nearly 150,000 questions across benchmarks kept blind from training." The chart's footnote gives 147,137 questions. The benchmarks are not named, the harness is not published, and the Foundry page's description ("public and community decision benchmarks and on held-out internal test sets", "Results were checked with paired statistical tests") does not say which is which. I cannot check any of it.
What I can check is the comparison set. The appendix names six models: Quyet-1.0-Large, Surogate Rune 26B-A4B, GPT-6 Luna Decisions, deck-31B, H2O-Lightning-4B and Strands-Decider 2B, with each one's JevBench rank. The top of the independent Decision Index is not there. Perplexity's decider v1.1, first on the board at 62.75, is open-weight and missing. So is Torchcast Decision 27B, and so are all three Clef models, including clef-flash on the same base. Strands-Decider 2B, a 1.9B model that scores 21.75 on the Decision Index, is in, with its average taken over "the 23 of 36 benchmarks it could answer". The comparison is not wrong, but it is chosen, and the most informative row, the open post-train of the same 9B base, was not chosen.
Against Jev, which the edit added, the lead is 83.5 to 82.3. On an unpublished suite of 36 benchmarks with no confidence interval shown, 1.2 points is a tie until someone else runs it. Calibration has Jev ahead, 93.7 to 92.2. The robustness claim, that "Microsoft-Decision-1 changes its decision on 1.3% of perturbations on average", is the kind of number I would most like to see for every decision model, and like the rest it has no data behind it yet. The Decision Index has not listed it; that board is for open models, with Jev as its one hosted reference row.
## A hyperscaler joins
Here is what the evidence supports. The decision-model readout has stopped being anyone's moat: Microsoft's model is a post-train of an open 9B base, the same base under clef-flash, Nimble 9B v3 and four other entries on a board that now lists 117, and the only number Microsoft offers that an outsider could reproduce, latency, depends on how it was measured. What Microsoft adds is distribution and paperwork: a Foundry endpoint with Azure billing, an EU authorised representative named on the model page, OpenRouter on day one, 1.33B prompt tokens through OpenRouter in its first day or so, and a price set exactly at Jev's. The price floor moved the same day (clef-flash to \$0.038), so the competition the release creates is on price and procurement, not on a capability nobody else has. For buyers that is good news. For the small labs on the board, it means their open weights are now the benchmark a hyperscaler chooses whether to compare against.
## October 11: a faster Clef, a cheaper flash, and a 0.6B student
Two follow-ups landed after this was first written. One came from Cloudflare and one from FluidInference, and the second turned clef-flash into a model small enough to run on a laptop's Neural Engine.
### What made Clef "~2x faster"
Michelle Chen's [thread](https://x.com/michellechen/status/2108625984585170988) summed up Cloudflare's side in three bullets, and the third was "clef is now ~2x faster". I had already used the same [blog post](https://blog.cloudflare.com/clef-faster-cheaper-multimodal) for Clef-omni's training recipe and its 130 ms median, but not its section on Clef's hosted speed, which has a before-and-after table:
| Input | Before, median / p95 | Now, median / p95 | Median speedup |
|---|---:|---:|---:|
| ~800 tokens | 262 / 438 ms | 152 / 351 ms | 1.7x |
| ~3,400 tokens | 616 / 777 ms | 305 / 531 ms | 2.0x |
| ~16,000 tokens | 2,721 / 3,250 ms | 1,635 / 1,805 ms | 1.7x |
So "~2x" is the best of three rows, and the median speedup is 1.7x at both ends. The tail moved less where most requests sit. At about 800 tokens the p95 went from 438 to 351 ms, roughly 1.25x. No new weights were released: "most of the optimizations we made are at the serving infrastructure layer". The one change the blog names is the move to SGLang, through SGLang PR #42721, which ships in 0.5.22.
The [SGLang cookbook](https://docs.sglang.io/cookbook/autoregressive/Cloudflare/clef) shows what that path does, and it rules a few things out. Clef doesn't go through a scoring route like `/v1/score`. SGLang serves it on `/v1/systemone`, the Jev-compatible endpoint, and refuses chat and generation requests. When it finds `joint_head_config.json` it loads the head and switches to embedding mode, and in that mode it "disables radix caching, chunked prefill, and CUDA graphs". So the self-hosted recipe gets none of its speed from prefix caching or graph capture. Each request is one prefill on one GPU (TP=1), with every question in the same prompt so the state is read once. What a dedicated serving engine has over the reference path is the rest: batching requests from many callers onto one GPU and running real attention kernels, instead of a `transformers` forward pass per record. I can't see Cloudflare's production config, so I can't say how much of the 1.7x is SGLang and how much is other changes the blog doesn't list.
Two more details from the cookbook matter if you self-host. Prompts are capped at 16,384 tokens, the reference `encode_record` default, against 64k on the hosted Clef. And it covers Clef and clef-flash only, so Clef-omni still has no SGLang path. The cookbook also reruns GSM8K through `/v1/systemone` on H200, B200 and B300: Clef lands at 80.71, 80.59 and 80.59 against a reported 80.8, and clef-flash at 67.32, 67.36 and 67.36 against 67.3. As far as one benchmark can show, the serving path keeps the reference model's answers.
The price came with a trade. Clef-flash went from \$0.09 to \$0.038 per million input tokens, now about 10% under Jev's \$0.042, but its hosted context window went from 64k to 24k tokens. Cloudflare says "only 0.24% of requests exceed 24k input tokens" (the thread rounds it to 0.2%), and the weights on the Hub are unchanged and trained for 256k. That is reasonable, but it means "cheaper than Jev" comes with a shorter input limit. If your states are long, the blog itself points you to Clef at \$0.24.
### clef-text-0.6b: what the distillation is measured against
The next day Alex at FluidInference [posted](https://x.com/Alex_tra_memory/status/2108959518386458695): "We distilled clef-flash into a 0.6B model and supporting ANE option. 1,000 support tickets triaged on a M5 pro in 57 s: team, urgency and refund for each, 48 ms per ticket. Within a few points of the 9B on classification." The [Open d1 piece](/articles/liquid-open-d1#d1-omni-600m-grows-a-head) took FluidInference's last Core ML port apart and found a 95.4% headline sitting on a 90.1% do-nothing baseline, so I read this one the same way: card, weights and code.
The model is what the card says. Qwen3-0.6B (596,049,920 parameters in the PyTorch repo's safetensors header) carries Clef's joint schema head (102,882,308), 0.70B in all. The head checks out against the formula used earlier in this article. Clef-omni's head is 109,175,812 at a 2,048-wide backbone, and each unit of backbone width is worth 6,146 parameters in the head's input projections and norms, so a 1,024-wide backbone gives exactly 102,882,308. The card says the head "starts from clef-flash's head weights wherever the shapes match", which is everything except those input projections. Training used 24,208 records from the train splits of 12 public datasets, labelled by an 8-bit Core ML clef-flash, with a KL loss at temperature 2 plus 0.3 of gold-label cross-entropy, LoRA rank 64 on the backbone, the head trained in full, for 2 epochs on an M5 Pro. The training code isn't in FluidUse, so the recipe is the card's word.
"Within a few points" holds on average and breaks where tickets live. On the card's seven classification rows the student averages 84.1 and the teacher 84.5, by my arithmetic. BANKING77, 77 intents of real customer messages and the row most like ticket routing, is 86.4 against 94.5. That is eight points down, and the card's own summary, "within 0–4 points of the teacher on topic, entity, sentiment, rating, toxicity, emotion", leaves intent off its list. On the five reasoning and knowledge rows the student is 8 to 37 points down, and the card says so plainly: "not a knowledge model". Across all twelve rows it is 79.1 against 88.2.
The comparison also leans the student's way, which is the mirror image of the d1 problem. The student was trained on the train splits of the same twelve datasets whose test splits it is scored on, with 30% of its loss on their gold labels. The teacher answered them zero-shot. "Held-out" here means held-out examples, not held-out tasks. The giveaway is in the table. The student beats its own teacher on Emotion by ten points (68.0 against 58.0) and on TweetEval offensive by 2.7. A distilled model can only do that by learning the labels, not by copying the teacher. On a task it has never been trained on, which is every real ticket queue, nothing here says how close it stays.
The ticket run measures speed and nothing else. `MockTickets.swift` builds the 1,000 tickets from 25 templates, with plan, product, amount and time slotted in and an opener and closer added, all from a fixed seed. That gives 1,000 different strings but only 25 different requests, and none of them carries a label. I ported the generator and got the same final tickets that are on screen. Mapping each template to the team a person would pick gives Engineering 380, Billing 245, Product 222 and Account 147, plus six thank-you notes. The board shows 386, 208, 261 and 145. The gap is about the size of the 40 "discount for nonprofits" questions, which could reasonably go to Billing or Product. The model is roughly where a person would be, on a test too easy to separate a 0.6B model from a 9B one.
The speed is real, with two footnotes. The 57.2 s is the board's wall clock, so it works out to 57 ms a ticket, and the 48 ms is the median model time inside it. And the run uses the GPU. `TriageModel` loads the model with `.cpuAndGPU`, even though a comment a few lines above says "on the Neural Engine". The card puts the Neural Engine at about 77 ms a ticket, so the post's "supporting ANE option" is true, but the 57 seconds is not an ANE number. At those rates the Neural Engine run would take about 77 s (my arithmetic). The card's reason to use the Neural Engine is a good one: it leaves the GPU free. On the same tickets, the card puts the 9B clef-flash Core ML port at about 0.5 s, so the student is about ten times faster.
What I would claim for it, then. It is a 0.70B model with a real Clef head that routes short, clearly worded requests in tens of milliseconds on a Mac. On the public classification sets it was trained on, it stays close to the teacher, except on fine-grained intent. If you have a queue, label a few hundred of your own tickets and score it against clef-flash on those before you trust "within a few points".
## What I would use, and for what
For a decision about audio or video, Clef-omni is the only open model I know of that takes a clip with its soundtrack as one input. It needs a GPU with more than 64 GB free, or a 32 GB Mac through the MLX conversion, and it is slower than it should be until SGLang supports it. I would not use it for text-only work, where Cloudflare's own numbers put it below Clef and the Decision Index puts it below models a third its size. And I would treat its public-benchmark scores with the discount the board's private tests suggest.
For something on a device, d1-omni is the right tool and Clef-omni is not a substitute. For text-only routing on a Mac, clef-text-0.6b is now the other candidate, as long as you score it on your own labels first.
For Microsoft-Decision-1: if you are already on Azure, it is a Jev-priced endpoint inside your tenancy, and that is a real reason. Measure it on a labelled sample of your own traffic against Jev and clef-flash before you believe the chart, and pin the results by date, because the weights behind the name will change.
## How I checked
Clef-omni was read at commit `0db1cd2`. I fetched the card, `config.json`, `joint_head_config.json` and `joint_schema_model.py`, and read the headers of all fifteen model shards and `joint_head.safetensors` by HTTP range request, summing shapes by name prefix. For the training diff I read the headers of `Qwen/Qwen3-Omni-30B-A3B-Instruct` the same way and compared the first 32,768 values of 18 tensors in both repositories; the percentages are over those slices, not whole tensors. The three head scalars were read the same way from Clef-omni, Clef and clef-flash. I ran no model.
For the October 11 section I read Michelle Chen's thread (2108625984585170988) and Alex's post (2108959518386458695) with their replies through the fxtwitter mirror, the speed and pricing sections of Cloudflare's blog post, and the SGLang cookbook page for Clef. For clef-text-0.6b I read both FluidInference cards (`clef-text-0.6b` and `clef-text-0.6b-coreml`), counted parameters from the PyTorch repo's safetensors headers by range request, and read FluidUse at `9384e70`: `ClefFlashDemo` (`MockTickets.swift`, `TriageModel.swift`, its README), `ClefCompareDemo` and `ClefTextManager.swift`. The template tally comes from a Python port of `MockTickets.make` (SplitMix64, seed 7), checked against the last tickets on screen. The 57.2 s and the team counts are read off the last frame of the post's video. The classification averages are my arithmetic over the card's table. I ran neither model.
Board numbers are from the Decision Index Space's `data/v03.json`, `data/index.json` and `data/vision.json`, generated on 10 October 2026, and from JevBench's published v1.6.1 results JSON. Microsoft's chart data was read from the widget embedded in the launch post, and the original version from the frame of Satya Nadella's video. The Foundry and OpenRouter pages were rendered in a headless browser on 10 October; the Foundry "Benchmarks" and "Technical specs" sections are the source of the architecture and training statements. Both posts' threads and replies were read through the fxtwitter mirror.
What I could not check: Microsoft's 36 benchmarks, its harness and its robustness numbers; where GPT-6 Sol's and Luna's latencies came from; what data Clef-omni was trained on and whether it included audio or video; why the three Clef heads share the same three scalars; and Clef-omni on any independent audio or video test.