The Interesting Number Isn't the Price. It's That There Isn't One.

This blog has spent a lot of the last two weeks on price per token: Luna's 80% cut, Fable 5 at $50 per million output, DeepSeek at $0.87. Every one of those arguments assumes a meter is running.

Liquid AI's LFM2.5-2.6B, released today, is a 2.6-billion-parameter agentic model that runs entirely on-device — 30 tokens/second on a phone, in under 2.5GB. There's no meter. And Liquid is explicit that this is the point rather than a side effect: "agents can now be massively parallelized on local hardware, running background tasks that burn through millions of tokens at no marginal cost."

Cheaper changes your invoice. Free changes your architecture. Nobody spins up a hundred speculative background agents that might each burn a million tokens when output costs $6 per million. At zero marginal cost, that's just a loop.

The efficiency numbers are a clean sweep

Liquid's CPU benchmarks (Q4_K_M quantization, 4K-token input) cover three devices, and LFM2.5-2.6B wins every cell — fastest prefill, fastest decode, lowest memory — against both Gemma-4 and Qwen3.5:

(decode tok/s per device; memory from the M5 Max run. Prefill follows the same ordering — 6,705 tok/s on M5 Max against Qwen3.5-9B's 2,401.)

The phone column is the one that matters, and it isn't really a speed comparison. At 7GB, Qwen3.5-9B doesn't run on a phone in any practical sense; at 8 tokens/second it wouldn't be usable if it did. LFM2.5-2.6B at 2.4GB and 30 tok/s is on the correct side of a threshold rather than further along a curve.

On GPU the same efficiency shows up as throughput: roughly 15,000 output tokens/second at high concurrency on a single H100, which Liquid puts at about 1.3 billion tokens per day from one card.

Why it's fast: the architecture, not just the parameter count

Liquid credits "the efficient LFM2 architecture" and moves on, but the mechanism is worth unpacking, because it explains the memory column better than "it's a smaller model" does.

LFM2 is a hybrid: mostly gated short convolution blocks, with only a minority of grouped-query attention (GQA) blocks — a roughly 1:3 ratio of attention to convolution in the smaller models of the family. The blocks are LIV — Linear Input-Varying — operators whose weights are generated on the fly from the input they act on, a framing that puts convolutions, recurrences and attention under one input-aware umbrella.

The part that matters for on-device deployment: a standard transformer runs softmax attention at every layer, and every layer keeps a KV cache that grows with sequence length. LFM2's convolution blocks don't attend over past tokens at all — each maintains a fixed-size state updated per token, with no KV cache. So most of the network's memory is constant in context length rather than linear in it.

That reframes the table above. 2.4GB against Qwen3.5-9B's 7.0GB at a 4K-token context isn't only a parameter-count difference — it's that a majority of layers carry no per-token cache at all. And the gap should widen with longer inputs, which is exactly the regime a 128K-context agentic model lives in: long tool outputs, accumulated traces, multi-step scratchpads.

The layout also wasn't hand-designed. Liquid reports using hardware-in-the-loop architecture search under explicit edge latency and memory constraints — which is why the advantage shows up as measured CPU throughput rather than only as a FLOP count.

(Architecture details come from Liquid's LFM2 write-ups and the LFM2 technical report; the specific block ratios are reported for earlier models in the family. I could not open the LFM2.5-2.6B model card to confirm this release's exact configuration — huggingface.co is blocked from this environment.)

How a 2.6B model got agentic: the training is the story

Small models are usually bad at agentic work because tool use, planning and multi-step recovery are exactly what gets lost when you shrink. Liquid's answer is a four-stage post-training pipeline, and the third stage is the novel one.

Two rounds of SFT — broad coverage, then targeted shaping on agentic tasks, reasoning and tool use. The mix is about seven times the size of the one used for their own LFM2.5-8B-A1B, weighted toward tool use, web search, software engineering and agent traces.

Teacher specialization. From that shared SFT checkpoint, they train one expert per domain — instruction following, math, knowledge and hallucination control, code, tool use, long context — each via focused SFT plus RLVR. Separate training means each expert optimizes deeply without competing gradient updates from unrelated objectives.

MOPD — Multi-Domain On-Policy Distillation. The specialists then teach a single student, but not by having the student imitate their trajectories. The student rolls out under its own policy, and each prompt is routed to the teacher for that domain, which supervises the student's own response with token-level feedback. The design detail that makes it work: because the teachers all branched from the same SFT checkpoint as the student, their feedback stays close to the student's distribution — close enough to guide without destabilizing training. That's a real answer to the classic distillation failure mode, where a student is dragged toward a teacher's distribution it can't actually represent.

Agentic RL inside real harnesses. The final stage runs multi-turn RL in Hermes Agent, OpenClaw and other production harnesses — not a simulator. Each rollout gets its own sandbox; optimization is GRPO against an outcome-based reward combining an LLM-as-judge rubric, programmatic checks, and a hard safety gate. Training inside real harnesses exposes the model to their actual tools, system prompts and interaction patterns.

The infrastructure note is worth flagging for anyone building similar systems: a Harness Proxy lets them treat third-party harnesses as black boxes with no modification, while still capturing the token-level trajectories RL needs — validated with linear trajectory consistency, token-mismatch checks, and Rollout Routing Replay.

The harness angle, again

Training inside OpenClaw and Hermes Agent, then shipping with instructions to serve behind an OpenAI-compatible endpoint and point any harness at it, is the same pattern this blog keeps running into from different directions: YC open-sourcing a harness-neutral agent platform, DeepSeek adopting OpenAI's Responses API, and now a model vendor optimizing against harnesses it doesn't own.

The interface has standardized to the point where a model can be trained against a competitor's ecosystem as a feature. That's what a commoditized layer looks like from the inside — and it cuts both ways for Liquid: easy adoption, but also easy replacement the day a better 2.6B appears.

"Open" is doing work again

The weights are on Hugging Face, base and post-trained, with day-one GGUF, MLX, vLLM, SGLang and ONNX support. But the licence is the LFM Open License v1.0, which is Apache-2.0-based and not OSI-compliant: commercial rights terminate for any entity with $10M or more in annual revenue, who must negotiate a separate paid agreement.

On the six-rung openness ladder that's a textbook rung 3 — free until you're big. Worth noting the threshold is half Kimi K3's $20M, and unlike K3's clause — which only bites Model-as-a-Service resellers — Liquid's applies to commercial use generally. For an independent developer or an early-stage startup it is functionally Apache-2.0. For a mid-sized company shipping this in a product, it is a licence negotiation.

That's a coherent business model for a company selling edge deployment, not a criticism. But it's another entry for the pile: the word "open" in a licence name continues to carry almost no information.

Where it loses

Liquid is direct about it, which is worth crediting: coding is the one area where the larger models keep an edge. LFM2.5-2.6B leads every instruction-following benchmark and nearly every tool-use benchmark (trailing only Qwen3.5-9B on BFCLv4), leads AA Omniscience, and outperforms both Gemma models on agentic tasks — but on code, the bigger models win, and Liquid says so in their own announcement.

That matters more than a normal benchmark gap, because coding agents are currently the highest-value agentic workload in the industry. The "free inference changes your architecture" argument is strongest exactly where this model is weakest. The realistic near-term shape isn't local-replaces-cloud; it's local-handles-volume — the background research, the document triage, the classification passes, the always-on monitoring — with escalation to a frontier model for the hard 10%. Which is, notably, the same routing architecture Microsoft built MDASH around, arrived at from the opposite end of the cost curve.

All benchmark figures here are Liquid's own, on Liquid's chosen comparison set — the standard caveat this blog applies to Alibaba's tables and everyone else's. The efficiency measurements are the more credible half, since throughput and memory on named hardware are the easiest claims for a third party to falsify.

What to expect next

• "Tokens per day per device" becomes a metric people actually quote. Price per million tokens is meaningless for a local model; sustained throughput within a memory ceiling is the number that decides what you can build.
• The background agent becomes the on-device product category. Not the chatbot on your phone — the hundred things running while you don't watch, which only make economic sense at zero marginal cost.
• Expect the coding gap to be the next target, and to be hard. Every lab shipping a small agentic model will aim there because that's where the money is; it's also the capability that has resisted compression most stubbornly.

References: Liquid AI — LFM2.5-2.6B announcement · LiquidAI/LFM2.5-2.6B-GGUF on Hugging Face · LFM Open License · Liquid Docs — model license · related coverage: Open Weights You Can't Actually Run · The Heavyweight Shift · The Price War Nobody Is Actually Fighting · How Open Is "Open"? · YC's QM harness