LFM2.5-2.6B: Liquid AI's Small Reasoning Model for Agents

Small models are usually sold on one property: they fit. The interesting question is what they are good at once they fit, and the honest answer for most sub-5B models has been "short, simple tasks". LFM2.5-2.6B from Liquid AI is aimed at something more specific: agent steps, tool calls, extraction and retrieval-augmented answers, run on a laptop or a phone-class device.

Liquid AI's model card is unusually direct about the limits. It recommends the model for agentic workloads, tool use, data extraction, RAG and long-context processing, and explicitly does not recommend it for agentic coding or knowledge-heavy tasks. That second sentence is worth more than most benchmark tables.

A hybrid that is mostly convolution

The architecture is not a standard transformer. The card lists 30 layers: 22 double-gated short convolution blocks and only 8 grouped-query attention blocks. Total size is about 2.69B parameters, with a 128K-token vocabulary. Pre-training covered roughly 34T tokens, with mid-training extending the context window to 128K tokens.

The reason to care is memory. Attention layers are the ones whose KV cache grows with context length; convolution blocks keep a small fixed state. With only eight attention layers, long prompts cost far less memory than they would on a pure transformer of the same size, which is what makes a 128K window plausible on modest hardware. KV cache explained walks through why that scaling dominates on-device inference.

Weights went up on Hugging Face in early August 2026, with a separate base checkpoint for anyone who wants to fine-tune. The licence is Liquid AI's own LFM Open License v1.0, not Apache or MIT. Read the terms before you ship it in a commercial product, since they are not a standard permissive licence.

It always thinks

Liquid AI describes LFM2.5-2.6B as a pure reasoning model that always thinks before it answers; the chat template opens every assistant turn with a <think> tag. There is no switch to turn this off.

That is a real trade-off for a small model. Reasoning tokens improve multi-step answers, but they add latency and output volume to every call, including trivial ones. On-device, where you are generating at tens of tokens per second rather than hundreds, a few hundred thinking tokens before a one-line answer is noticeable. Budget for it, and strip the thinking block before you pass output to the next step. Reasoning models explained covers when thinking longer actually helps.

The card recommends conservative sampling: temperature 0.1, top-k 50 and a repetition penalty of 1.1. Small reasoning models are prone to looping at higher temperatures, so start there.

Tool calls come out as Python

The default tool-calling format surprises people. Define tools as JSON in the system prompt or through the chat template, and the model emits calls as a Python-style list between <|tool_call_start|> and <|tool_call_end|> tokens. You run the call, return the result in a tool role message, and the model gives a plain-text final answer.

If your harness expects JSON tool calls, say so in the system prompt and the model switches. If you serve it behind an OpenAI-compatible server, check that the server's parser understands the default format; a mismatched parser shows up as the model "ignoring" tools when it is in fact calling them in a syntax nobody reads.

What the benchmark table says about knowledge

The card compares LFM2.5-2.6B against Gemma 4 E2B and E4B and Qwen3.5 4B and 9B. The pattern is clearer than any single row:

• Instruction following is the standout: IFBench 59.17 against 48.40 for Qwen3.5 4B, and IFStruct 85.49.
• Tool use is competitive with models up to nearly four times its size: BFCLv4 56.88 against 50.56 for Qwen3.5 4B and 60.13 for Qwen3.5 9B; ToolSandbox 77.83.
• Code trails: LiveCodeBench v6 59.41 against 69.86 for Qwen3.5 9B.
• Knowledge is thin but honest. On Artificial Analysis's Omniscience evaluation it answers correctly only 8.13% of the time, against 17.63% for Qwen3.5 4B, yet its non-hallucination rate is 59.04% against 12.66%. It declines rather than invents.

That last row is the most useful thing on the card. A small model that knows it does not know is exactly what you want under a retrieval system, where the facts come from the context and fabrication is the main failure mode. It is exactly what you do not want as a standalone question-answering bot.

One row is a warning: τ³-Bench Banking at 5.67, with every model in the table in single digits. Long, policy-constrained customer-service dialogues remain out of reach for this size class.

Free endpoint or your own hardware

On OpenRouter it is offered as a :free variant, which is the same model on a rate-limited endpoint. That is fine for evaluation and hobby use, and unsuitable for anything with a latency or uptime requirement; free endpoints can also cap context below the model's 128K, and the OpenRouter listing showed 65,536 tokens at the time of writing. Free API tiers compared covers how those limits tend to shift.

Self-hosting is the more natural home. Liquid AI publishes a GGUF build for llama.cpp-compatible tools, the card targets recent transformers releases, and the model is small enough to run on a laptop CPU or GPU. If you are deciding between that and an API, local models vs API lays out the arithmetic.

Where it fits

• Use it as the answerer under RAG, where its reluctance to invent is an asset.
• Use it for structured extraction and simple tool-calling steps inside a larger agent.
• Use it on-device where data cannot leave the machine.
• Do not use it for coding agents, open-domain trivia or long policy-heavy dialogues.

Test it on twenty of your own extraction or tool-call examples at the recommended sampling settings, and count malformed calls and fabricated fields separately. Those two numbers will tell you more than the card can.