LFM2.5-2.6B: First agentic model you can run on your iphone

An agent running on an iPhone must fit in device memory, respond at interactive speed, and tolerate a slow or absent network. Those constraints rule out many models and cloud-dependent runtimes.

Liquid AI released LFM2.5-2.6B on August 4, 2026 as a 2.6B-parameter model post-trained for planning, tool calling, and multi-step agent work. Liquid reports roughly 30 tokens per second on a phone and provides deployment guidance for mobile hardware. The release announcement makes it a concrete candidate for an on-device pilot.

LFM2.5-2.6B makes a serious iOS agent pilot plausible for narrow, structured workflows. The model has relevant tool-use training and documented deployment options, but each product team still has to prove that its target workflow fits a 2.6B local model on the iPhones it supports.

What makes this an agent model

Parameter count does not make a model agentic. An agent needs to turn an intent into actions, call tools in the expected format, read their results, and continue until it can answer or stop safely.

LFM2.5-2.6B is a dense model with 2.69B total parameters, 30 layers, a 128K-token context window, and a 128,000-token vocabulary. Its architecture combines 22 short-convolution blocks with eight grouped-query attention blocks. These specifications describe a design optimized for efficient inference; product performance still requires device-level testing. The official model card lists the model's specifications and supported formats.

The larger change is in post-training. Liquid describes a four-stage recipe:

1. supervised fine-tuning for broad behavior and priority skills;
2. teacher specialization across instruction following, math, knowledge, code, tool use, and long context;
3. multi-domain on-policy distillation into one student model; and
4. agentic reinforcement learning inside agent harnesses and realistic productivity tasks.

Liquid says the model was trained in environments that expose it to tools, system prompts, and interaction patterns from harnesses such as Hermes Agent and OpenClaw. The training explicitly targets tool use. A finished assistant still needs a runtime, product tools, permissions, state management, and a user experience.

The model card describes a four-part tool loop: define tools, emit a tool call, return the tool result, and generate the final response. The model chooses an action and fills its arguments. Your runtime validates the call, checks permissions, executes the action, and decides whether a side effect needs confirmation.

That division is important. A local model can reduce the distance between a user's request and the next tool call. It does not own your authorization system, tenant boundaries, business rules, or data integrity.

Can it really run on an iPhone?

Yes, but “run on an iPhone” has three separate meanings:

Question	What the published material establishes	What still needs testing
Can the weights fit?	Liquid documents a 1.67 GB Q4_K_M GGUF, 2.87 GB Q8_0 build, and 5.4 GB BF16 build.	Runtime overhead, context cache, app memory limits, and available RAM on the target device.
Can the model generate locally?	Liquid reports about 30 tokens per second on a phone, and documents LFM deployment on iOS and Android through LEAP.	The exact iPhone model, quantization, context length, thermal state, and measurement method behind the phone result.
Can it operate as an agent?	Liquid documents local OpenAI-compatible endpoints and connections to Hermes Agent, OpenClaw, and Pi.	iOS tool adapters, background execution, permission prompts, offline data access, and recovery after an interrupted tool call.

The first row is not the same as app memory. A 1.67 GB model file still needs working memory for the runtime, token cache, prompt, generated output, and application. Longer context increases that pressure. Liquid's deployment guide recommends starting with Q4_K_M and using a smaller context such as 32K when memory is constrained, even though the model supports up to 128K tokens. The local-agent guide gives the quantization sizes and deployment trade-offs.

The second row is also easy to overread. A phone-level token rate is useful evidence that the model can be responsive on mobile hardware. It is not an iPhone compatibility matrix. A product team should treat the reported 30 tokens per second as a starting hypothesis, then measure on the exact iPhone generation, OS version, quantization, prompt length, and thermal conditions it plans to support.

Liquid's documented mobile path is its LEAP SDK. Its FAQ says the SDK can deploy LFM models to iOS and Android, while the model is also published in ONNX for cross-platform inference and its MLX checkpoint targets Apple Silicon. Each deployment option uses a different iPhone runtime. Before committing to an app architecture, confirm the current iOS package, supported model artifact, hardware acceleration path, and distribution constraints.

The benchmarks point to a narrow, useful niche

Liquid's published evaluation compares LFM2.5-2.6B with models from roughly 4.7B to 9.7B parameters. Selected results are below.

