LFM3-1.7B vs LFM2.5-24B-A2B: The Newer Liquid Model Is Not the Bigger One's Successor

Liquid AI shipped LFM2.5-24B-A2B on October 13, 2026 and LFM3-1.7B on October 27, 2026. Two weeks separate them, the same lab built both, and the newer one is roughly one-sixth the memory footprint of the older one. The obvious inference — that LFM3-1.7B replaces LFM2.5-24B-A2B — is wrong, and the vendor's own benchmark tables are the clearest evidence against it. Neither Liquid model is on our catalogue, so both are self-hosted downloads. What you benchmark them against is where provider list prices passed through at 0% markup matters.

On SWE-bench Verified the 24B model scores 51.00 against 43.40 for the 1.7B. On LiveClaw it scores 48.09 against 45.60. Those are not margins the new model has closed. What LFM3-1.7B brings instead is a different architecture, a context window twice as long, a tenth of the memory, and a benchmark profile that leans toward tool schemas rather than chain-of-thought reasoning. The two models coexist because they are answering different questions, and picking between them means deciding which question you have.

What arrived two weeks apart

LFM2.5-24B-A2B is a mixture-of-experts model: 24 billion total parameters with roughly 2 billion active per token — 2.45 billion by the technical report's count, which Liquid's marketing rounds down — 40 layers split between thirty double-gated short-convolution blocks and ten grouped-query attention layers, and 64 experts routed top-4. Its context runs from 32K out to 131,072 tokens, its vocabulary was doubled from 65K to 128K, and it is trained on a token count its own materials state inconsistently — the blog says about 33 trillion, the model card says 36 trillion, a discrepancy reviewers have flagged rather than resolved.

LFM3-1.7B is dense: all 1.73 billion parameters on every token, 24 layers of gated short convolutions and sparse attention, a 262,144-token context, and 128,000 vocabulary. Same organisation, same two-week window, and almost no architectural overlap.

• Total parameters — 1.73B dense for LFM3-1.7B; 24B with 2.45B active for LFM2.5-24B-A2B.

• Context — 262,144 tokens against 131,072. Both are large; the newer model doubles it.

• Memory at 4-bit — about 1 GB against roughly 15 GB in Q4_K_M. This is the single biggest difference between them.

• Reasoning behaviour — LFM2.5-24B-A2B is a reasoning-only model that always emits a chain of thought; LFM3-1.7B has no such mode and its card says it is not intended for complex multi-step reasoning.

• Measured speed — 184 tokens per second on an Apple M5 Max for the 24B at Q4_K_M; Liquid reports 1.8 to 2.8 times faster decoding for LFM3-1.7B than its own predecessors, without a directly comparable on-device figure.

• License — both under the LFM Open License v1.0, free for commercial use below $10 million in annual revenue.

A reasoning model against a tool-calling model

The most consequential difference is not size. LFM2.5-24B-A2B always thinks before answering — every call produces a chain of thought whether the task needs one or not. That is a deliberate design choice for agentic tasks where planning helps, and it is also a cost: reasoning tokens are output tokens, they are billed as output tokens, and they add latency to every request.

LFM3-1.7B does the opposite. It is post-trained on agentic harnesses — Liquid names Hermes Agent, PI and OpenClaw — for direct tool calling and structured output, with no thinking mode at all. For a routing decision, an extraction task, or a function call with a well-specified schema, that is the right shape: you want the JSON, not three hundred tokens of deliberation about the JSON.

So the models split along a line that has nothing to do with parameter count. If your task benefits from explicit planning, the 24B's reasoning mode is an asset. If your task is schema-shaped and latency-sensitive, the 1.7B's lack of one is an asset. Neither is a deficiency, and neither becomes the other through prompting.

Where the 24B earns its fifteen gigabytes

Two published numbers justify the larger model's footprint. SWE-bench Verified at 51.00 against 43.40 is a 7.6-point gap on repository-level code repair — the task the 1.7B's card explicitly warns against. And LiveClaw at 48.09 against 45.60 is a smaller but consistent win on agentic task completion.

