Liquid AI has released LFM2.5-2.6B, a compact model designed to run agent workflows on local devices. According to the company, it can follow instructions, call tools and complete multi-step tasks using less than 2.5GB of memory.
The release broadens the range of devices that developers could use for local agents. Liquid AI lists laptops, desktop CPUs and phones, alongside server deployment through common inference frameworks. Businesses could gain more control over where data goes, reduce reliance on cloud inference and run high-volume tasks without paying for each model call.
Those benefits remain vendor claims. The evidence supplied for this article contains Liquid AI’s own benchmarks and performance measurements, with no independent replication. The model’s value will depend on the workflow, hardware, permissions and quality threshold a business sets around it.
What Liquid
What Liquid AI has released
LFM2.5-2.6B comes in base and instruction-tuned versions. Liquid AI says the model was pre-trained on about 34 trillion tokens, then given a training stage that extended its context window to 128,000 tokens.
The company describes four post-training stages. These include supervised training weighted towards tool use and agent trajectories, specialist teacher models for different domains, distillation into one model and reinforcement learning inside agent frameworks.
That last stage is relevant to developers. Liquid AI says it trained the model across different tools, system prompts and multi-turn environments, including harnesses such as OpenClaw and Hermes Agent. Training within those environments may help a small model cope with the formats and interactions an agent encounters after deployment. The supplied evidence does not show how well that compatibility transfers to an organisation’s own tools or instructions.
The model supports Transformers and, according to Liquid AI, ships with support across llama.cpp, MLX, vLLM, SGLang and ONNX. The company also offers a browser demonstration using WebGPU. Availability across several runtimes gives technical teams more choice over where they test it, from a browser prototype to a local service.
Performance Case
The performance case comes from Liquid AI
Liquid AI reports decoding speeds of 220 tokens per second on an Apple M5 Max and 113 tokens per second on an AMD Ryzen AI Max+ 395. It also says the model can run at 30 tokens per second on a phone and reach almost 15,000 output tokens per second on one H100 GPU under high concurrency.
These figures suggest that a 2.6 billion parameter model can produce text fast enough for interactive agent work on current hardware. The article does not provide enough detail to treat those numbers as a purchasing benchmark. It does not establish how quantisation, context length, tool latency, power use or sustained workloads affected each result.
Liquid AI’s benchmark table compares LFM2.5-2.6B with Gemma and Qwen models ranging from 4.7 billion to 9.7 billion parameters. In the company’s tests, LFM2.5-2.6B led the listed instruction-following benchmarks. It also led most of the listed tool-use tests, with Qwen3.5-9B scoring higher on BFCLv4.
The results were more mixed elsewhere. Larger models led the coding benchmarks, and Qwen3.5-9B achieved higher results on several agent evaluations. Liquid AI acknowledges the coding gap and recommends a larger model for that work.
Businesses should read the table as evidence of a promising candidate for evaluation, rather than proof that the model will outperform larger alternatives in production. Liquid AI selected the models, tasks and test configuration. The evidence pack contains no third-party benchmark, security assessment or long-running deployment study for LFM2.5-2.6B.
Local Model
A local model does not provide a safe workflow by itself
A small model can reduce one deployment constraint: the need to send every prompt to a hosted model. Data stays on the device only when the surrounding application keeps it there. An agent with web access, analytics, remote tools or cloud storage can still transmit information outside the device.
The same distinction applies to security. Model size says little about the damage an agent can cause if it receives broad credentials or permission to alter important files. Teams need to control the agent’s action surface as closely as they evaluate its answers.
A separate case study from GitHub illustrates that workflow design. GitHub describes how the Microsoft Aspire team uses GitHub Agentic Workflows to draft documentation after product changes merge. This workflow did not use LFM2.5-2.6B, so it provides no evidence about Liquid AI’s model. It does offer a concrete pattern for deploying agents around business systems.
The Aspire workflow resolves the target documentation branch with deterministic code before the model starts. The agent reads the product change and proposes documentation, then emits a structured description of the action it wants to take. A separate handler creates a draft pull request under narrow rules. The workflow limits repository access, restricts allowed branches, blocks protected files and assigns a human reviewer.
GitHub reports 396 workflow runs during a rolling 30-day period from 3 May to 2 June 2026. The system created 82 draft documentation pull requests, all of which merged, with a median time to merge of 44.8 hours. GitHub says engineers reviewed every draft and that 96 per cent merged within seven days.
These are self-reported operational figures from the team that built the workflow. The article provides no control group, external audit or measurement of editing effort. It also records an earlier version that produced nine closed pull requests out of 69 after treating internal changes as documentation work. The team tightened its prompt and added negative examples in response.
That history is useful. Agent quality depends on the complete system: task selection, deterministic checks, permissions, review and feedback from failures. A capable model cannot compensate for a workflow that gives it an ambiguous brief or excessive access.
Where Local
Where local agents may be useful
For a business, the strongest early candidates are frequent tasks with sensitive inputs, clear outputs and a cheap route for human correction. Examples could include classifying internal documents, preparing structured drafts from approved files or proposing updates for review.
Creative teams could test local processing where source material should remain on controlled hardware, such as organising project notes or checking drafts against a defined style guide. The model’s reported coding weakness makes autonomous software changes a less convincing first use, especially where mistakes could reach production.
Local inference may also change the cost calculation for repetitive work. Liquid AI says users can avoid a cloud inference bill, although local deployment still carries hardware, electricity, maintenance and engineering costs. Teams should compare the total cost of a working process rather than the price of individual model calls.
The evidence pack does not establish commercial licensing terms, performance across languages, battery impact on mobile devices or reliability over long tool sequences. Organisations should confirm those points against their own requirements before deployment.
Practical Evaluation
A practical evaluation plan
1. Choose one bounded task. Start with work that has an observable result and can wait for approval. Avoid production credentials and irreversible actions during the pilot.
2. Keep fixed rules outside the model. Use ordinary code for branch selection, file restrictions, spending limits and other decisions that should produce the same answer each time.
3. Restrict tools and data. Give the agent access only to the files, applications and actions required for that task. Check whether any connected tool sends local data to an external service.
4. Build a representative test set. Include routine cases, ambiguous requests, malformed inputs and examples where the correct action is to stop. Compare the model with the alternative you would use in practice, including a larger hosted model where appropriate.
5. Measure operational outcomes. Record completion rate, incorrect actions, latency, human editing time and failures that require escalation. Vendor token speeds cannot answer whether the workflow saves time.
6. Require review and a fallback. Route proposed changes through drafts, queues or other reversible states. If the agent cannot complete an action, preserve the request for a person instead of dropping it.
LFM2.5-2.6B gives developers a credible new option to test when privacy, device deployment or inference volume makes a compact model attractive. Liquid AI’s launch results justify an evaluation, not a broad rollout. Businesses will learn more from a constrained pilot on their own work than from the model’s parameter count or benchmark position.
Checked sources