Benchmark	LFM2.5-2.6B	Qwen3.5-9B	Reading the result
BFCLv4	56.88	60.13	A larger model leads on this tool-calling benchmark.
ToolSandbox	77.83	76.44	LFM2.5-2.6B is slightly ahead in this tool-use environment.
Claw-Eval average	62.85	66.53	The larger model leads on this agent-harness evaluation.
LiveCodeBenchv6	59.41	69.86	Coding remains a clear reason to choose a larger model.

Liquid published these results; they have no independent replication cited here. The release specifies model versions, serving stack, generation settings, and different output limits by benchmark, so use the figures to form a test plan and avoid blanket rankings. The release's benchmark table and methodology are the right reference for the numbers.

The model card makes the intended boundary explicit: LFM2.5-2.6B is recommended for agentic workloads, tool use, extraction, retrieval-augmented generation, and long-context workflows. Agentic coding and knowledge-heavy tasks fall outside the recommendation. That boundary suits an iPhone workflow built around a small set of high-frequency actions with a handoff for the rest.

How to evaluate it without building the wrong thing

Choose the workflow before the model. A good first candidate has a small tool vocabulary, a clear success condition, and a reason to stay local. Examples include summarizing data already on the device, classifying an item before a user confirms an action, or preparing a structured update that another system can validate.

Then evaluate in this order:

1. Define the tools as narrow operations with typed arguments. Do not expose a general-purpose “do anything” function and expect a 2.6B model to supply the missing product logic.
2. Put authorization outside the model. The app or service that executes a tool must enforce the signed-in user's permissions, tenant scope, and confirmation rules.
3. Start with a quantized build and a realistic context budget. Measure model load time, time to first token, decode speed, peak memory, battery impact, tool latency, and recovery after failure.
4. Compare the same task and tool schemas with a cloud baseline. Track completed workflows, answer quality, and invalid or unsafe tool calls.
5. Add an explicit handoff for work that needs broad knowledge, complex code generation, fresh web data, or a larger context than the phone can comfortably maintain.

The agent runtime still needs state management, retries, validation, cancellation, and a policy for side effects. On-device inference changes where tokens are generated; it does not replace any of those controls.

Where an embedded agent fits in a SaaS product

For a SaaS team, the model is only one layer of the product experience. A useful architecture separates the in-product agent surface, the model backend, and the product's own action layer.

Ginger Labs can sit in the embedded agent or copilot layer inside the customer's application. Users describe an outcome, and the agent can reason over product schemas, records, and stages before calling the customer's product capabilities. An LFM2.5-2.6B runtime could be evaluated as one local inference option for a narrow workflow. The current Ginger Labs product context does not establish a specific integration, so that compatibility requires testing.

The customer owns the API and data model, domain rules, user permissions, tenant boundaries, allowed actions, and customer-facing experience that determine whether an action is correct. Ginger Labs does not turn a small local model into a complete product agent. Connect the model to a well-defined product action surface and make the resulting work understandable to the user.

MCP is a different boundary. It can expose selected product capabilities to compatible external AI clients, while an embedded agent keeps the interaction inside the customer's product. An iPhone pilot does not need MCP unless external clients are part of the use case.

Decide from the device and workflow constraints

Choose LFM2.5-2.6B when the local benefits are part of the product requirement: lower dependence on a network connection, predictable per-interaction inference cost, or keeping a narrow workflow on the device. Do not choose it because 2.6B sounds large enough or because a vendor benchmark leads a particular table.

The next step is a small device test with one read workflow and one write workflow that requires user confirmation. Run both on the target iPhone, record the end-to-end metrics, and compare them with a cloud model using the same tools. If the local model completes the narrow workflow with acceptable latency, memory use, and error recovery, expand the pilot. If it fails on tool selection or context management, keep the product experience and tool contract, then route that workflow to a larger model.

LFM2.5-2.6B makes the experiment plausible. The evidence supports a capable, agent-focused small model with a documented path toward phone deployment. Test it close to the user on work that fits its scale, then design the surrounding system around the limits observed on real devices.

Sources

• Liquid AI: LFM2.5-2.6B: Deploy Agents Everywhere
• Liquid AI model card: LFM2.5-2.6B
• Liquid Docs: LFM2.5-2.6B
• Liquid Docs: Run local agents with LFMs
• Liquid Docs FAQ: mobile deployment and quantization