LFM3 on an M-series Mac: what 256K context in 1 GB really buys an on-device agent

Liquid AI shipped LFM3-1.7B, a 1.73B parameter model with a 256K token context that fits in about 1 GB at 4-bit, which on paper is a private agent reading a whole project on a MacBook Air without touching an API. Two things decide whether you can build on it: at 128K it gets about a third of the RULER long-context cases wrong, and once you or your client's group reaches $10M in annual revenue, the license no longer covers commercial use. The architecture mostly backs the promise up; those two are where it gets thinner.

What Liquid actually shipped

Liquid announced the LFM3 family on 27 October, so the model is a week old, even if it only now tops the trending lists. The text model is LFM3-1.7B; the any-to-any sibling is LFM3-Omni-2B, which takes text, images, video and audio and can answer in speech. One detail the launch coverage glosses over: the Omni card lists a 32K context, not 256K. The long window belongs to the text model only.

The tri-hybrid label describes the layer mix. LFM3-1.7B has 24 layers: 13 gated short convolutions with kernel size 7, 5 sliding-window attention layers with a 256-token window, and 6 global attention layers. Only those six global layers keep a KV cache that grows with the prompt. The convolutions carry a fixed state and the sliding-window layers stop at 256 tokens. That is the whole trick behind long context at small memory.

Liquid's own figure: at a full 128K context the KV cache takes 1.6 GB, against 4.3 GB for Qwen3.5-4B and 5.6 GB for MiniCPM5-2B. Going to 256K roughly doubles the global-layer cache, so my estimate is about 3.2 GB of cache plus about 1 GB of 4-bit weights. Call it under 5 GB with runtime overhead. That fits on a 16 GB M-series machine with room left for the IDE and a browser, which is the real requirement for a laptop agent.

What a 256K agent can really do on M-series

Fitting in memory is the easy half. Reading 256K tokens is the other half, and prefill on Apple silicon is compute-bound. Liquid publishes only relative speed: at 32K context in llama.cpp with Q4_0, prefill is at least 2.5x and decode at least 1.8x faster than the models they compared, across three devices. There is no absolute tokens per second figure, and I have not timed a full 256K prefill myself, so treat any "instant" claim as unproven. Expect a cold read of a large repository to cost a real wait, then quick follow-up turns if your runtime keeps the cache warm.

Then there is recall. The model card reports RULER at 128K of 65.56. That score is out of 100, so roughly a third of the long-context retrieval and tracing cases go wrong at half the advertised window. I would not trust it to find the one config line buried in 200K tokens of logs. I would trust it to summarize, classify and route.

A 256K window you can fit is only useful if the model can still find things in it, and at 128K this one misses about a third of the time.

The card is also honest about scope. It says the model is "not recommended for agentic coding or complex multi-step reasoning due to its small size", and that turning off the thinking traces can behave inconsistently. Tool calling is the strong suit: BFCL V4 at 71.39 and IFEval at 96.66, with post-training aimed at the Hermes Agent, Pi and OpenClaw harnesses. So the realistic on-device agent is a local front desk. It reads a long mailbox export, a meeting transcript or a contract, extracts structure, calls tools, and hands anything hard to a bigger model. That is a useful job, and keeping the raw data on the laptop is the part clients actually pay for.

Getting it running is the easy part: the card lists an MLX 4-bit build, GGUF for llama.cpp, Ollama and LM Studio, and ONNX. Picking the runtime is where a long-context agent wins or loses time. When I measured MLX against llama.cpp on a plain transformer, the faster choice flipped at roughly 40K tokens. A hybrid with only six layers whose cache grows may move that boundary, so if your agent will live past 40K, time both runtimes on your own prompt before you commit.

Where the LFM license bites

This is the clause that decides who ships it. The weights come under the LFM Open License v1.0, tagged lfm1.0 on Hugging Face, and the grant reads almost like Apache 2.0 until Section 5: commercial use is not licensed for you or your Legal Entity once annual revenue reaches $10,000,000. Legal Entity covers anything that controls you, that you control, or that shares common control with you, with a 50 percent ownership test. So a five-person subsidiary of a large group is over the threshold on day one, before it has invoiced a single customer.

There is a carve-out for qualified non-profits doing non-commercial or research work, and the usual duties apply: ship the license, mark modified files, keep the notices. Nothing in the text explains how revenue is measured, which is exactly the question a procurement lawyer will ask. For a solo developer or a small agency the model is effectively free. For anyone selling into enterprises, the model you prototype on may be one your client is not allowed to run in production. My license checklist exists for this case, and LFM3 goes straight into the "ask legal before the demo" column.

My recommendation: pull the MLX 4-bit build, run one of your own long-document tasks at 32K, 128K and 256K, and score retrieval accuracy at each length before you design anything around the 256K number. If you or your client crosses $10M in annual revenue, get written commercial terms from Liquid before the first demo.