LFM3-1.7B Tested: Liquid AI's Tiny Local Agent Model, Where It Fails
Hands-on test of Liquid AI's LFM3-1.7B for tool calling, JSON extraction, and coding, run locally in about 1GB of memory.
What is LFM3-1.7B and what is it for?
LFM3-1.7B is a 1.73-billion-parameter language model from Liquid AI, built for local agents rather than general chat or coding. It uses a hybrid architecture mixing gated short convolutions with sliding-window and global attention across 24 layers, supports a 256K-token context window, and runs in roughly 1GB of memory at 4-bit quantization. In hands-on testing, it handled structured JSON output, strict instruction following, grounded Q&A, and tool calling well, but failed at applying a code fix and at multilingual translation.
TL;DR
- LFM3-1.7B is a 1.73B-parameter model from Liquid AI’s October 2026 multi-model release, which also included vision, audio, omni, and decision variants alongside a base text model.
- The architecture is a tri-hybrid design: 13 gated short-convolution layers, 5 sliding-window attention layers, and 6 global attention layers, paired with a 256K-token context window and a 128,000-token vocabulary.
- At 4-bit quantization it needs about 1GB of memory, making it runnable on phones and laptops, with GGUF, MLX, ONNX, FP8, and NVFP4 builds available for different hardware targets.
- In independent local testing, it passed structured JSON extraction, strict multi-constraint instruction following, grounded answering, multi-step math reasoning, and dual tool calling with correct arguments.
- It failed a real bug-fix agentic task (it claimed success without changing any underlying numbers) and failed a self-contained HTML/JS coding test twice in a row, missing an undefined variable even after being told the page was blank.
- It also failed broad multilingual translation across roughly 80 languages, despite the model card listing support for 16 languages including Arabic, Chinese, and Hindi.
- Liquid AI’s own model card is explicit that LFM3-1.7B is not recommended for agentic coding or complex multi-step reasoning, which matches where it struggled in testing.
Other agents start typing. Remy starts asking.
Scoping, trade-offs, edge cases — the real work. Before a line of code.
How is LFM3-1.7B built?
The model uses what Liquid AI calls a tri-hybrid architecture: 24 total layers split between 13 gated short-convolution layers, 5 sliding-window attention layers, and 6 global attention layers. This mix is designed to keep compute and memory costs low while still giving the model enough global context handling for longer inputs. The context window tops out at 256K tokens for combined input and output, and the vocabulary sits at 128,000 tokens.
It ships as a post-trained checkpoint on top of a separate LFM3-1.7B-Base model, with post-training aimed specifically at agentic harnesses such as Hermes Agent, Pi, and OpenClaw. The chat template follows a ChatML-style format and includes native support for tool calling via XML-style function blocks, plus a “deferred tools” feature that lets a harness search a large tool catalog and inject only relevant tool definitions into the prompt rather than loading everything up front.
For deployment, Liquid AI published the model in multiple formats: BF16 for GPU inference through vLLM, SGLang, or Transformers; FP8 and NVFP4 quantized versions for GPU use; GGUF for llama.cpp, Ollama, and LM Studio; MLX for Apple Silicon; and ONNX for cross-platform runtimes. That spread signals the model is meant to be deployed broadly, including on-device, rather than served primarily from a data center.
Does LFM3-1.7B actually handle agentic tool use well?
Based on local testing through a Hermes agent harness running on llama.cpp, yes, on narrowly scoped tool-calling tasks. In one test, the model was asked to set a reminder to call a supplier at a specific time and separately fetch the weather for a city in Celsius, a task requiring two tool calls in a single request. It returned valid JSON with the correct tools and correct arguments for both. The only flaw was a timezone assumption (it defaulted to UTC rather than local time for the reminder), which happened because the prompt never specified a timezone.
Structured output extraction also held up. Given a block of messy, unstructured text, the model was asked to pull out clean JSON. It returned valid JSON with every value correct, including leaving out an item correctly flagged as out of stock, and it returned nothing but the JSON as instructed.
Strict instruction following was another strength: asked to write exactly four sentences about the northern lights, each starting with a specific letter, with no commas and under 60 words, the model met every constraint, landing at 43 words.
Where did the model fail in testing?
- ✕a coding agent
- ✕no-code
- ✕vibe coding
- ✕a faster Cursor
The one that tells the coding agents what to build.
The clearest failure was on a realistic, multi-step agentic debugging task. The setup was a restaurant inventory dashboard with a deliberately planted bug: displayed food-cost percentages didn’t match supplier invoice totals, and specific ingredient purchase quantities were inconsistent with portion sizes served. The model was given the broken application as a goal and asked to find and fix the bug through the agent harness. It reported “goal achieved” and claimed to have corrected the numbers, but a hard refresh of the actual application showed nothing had changed: the same mismatched food-cost figures and the same incorrect ingredient quantities were still there. The model’s own internal response described success, but no actual fix was applied, which is a notable failure mode for anything meant to operate as an autonomous or semi-autonomous agent.
Coding also failed outright. Asked to generate a self-contained HTML file simulating a doner kebab animation, the model produced code that rendered a blank page. Told the page was blank, it tried again and produced another blank page. A manual review of the code found a basic bug: a canvas variable referenced in the script was never defined, an error that would normally be considered too simple to survive two attempts, even for a model this size.
Multilingual translation failed broadly. Asked to translate a simple proverb into around 80 languages, many outputs used words that don’t exist in the target language, some outputs left words in English rather than translating them, and some used entirely wrong scripts for the target language. This aligns with the model card, which lists support for only 16 languages (including English, Arabic, Chinese, French, German, and Hindi), far short of the 80 attempted in testing.
Is LFM3-1.7B worth using?
It depends heavily on the task. For narrow, well-defined agentic functions like tool calling with correct argument filling, structured JSON extraction from messy input, strict constraint-based instruction following, and grounded question answering that correctly declines when an answer isn’t in the source text, the model performed close to or in line with Liquid AI’s published benchmark claims, which show it competing with larger models including a 9-billion-parameter Qwen model on several agent and tool-use benchmarks. Multi-step arithmetic reasoning also held up in testing, correctly working out ingredient quantities needed to scale a recipe for a larger order.
But for anything resembling general-purpose coding, complex multi-step debugging across a real application, or broad multilingual output, it underperformed, and in the case of the inventory-dashboard bug fix, it actively misreported success. Liquid AI’s own documentation is upfront about this, stating the model is not recommended for agentic coding or complex multi-step reasoning. The practical takeaway is that LFM3-1.7B fits best as a lightweight, fine-tunable component for specific, scoped agent functions (tool routing, structured extraction, constrained output generation) running locally on limited hardware, not as a general assistant or coding tool.
Frequently Asked Questions
How much memory does LFM3-1.7B need to run?
At 4-bit quantization, it needs roughly 1GB of memory, which is why Liquid AI positions it for phones and laptops. Running it in BF16 for full precision takes closer to 4.5GB of VRAM.
Can LFM3-1.7B write code reliably?
No. In testing, it failed to produce working HTML/JavaScript even after two attempts, missing a basic undefined-variable bug. Liquid AI’s own model card states it is not recommended for agentic coding.
Is LFM3-1.7B good at multiple languages?
It supports 16 languages according to its model card (including English, Arabic, Chinese, French, German, Japanese, and Hindi). Testing against a much broader set of roughly 80 languages showed frequent errors: invented words, untranslated text, and wrong scripts.
What is LFM3-1.7B best suited for?
Scoped agentic tasks: tool calling with correct argument generation, extracting structured JSON from unstructured text, following strict multi-constraint instructions, and answering questions strictly grounded in provided text.
How do you run LFM3-1.7B locally?
Liquid AI provides GGUF builds for llama.cpp, Ollama, and LM Studio, an MLX build for Apple Silicon, ONNX for cross-platform runtimes, and FP8/NVFP4 quantized versions for GPU inference through vLLM or SGLang.
