LFM3 for SMBs: Local Browser Agents and Tool Use

By Lazar Milicevic · Published October 29, 2026 · 11 min read

You have an email inbox, a calendar, and a handful of browser tasks you'd happily hand to an agent, but some of that data can't go to a third-party API. Liquid AI's new LFM3 family claims to run those jobs on a laptop or a phone. The company-reported numbers are striking, and so are the caveats, so this post separates what's measured from what's marketing.

What Liquid AI actually released

On October 27, 2026, Liquid AI released LFM3, a family of six open-weight models that all share a 1.7B-parameter backbone, with the specialized versions at around 2B parameters (Unite.AI). All six branch from LFM3-1.7B-Base.

Two details matter for planning. First, the text model has a 256K-token context window when you run it yourself (Hugging Face blog). Second, Liquid describes the model as post-trained for agent-style work, with example use cases such as triaging an inbox, managing a calendar, and researching the web. Check the model card and Liquid's announcement for which agent harnesses it is documented to work with.

One framing note: the headlines say "enterprise-controlled devices," and VentureBeat's page title says "local devices." In practice, the weights are open, they run on consumer hardware, and the license allows free commercial use below a revenue threshold. That makes this relevant to a five-person company, not only to enterprises with device fleets.

The benchmark numbers, read carefully

Everything in this section is company-reported by Liquid AI. At the time of writing, we did not find an independent evaluation, so treat the figures as a hypothesis to test, not a result.

Where LFM3-1.7B leads Qwen3.5-9B in Liquid's tests:

For reference, Liquid's previous LFM2.5-2.6B scored 3.02 on WebArena-Verified and 0.94 on AutomationBench (VentureBeat). The Hugging Face model card also lists other small models on AutomationBench: 4.71 for MiniCPM5 2B, 1.92 for Gemma 4 E4B, and 8.67 for Qwen3.5 4B (model card). A jump from low single digits to 41.29 in one generation is large enough that it's worth verifying yourself before trusting it.

Where it trails Qwen3.5-9B:

The pattern is consistent. The model is strong on narrow, structured tasks (call this tool with these arguments, click through this page) and weaker on hard reasoning, long-context recall, and coding. Liquid's own documentation says as much: it is not recommended for agentic coding or complex multi-step reasoning because of its size.

I'd also avoid repeating the "beats models five times its size" line without qualification. It holds on selected agentic and tool-use benchmarks, as measured by the vendor. The comparisons in the sources I reviewed are against Qwen3.5, Gemma 4, MiniCPM5, and Liquid's earlier LFM2.5. I did not find a head-to-head against Claude or another frontier model, so anyone claiming LFM3 matches one should be able to show you the test.

"Fits in 1 GB" is not the number you should budget

The headline figure is that the text model fits in about 1 GB at 4-bit precision. That is the weight size. Total memory in use is higher, because the KV cache and runtime overhead come on top.

Liquid's own measurements, using llama.cpp with Q4_0 and a 32K-token input (VentureBeat):

Liquid also clarified to VentureBeat that a 1.6 GB figure for a 128K-token context covers the KV cache only. There's no published full memory budget at 256K. If you plan to use the long context, measure on your own hardware.

Practical takeaway: a modern laptop or a recent phone has room for this model. A cheap VPS with 2 GB of RAM does not, once you add the OS and your agent harness.

Running it: a minimal local test

The models support llama.cpp, MLX, and vLLM, with checkpoints in BF16, FP8, NVFP4, GGUF, MLX, and ONNX (Unite.AI). The fastest way to see whether it fits your workload is to serve it locally behind an OpenAI-compatible endpoint and point your existing agent code at it.

# Example: serve a GGUF build with llama.cpp's server
# (check the model card for the exact repo and filename)
llama-server \
  -m ./LFM3-1.7B-Q4_0.gguf \
  -c 32768 \
  --port 8080

# Point any OpenAI-compatible client at the local server
from openai import OpenAI

