Liquid AI's LFM2.5-24B brings reasoning to local agents

Liquid AI's LFM2.5-24B-A2B gives self-hosters another reasoning model for tool-using agents. The October release targets local execution with a 131,072-token context window and downloadable checkpoints. Its benchmark and speed figures are Liquid AI's measurements, not independent DeAI tests.

Key facts

• The model card lists 24.0B total parameters and 2.45B active per token; the A2B branding rounds the active count.
• Liquid AI reports 184 tokens per second on an Apple M5 Max, measured with llama.cpp, Q4_K_M quantization, and a 4K-token input context.
• The company's evaluation table gives LFM2.5 a LiveClaw score of 48.09, versus 38.19 for Qwen3.6-35B-A3B.
• The same table puts its SWE-Bench Verified result at 51.00, below Qwen's 66.20 in the reported OpenCode setup.

What shipped

The release post, collected by DeAI's feed on October 14, describes a text-only model that reasons before answering, calls tools, and operates inside agent harnesses. Liquid AI says its post-training included agentic reinforcement learning in OpenClaw, Hermes Agent, Pi, and OpenCode. That is relevant training context, not proof that it will complete arbitrary tasks reliably in those applications.

The detailed card distinguishes the native checkpoint from FP8, GGUF, ONNX, and MLX variants. Those packaging choices matter more to a local deployment than the headline active-parameter count. A sparse model still has to store its inactive experts somewhere; choosing an Apple-oriented quantization or a server-oriented checkpoint changes the memory and runtime requirements.

Liquid AI also changed the operating behavior relative to the predecessor. Its card describes this version as a pure reasoning model whose template starts a thinking segment. An application cannot assume the same response length or time to final answer as a model that can skip reasoning entirely. Faster token generation may be offset by more generated reasoning on a particular task.

What the numbers establish

The local throughput result has a useful disclosure attached: quantization, runtime, and input length. It should be read with those conditions. Liquid AI's separate claim of more than 21K output tokens per second on a B300 measures aggregate GPU throughput under concurrency. It is not the interactive response speed of one local agent and cannot be compared directly with the laptop number.

The benchmark table is similarly mixed. Liquid AI reports strengths in tool use and instruction following, but its own comparison shows Qwen ahead on coding and several knowledge-heavy tasks. The release recommends retrieval or web search for knowledge-heavy workloads. That qualification belongs in deployment planning alongside the favorable tool-use scores.

For an operator, the relevant unit is a completed task. A reproducible evaluation would hold the repository or document set, harness, tool permissions, reasoning budget, and stopping rules constant. It would record unsuccessful tool calls and retries as well as successful answers. DeAI has not run that comparison, so the published scores remain attributed results.

Local inference and the privacy boundary

The release repeatedly uses the word private. Running the checkpoint locally gives the operator control over the inference machine. It does not establish that the whole agent stays offline. A browser tool, search service, remote repository, or telemetry plugin may still transmit the material an agent reads.

That distinction is covered in DeAI's private-inference explainer. A deployment review should follow a document from its storage location through the harness, model endpoint, tools, and logs. Keeping model execution local is one boundary in that path. It is not an attestation about every other component.

Cost needs the same treatment. DeAI's self-hosting versus API economics guide separates owned hardware from utilization and operating expense. This release adds another candidate for that calculation; a vendor speed chart alone cannot establish which route costs less for a particular team.

Background and next checks

The broader model coverage hub tracks downloadable releases, while the open-weight explainer explains why weight access and licensing must be checked separately. This card labels its license as LFM1.0 rather than Apache or MIT. Builders should review the linked terms for their intended deployment instead of inferring unrestricted use from download access.

The practical next step is a limited replay of real tasks with the exact checkpoint and template the application will use. Start with reading and low-impact tool calls, then inspect whether reasoning output, function-call syntax, and tool results survive the full serving path. Liquid AI documents Python-style function calls by default and an option to request JSON calls; a client expecting only an OpenAI-shaped tool-call object needs a compatible parser.

Record prompt length, peak memory, time to first useful action, total generation, and final task success. Those observations would show whether this model's reported strengths carry over to a local workflow. Until then, the release is a concrete new deployment option with disclosed trade-offs, rather than a verified replacement for a larger coding model.