TL;DR: Liquid AI's LFM3 1.7B is a strong contender for the best local LLM for lightweight agents. Its 4-bit model weights take roughly 1GB, and it supports up to 256K tokens of context.
Its hybrid architecture helps process long inputs efficiently. It scores 38.4 on WebArena, ahead of some larger models, including 9B alternatives.
This guide covers Ollama setup and three practical tests: browser action planning, contract risk analysis, and support tickets converted into proposed API calls. You'll also learn where the model needs more guidance and when a larger model makes sense.
Fact: 256K-token context and about 1GB of quantized weights.
Avoid: Assuming generated actions were executed on a live system.
Try: Verify outputs before running payments or refunds.
What's stopping you from running AI locally right now?
Table of Contents
Introduction
A tiny AI model that runs on just 1GB of memory is beating models 5 times its size at browser tasks. Sounds crazy, right?
Liquid AI's new LFM3 1.7B might be one of the best local LLM options for running AI agents on everyday hardware.
It comes with a massive 256K-token context window, needs only around 1GB of memory in 4-bit, and scores 38.4 on WebArena, ahead of some 9B models.
But can something this small actually handle real work?
In this guide, I'll break down how LFM3 works and walk you through 3 practical tests: automating browser tasks, auditing legal contracts, and turning customer support tickets into API calls.
You'll see what this tiny model can actually do, where it struggles, and if it's worth running locally.
I. Understanding Liquid AI's LFM3 1.7B
Liquid AI's LFM3 family includes models for text, vision, audio, and decision-making. The 1.7B text model is especially interesting because it's built for running AI agents locally.
The biggest advantage? Its 4-bit version takes roughly 1GB for model weights, making it practical to run on everyday laptops, phones, and basic PCs.
So, how can such a small model handle 256K tokens?
1. The 24-Layer Tri-Hybrid Architecture
Most traditional Transformers rely heavily on attention, which gets expensive as prompts grow longer.
LFM3 uses 24 layers combining 3 different mechanisms:
Component | What it does |
|---|---|
Convolutional layers | Process tokens efficiently without constantly comparing distant words, speeding up long-input processing. |
Sliding-window attention | Focuses on 256 tokens at a time, keeping nearby information accurate while reducing memory use. |
Global attention | Connects information across distant parts of a document, helping track details from beginning to end. |
→ This design helps LFM3 process large documents faster while keeping memory requirements manageable.
2. How Was LFM3 Trained?
Liquid AI trained the model using approximately 22 trillion tokens, including:
15T web tokens for general knowledge.
3T code and math tokens, plus 3.5T agent traces for reasoning and tool-based workflows.
The team also trained 6 specialist models across math, coding, and agent tasks, then distilled their knowledge into the smaller 1.7B model.
That's why LFM3 is worth considering among the best local LLM options for lightweight AI agents. Its training and architecture are designed to handle long inputs and structured tasks on limited hardware.
Learn How to Make AI Work For You!
Transform your AI skills with the AI Fire Academy Premium Plan - FREE for 14 days! Gain instant access to 700+ AI workflows, advanced tutorials, exclusive case studies and unbeatable discounts. No risks, cancel anytime.
II. LFM3 1.7B Benchmark Performance
LFM3 1.7B is outperforming models with up to 9B parameters on several agent benchmarks, despite being much smaller.
Take a look at the numbers:
Benchmark | LFM3 1.7B Score | Why it matters |
|---|---|---|
WebArena | 38.4 | Beats MiniCPM 5 and Qwen 3.5 models, including 9B, at browser-based tasks. |
Desktop automation | ~41 | Around 3× better than the 9B baseline at executing desktop scripts. |
Agent framework | ~45.6 | Leads the comparison in continuous agent workflows. |
Tool calling & instruction following | Ahead of 4B and 9B baselines | Better at following instructions and selecting tools for specific tasks. |
The desktop automation result is especially impressive. While competing models score roughly 4–15 points, LFM3 reaches about 41.
That means a model small enough to run on your laptop can compete with much larger models when handling automated workflows.
→ My takeaway: If you're looking for the best local LLM for browser automation or tool-calling agents, LFM3 1.7B is worth testing.
Of course, benchmark scores only tell part of the story. Let's see how it handles actual tasks.
III. Hands-On Test with 3 Real Tasks
I put LFM3 through 3 practical tests covering browser automation, legal document analysis, and customer support workflows.
1. Quick Setup with Ollama
The setup is pretty straightforward:
Download the model: Get the ~1GB 4-bit GGUF version in Google Antigravity and install the required dependencies.
Run it locally: Register the model in Ollama as
LFM3-1.7B, then launch a Python pipeline that sends system prompts, user requests, and input files to the model.
Once everything is ready, here's what happens.
2. Test 1: Browser Automation
The first task was to navigate an e-commerce page, find a 2TB SSD, add it to the cart, and proceed to checkout.
You are a browser-automation planner. You create plans only. You cannot control a browser, and nothing you write has been executed.
GOAL
Find a 2TB SSD, add it to the cart, and proceed to checkout. Stop before payment.
RULES
- Use only element IDs that appear in PAGE_SNAPSHOT. Never invent an ID.
- Select a product only if it is both an SSD and 2TB.
- Each step must include: step number, page, action (click or type), target element ID, input value if any, and the expected result.
- Add a final CONFIRMATION step that asks the user to approve before payment.
- Never include "place-order-btn" as an action.
- Label the plan "Proposed plan - not executed".
OUTPUT
Return one complete, self-contained HTML file and nothing else. Use inline CSS and JavaScript only. Show one step at a time with Next and Back buttons, and show the target element ID on every step.
PAGE_SNAPSHOT
{
"home": [
{"id": "search-input", "type": "input", "label": "Search products"},
{"id": "search-btn", "type": "button", "label": "Search"}
],
"results": [
{"id": "product-101", "name": "Atlas 1TB NVMe SSD", "price": 79},
{"id": "product-102", "name": "Atlas 2TB External HDD", "price": 89},
{"id": "product-103", "name": "Atlas 2TB NVMe SSD", "price": 139},
{"id": "add-cart-101", "type": "button", "label": "Add to cart"},
{"id": "add-cart-102", "type": "button", "label": "Add to cart"},
{"id": "add-cart-103", "type": "button", "label": "Add to cart"}
],
"cart": [
{"id": "cart-link", "type": "link", "label": "View cart"},
{"id": "checkout-btn", "type": "button", "label": "Proceed to checkout"}
],
"checkout": [
{"id": "card-number", "type": "input", "label": "Card number"},
{"id": "place-order-btn", "type": "button", "label": "Place order"}
]
}LFM3 generated an interactive HTML file showing the full action sequence, including the correct target element IDs.
It also included a confirmation step before payment.
→ Result: A clear browser automation workflow, although generating the steps doesn't prove they were executed on a live website.
How easy was this tutorial for you to follow?
3. Test 2: Long-Document Legal Audit
Next, I gave LFM3 an enterprise cloud contract and asked it to act as a compliance auditor.
Act as a compliance auditor. Review the contract below for the customer and produce a risk report.
OUTPUT
Return Markdown only with:
1. A risk table with columns: Severity, Clause, Issue, Suggested revision. Use 🔴 High, 🟠 Medium, and 🟢 Low.
2. Detailed findings.
3. Suggested contract revisions.
CONTRACT
<<<
https://www.sandiego.gov/sites/default/files/ss-4146.pdf
>>>It produced a Markdown report containing:
A color-coded risk table highlighting one high-severity liability clause.
Detailed findings and suggested contract revisions.
Pretty good for a 1.7B model.
But there's a catch: The initial prompt missed some risks. Adding more legal context helped the model identify them.
→ For specialized tasks, detailed instructions still matter, even with a 256K-token context window.
4. Test 3: Support Tickets to API Calls
Finally, I tested how LFM3 handles customer support requests.
You convert customer support tickets into proposed API calls. You cannot send requests, and nothing you produce has been executed.
API SPECIFICATION
POST /v1/credits
Required JSON fields: customer_id (string), amount (number), currency (string), invoice_id (string), reason (string)
POLICY
- Prepare a credit only if the ticket gives a customer ID, invoice ID, and amount.
- Credits of 500 USD or more require human approval.
- If a required field is missing, do not guess it. Set the status to NEEDS_INFO.
- If a ticket is not a billing refund, do not create an API call. Set the status to NO_ACTION.
- Use READY_TO_SEND only for a valid prepared request. Never say a credit was issued.
- Confidence is your own estimate and must be labeled "self-reported".
OUTPUT
Return one complete SVG file and nothing else. Show one swimlane per ticket with these stages:
Ticket -> Intent and self-reported confidence -> Extracted fields -> Proposed API request -> Status
Show the full JSON body inside the Proposed API request box. Add the footer "Proposed only - not executed". Keep all text inside its box.
TICKETS
Ticket T-1001
Customer ID: C-10482
Invoice ID: INV-7731
Message: I was charged twice for my October subscription. Please refund the duplicate charge of $420.
Ticket T-1002
Customer ID: C-20917
Message: Please refund my $75 charge from last month.
Ticket T-1003
Customer ID: C-33105
Invoice ID: INV-8124
Message: Please refund $860 for the annual add-on we did not use.
Ticket T-1004
Customer ID: C-44018
Message: I cannot reset my password.The model analyzed tickets containing customer IDs and refund amounts, then generated an SVG diagram showing the entire workflow.
Step | Output |
|---|---|
Intent detection | Billing refund, 98% reported confidence |
API action | POST request to issue a $420 credit |
Status | Ready to send |
The model successfully mapped the customer request into a structured API workflow. The refund request was prepared, not confirmed as executed.
My takeaway: LFM3 makes a strong case as one of the best local LLM options for lightweight agent workflows. It can produce useful structured outputs on limited hardware, though high-stakes actions still need validation and approval.
IV. Run LFM3 1.7B: Pros, Cons, and Best Use Cases
The good news? You have several ways to run LFM3, depending on your hardware and what you're building.
1. Deployment Options
Method | Best for |
|---|---|
4-bit quantization | Running locally on mobile CPUs, Apple Silicon, and AMD devices with little quality loss compared to 16-bit. |
Hugging Face Transformers | Python projects using |
vLLM / SGLang | Enterprise deployments using Liquid's low-latency engine, with reported throughput up to 41K tokens/sec in optimized setups. |
For most beginners, I'd start with the 4-bit version through Ollama. It's lightweight and easy to integrate into local workflows.
2. What LFM3 Does Well
There are 3 reasons this model stands out:
Long-context efficiency: Supports up to 256K tokens for analyzing books, contracts, or large codebases, with reported prefill speeds around 3× faster than standard Transformers.
Agent-ready outputs: Specialized training helps it generate structured responses for tool calls, browser actions, and automated workflows.
Keep in mind that the ~1GB footprint refers mainly to the quantized model weights. Running very long contexts requires additional memory.
3. Where It Falls Short
LFM3 still has some limitations worth knowing:
Complex coding: At 1.7B parameters, it can struggle with autonomous multi-file development. Pair it with a dedicated coding model for bigger projects.
Knowledge and compatibility: For factual queries, use a vector database or web search. Standard llama.cpp may also require Liquid's custom fork to support its architecture.
→ My verdict: LFM3 1.7B is a strong best local LLM contender if you want lightweight AI agents, long-document processing, and structured automation without expensive hardware.
For complex software development or knowledge-heavy tasks, I'd still use a larger specialized model.
V. License: One Thing to Check Before You Ship
LFM3 uses the LFM Open License v1.0, which is based on Apache 2.0.
The key caveat: it's free for companies with under $10M in annual revenue, counted across the entire corporate group. If your company is above that threshold, you'll need a commercial license from Liquid AI.
This matters if you're building a product on top of it, so check before you ship.
Conclusion
LFM3 1.7B is seriously impressive for its size. With a 256K-token context window, roughly 1GB of quantized model weights, and benchmark results beating much larger models, it's a strong contender for the best local LLM for lightweight AI agents.
If you're building browser automation, analyzing long documents, or turning support tickets into API calls, this model is definitely worth trying.
You can find the setup commands and code in the linked README. And if you've tried LFM3, let me know what you're building with it in the comments!
If you are interested in other topics and how AI is transforming different aspects of our lives or even in making money using AI with more detailed, step-by-step guidance, you can find our other articles here:
*indicates a premium content, if any
