Liquid AI releases open-weight LFM2.5-24B-A2B, a 2B-active reasoning model for on-device agents
- LFM2.5-24B-A2B is a 24B-parameter reasoning model with only 2B active parameters per token, released open-weight on Hugging Face for fast, private on-device agents.
- On LiveClaw it scores 48.09 versus 38.19 for Qwen3.6-35B-A3B, and on AutomationBench 27.69 versus 8.72, but it trails Qwen on SWE-Bench Verified (51.00 vs 66.20) and GPQA Diamond (74.42 vs 83.69).
- It runs up to 1.7× faster than comparable MoEs, reaching 184 tokens/s on an Apple M5 Max and up to 21K output tokens/s on a single NVIDIA B300 GPU.
- The model uses 40 layers with 64 experts per MoE block and top-4 routing, and its context window grows from 32,768 to 131,072 tokens while the vocabulary doubles from 65K to 128K.
- Unlike its predecessor LFM2-24B-A2B, it is a reasoning-only model that produces an explicit chain of thought before its final answer, and pretraining was scaled up from 17T tokens.
Hacker News opinions
Wow, 184 tok/s and 21K tok/s for a model that seems this capable is wild. What AutomationBench actually tests is the part I can't figure out, since it's the only benchmark where it really pulls ahead.
My guess is AutomationBench is mostly a product of their agentic RL environments for those specific domains. Closest in size that beats it across that range of benchmarks is Inkling-Small at 276B, unless I'm forgetting someone.
I'm getting 200-320 tok/s on a 5070 Ti with 131k context on llama.cpp and no tuning. Can't speak to the intelligence yet, but these small agentic models are a lot of fun to play with.
How many tokens/s do you need for a coding agent to feel like Claude or codex? I'd say only 65.
It's kind of a loaded question. This model gets a lot of tok/s but reasoning is forced on, so time-to-answer depends on how much it over-reasons and how much it likes tool use.
Claude Code is 60-80 tps for me, and codex is mostly 40-50 depending on the model.
AFAIU prefill speed matters more for agentic coding, since the harness spends more time reading than writing new code. Qwen spends a lot of time reasoning, so it hurts more there.
If Qwen released a Qwen3.8 MoE of similar size, I'd expect roughly this model's capability. So someone caught up to Qwen in parameter efficiency, albeit Qwen from a month or two ago.
I don't buy that. On SWE-Bench Verified it's clearly worse than Qwen 3.6 35B-A3B, and it only clearly wins on AutomationBench, ToolSandbox, and LiveClaw. For my use cases Qwen still looks better.
I asked it to implement the simplest todo in the ghostty codebase and it failed badly, going in circles fixing one compile error and adding another. Qwen 3.8 was slower at 40 tok/s versus 75, but it got the job done.
Have you tried Gemma 4 26B-A4B? I think it's underrated for tasks like that, though maybe I've just been lucky.
In my experience it's stronger for terminal work, like chaining bash calls and monitoring background tasks, than for straight coding. Good with web and file search.
On a private benchmark I have, it's much worse than Qwen 35B A3B on general knowledge. It probably still beats Qwen 9B at much higher speed.
Fast is fast, 18 tk/s on an Intel Core 7 155H laptop, but the quality is something else. It put out some old knowledge when I asked general questions.
The license has a questionably enforceable non-commercial clause, which is confusing. I wish they had talked to an IP lawyer.
The license is generous (free under $10m revenue), but the pricing is confusing when it shows API pricing first.
Training a mid-size model like this can take anywhere from $500k to $5m in GPU-hours. The amortization question is harder to answer without knowing their financials.