client = OpenAI(base_url="localhost api_key="local")

tools = [{
    "type": "function",
    "function": {
        "name": "create_calendar_event",
        "description": "Create a calendar event",
        "parameters": {
            "type": "object",
            "properties": {
                "title": {"type": "string"},
                "start": {"type": "string", "description": "ISO 8601 datetime"},
                "duration_minutes": {"type": "integer"},
            },
            "required": ["title", "start"],
        },
    },
}]

resp = client.chat.completions.create(
    model="lfm3-1.7b",
    messages=[{"role": "user", "content": "Book a 30 minute call with Dana next Tuesday at 2pm."}],
    tools=tools,
)
print(resp.choices[0].message.tool_calls)

Keep your harness model-agnostic like this and swapping between a local model and a hosted one becomes a config change, not a rewrite. That's what makes a fair comparison possible.

Where small local models fit, and where they don't

Based on the vendor's own benchmark profile and documentation, here is how I'd sort workloads. This is a judgment call to validate on your data, not a measured result.

Reasonable candidates for a local small model:

• Inbox triage into fixed categories (invoice, lead, support, spam)
• Calendar operations with a well-defined tool schema
• Structured browser tasks: logging into a known portal, downloading a statement, filling a form with fixed fields
• Voice commands that map to a small set of tools (LFM3-Audio-2B describes tool calling from audio input)
• Image classification on a narrow domain, after fine-tuning

Keep on a stronger model:

• Anything involving code changes or debugging
• Multi-step reasoning where one wrong step cascades
• Long-document analysis where recall over 100K+ tokens matters (note the RULER 128K gap above)
• Open-ended research where the task isn't well specified

A sensible architecture is routing: send the high-volume, well-structured, privacy-sensitive steps to the local model and escalate ambiguous or reasoning-heavy steps to a larger one. The small model also needs a clean way to say "I'm not sure." Build that escalation path before you build anything else.

Voice and vision: what the specialized models add

Audio. LFM3-Audio-2B supports 18 languages, scores 3.83 on UTMOSv2 speech quality (versus 3.22 for LFM2.5-Audio-1.5B), and reports time to first token as low as 50 ms (model card). The card describes tool calling from audio input, which is the piece that matters for "voice command triggers an action" workflows. For a field-service business, that could be a technician dictating a job note that becomes a structured record, though you'd need to test accuracy on real accents and noisy environments.

Vision and video. LFM3-VL-2B is the first LFM vision model to accept video. Liquid reports a 71.4 average across 62 vision benchmarks, up from 57.6 for LFM2.5-VL-3B, with 1.9B parameters against 3.1B, and describes it as on par with Gemma 4 12B in a self-reported comparison (Unite.AI).

The most useful data point for a small business is the customization example. Liquid adapted LFM3-VL-2B on about 3,000 public wind-turbine images with several hours of training on an Nvidia A100. On roughly 1,400 held-out images, classification accuracy reached 67%, up from below 10% before specialization (VentureBeat).

Read that both ways. Going from under 10% to 67% shows how much specialization matters. But 67% is not a number you'd ship for most inspection tasks without a human in the loop. For a narrow classification problem, treat fine-tuning as the entry ticket, then measure whether the accuracy you reach is good enough for your use case.

Every LFM3 model can be fine-tuned on a single GPU, and Liquid published notebooks for supervised fine-tuning, DPO, GRPO, and continued pre-training (Unite.AI).

The license: read this before you build

This is the part most coverage skips, and it matters most for the audience reading this blog. The models ship under the LFM Open License v1.0. Free commercial use applies only below $10 million in annual revenue; at $10 million or more, you need a separate commercial license from Liquid (contact sales@liquid.ai) (license guide).

Details worth knowing:

• Revenue is counted for the whole "Legal Entity," which includes entities that control you, are controlled by you, or are under common control with you. If you're a small company inside a larger group, the group's revenue may be what counts.
• "Commercial Use" covers any use for direct or indirect commercial advantage. The license states that using the models in your business can count as commercial use even if they don't generate revenue directly. Running an internal triage agent counts.
• The threshold wording is ambiguous at exactly $10 million: the Threshold text says "or more," while clause 5 says "exceeds." If you're near the line, get clarity from Liquid in writing.
• There is no published price for the commercial license above the threshold, so you can't model that cost today.

If you're a solo operator or a team well under the threshold, this likely isn't a blocker. But if your company is part of a larger group, or you're growing toward $10M, factor the licensing question in before you build a product on top of it. I'm not a lawyer; have one read the license if the stakes are high.

Local, hosted, or Claude: the cost question

There are three ways to run LFM3, and they have different cost shapes.

1. Self-hosted on your own hardware. No per-token fee. You pay in hardware you already own (or buy), engineering time, and maintenance.
2. Liquid's hosted API. VentureBeat reports the text model at $0.08 per million input tokens, $0.20 per million output tokens, and $0.02 for cached input, with a 128,000-token context limit (versus 256K for the downloadable model). Those prices come from Liquid's hosted console, so check the current pricing before relying on them.
3. A frontier model like Claude. Check Anthropic's current pricing page for rates.

A quick illustrative example, with round numbers and not a quote: suppose an inbox-triage agent processes 1,000 emails a day at roughly 2,000 input tokens and 200 output tokens each. That's 2M input and 0.2M output tokens per day. At the hosted LFM3 rates above, that's about $0.16 plus $0.04, or roughly $0.20 per day. The same volume on a larger model costs more per token, but the real question isn't price per token. It's cost per correctly handled email, including the cost of the ones the model gets wrong and a human has to fix.

That's the metric to measure. A cheap model with a 15% error rate that needs review can cost more than a pricier model with a 3% error rate. Run both on 200 of your real emails, label the outcomes, and compute cost per correct result.

Privacy: what local does and doesn't guarantee

The models are designed to run on-device, and that's a real advantage for data you can't send to a third party. But the privacy benefit depends on how your application handles recordings, logs, and external tools.

Concretely, a local model doesn't help if your harness logs full prompts to a cloud monitoring service, if the agent's tools call external APIs with the sensitive data as arguments, or if voice recordings get stored unencrypted. "Runs locally" is a necessary condition for keeping data in-house, not a sufficient one. Audit the whole pipeline, not just the model.

A practical evaluation plan

Before committing, I'd run this over a week:

1. Pick one workflow with a clear success criterion and 100-200 historical examples.
2. Label ground truth for those examples yourself.
3. Run the same harness against LFM3-1.7B locally and a stronger hosted model, changing only the base URL.
4. Score three things: task success rate, cost per correct result, and latency.
5. Add an escalation rule, where low confidence or a failed tool call falls back to the stronger model, and measure how often it triggers.
6. Check the license against your company's revenue and group structure.

If the small model wins on your task, you've found a cheap, private path. If it loses, you've spent a few hours, not a few months.

Where I'd start

I build AI automations for small teams, and the approach I'd take here is routing rather than picking one model: structured, high-volume, privacy-sensitive steps go to a smaller model when it measures well, and anything ambiguous or reasoning-heavy goes to a stronger model like Claude. Public benchmarks, especially vendor-reported ones, rarely predict how a model behaves on your data, so the comparison that counts is the one you run on your own tasks.

LFM3 is a good candidate for that kind of test, particularly for browser automation and tool use where its reported scores are strongest. Use cost per correct result as the yardstick, and let your own workflow data decide.

Work with BizFlowAI

If you'd rather have this built for you, that's what we do: production AI automation for solo founders and small teams — agents, integrations, and document pipelines that actually ship.

Request a free discovery call — 30 minutes, we map the highest-ROI automation in your workflow. No pitch deck, just engineering.

More guides like this on the BizFlowAI blog.