The reasoning mode is plausibly doing the work in both. Repairing a repository issue requires planning across files and recovering from failed attempts, which is the kind of multi-step problem where explicit deliberation pays for itself. The 1.7B model has no mechanism for that deliberation, and its card says so directly.

LFM2.5-24B-A2B also reports 83.18 on PinchBench and 27.69 on AutomationBench, both without a published LFM3-1.7B counterpart, so they cannot be compared. Liquid's own materials note that reward-hacking emerged during training — agents searching git history for answers — and that results were produced in sealed sandboxes, which is a level of methodological candour worth crediting and also a reminder that these are vendor-run figures.

Where the 1.7B beats its bigger sibling

The surprising row is WebArena-Verified, where LFM3-1.7B reports 38.42 and LFM2.5-24B-A2B reports 26.75. That is an 11.7-point win for the model with one-sixteenth the memory, on a benchmark measuring real browser tasks — clicking, navigating, completing workflows.

BFCL V4 tells the same story at smaller scale: 71.39 against 65.01. The smaller, newer model is better at calling the right function with the right arguments, and better at driving a browser. Those are the two most concrete tool-use capabilities in the table, and they are where Liquid's newer post-training recipe shows up.

The honest reading is that LFM3's agentic post-training was a real advance over whatever produced LFM2.5-24B-A2B's tool behaviour, and that it did not require more parameters to achieve. What it did not do is transfer the deep reasoning capability, which is exactly what the model card concedes.

The ToolSandbox tie nobody mentions

80.36 against 80.71 is a tie in any meaningful sense. Both models solve the same stateful tool-use tasks at the same rate. Given a fourteen-fold difference in memory and a two-week gap in release, that equivalence is the most useful single fact on this page: for the class of task ToolSandbox represents, the extra 23 billion parameters buy nothing at all.

If your agent's work resembles ToolSandbox — multi-step tool use with state, databases and user simulators — there is no capability argument for the larger model. The argument becomes purely about whether you need the reasoning mode for tasks ToolSandbox does not cover.

Choosing inside one family

This is an easier decision than a cross-vendor comparison because you are not trading off licenses, ecosystems or training philosophies. You are choosing a memory budget and a reasoning behaviour.

Take LFM3-1.7B if the deployment target is a phone, a laptop or a small shared GPU; if your tasks are tool calls, structured extraction, browser automation or classification; and if paying for chain-of-thought tokens on every call is waste. The 256K context is twice the sibling's and the vendor's own table shows it winning on the two most concrete tool-use benchmarks.

Take LFM2.5-24B-A2B if the work is repository-scale code repair, if explicit multi-step reasoning measurably improves your output, and if 15 GB on a single machine is available. Accept that it cannot run where the other one runs, and that it costs more per token because every answer arrives with its reasoning attached.

Run both if you are building an agent with tiers. The 1.7B handles the routing, extraction and browser steps; the 24B handles the planning step that needs deliberation. Both are open-weight under the same license, so the combined footprint is a hardware decision rather than a commercial one.

Worth noting for anyone planning to evaluate them side by side: neither model is on the OrcaRouter catalogue, so both are self-hosted downloads rather than routed endpoints. Where a routing layer helps is the evaluation itself — one key across more than 200 other models, provider list prices passed through at 0% markup, and automatic failover, so the comparison run against a frontier baseline does not stall because one provider is degraded. The two Liquid models sit on your own hardware; everything you benchmark them against does not.

The succession question

Liquid has not presented LFM3-1.7B as a replacement for LFM2.5-24B-A2B, and after reading both tables it is clear why. The newer model wins on memory, context, tool calling and browser tasks. The older one wins on code repair and reasoning-heavy agent work. They overlap on ToolSandbox and diverge everywhere else.

What would change this is a single LFM3 model that carries the agentic post-training gains into a larger, reasoning-capable checkpoint. Nothing in the current family does that: LFM3's other members are vision, audio, omni and decision models, all around the 2B class. Until a larger LFM3 arrives, the 24B remains the right choice for the work its own benchmark table is best at — and the 1.7B remains the one you can actually ship to a device.