LFM3-1.7B vs Granite 4.2 30B: Two Agent Models That Split the Verdict by Axis

Put LFM3-1.7B and Granite 4.2 30B on the same page and the aggregate averages point in opposite directions depending on which row you read. On Berkeley Function Calling Leaderboard V4, Liquid AI's 1.73-billion-parameter model scores 71.39 against IBM's 61.39 — a ten-point win for a model roughly seventeen times smaller. On SWE-bench Verified, Granite scores 57.00 against LFM3-1.7B's 43.40, a 13.6-point win in the other direction. Routing does not add a margin to a provider's list price. Provider list prices pass through at 0% markup.

Both models are built for agents, both were released within two months of each other in 2026, and both vendors publish enough overlapping benchmarks that a real comparison is possible rather than a collage. That makes this the rare matchup where the interesting question is not which model is better but which axis your workload actually lives on. Very few tasks need both a 71 BFCL score and a 57 SWE-bench score, and the ones that do are not served well by either model alone.

The two numbers that cross

Granite 4.2 30B shipped on August 25, 2026 under Apache 2.0, a dense ~30B model built on the Granite 4.1 30B base and trained on roughly 15 trillion tokens. IBM's framing is enterprise: three configurable thinking modes, native tool calling against the OpenAI schema, twelve tested languages, and a three-stage training pipeline ending in multi-phase GRPO reinforcement learning.

LFM3-1.7B arrived two months later, announced on October 27, 2026, post-trained specifically on agentic harnesses — Liquid names Hermes Agent, PI and OpenClaw in the model card. It is a 1.73B dense model with a 256K context, and it is explicitly positioned for local agents and tool calling rather than general reasoning.

The benchmark crossing is not an accident of one weak number. LFM3-1.7B's entire published table leans agentic: 71.39 BFCL V4, 80.36 ToolSandbox, 68.01 τ³-bench, 45.60 LiveClaw, 38.42 WebArena-Verified. Granite's table leans engineering: 57.00 SWE-bench Verified, 33.29 SWE-bench Pro, 41.89 SWE-bench Multilingual, 38.76 SciCode, 29.24 on TerminalBench 2.1. Each vendor optimised for a different definition of "agent," and the benchmark tables are honest about which.

τ³ at 68.01 against 68.05 is the real headline

Buried under the two dramatic gaps is a dead heat. On τ³-bench, the tool-use evaluation that measures multi-turn task completion with user simulators and domain policies, LFM3-1.7B scores 68.01 and Granite 4.2 30B scores 68.05 — a difference of four hundredths of a point, which is indistinguishable from noise.

That is a more interesting result than either of the big gaps, because τ³ is the benchmark closest to what most agent deployments actually do: hold a conversation, follow a policy, call the right function, recover from a mistake. If a 1.73B model ties a 30B dense model there, the parameter count is buying something other than competent multi-turn tool use.

What it buys shows up in BFCL and SWE-bench, which measure different things. BFCL V4 tests single-turn function-call correctness against a schema — LFM3-1.7B's 71.39 suggests Liquid's post-training on real agent harnesses paid off directly. SWE-bench Verified tests repairing a real GitHub issue end to end, which requires holding a repository in context, planning across files, and producing a patch that passes tests — Granite's 57.00 reflects a model with the capacity to do that and a training set built for it.

So the split is legible. Small model, well-trained on tool schemas: wins the function-call test. Large model, trained on code repair: wins the repository test. Tied on the multi-turn middle ground where both were specifically trained.

Context is where the specs diverge hardest

• Context — 262,144 tokens for LFM3-1.7B; 128K native for Granite 4.2 30B, extensible to 512K. The extension is not free, and IBM is honest that it is an extension rather than a native window.

• Long-context retention — 65.56 on RULER at 128K for LFM3-1.7B against 81.4 for Granite 4.2 30B on the same benchmark family. The larger model holds more of a long document, which is the opposite of what the headline context numbers suggest.

• Footprint — about 1 GB at 4-bit against roughly 30B of BF16 weights, with official FP8, NVFP4 and MXFP4 builds. This is a single-GPU model, not a laptop model.

• Languages — sixteen for LFM3-1.7B against twelve tested for Granite, with a different overlap. Granite's twelve include Czech and Dutch; Liquid's include Thai, Vietnamese and Indonesian.

• Thinking modes — Granite 4.2 30B ships full, low-effort and no-thinking modes. LFM3-1.7B has no such surface, and its card says it is not intended for complex multi-step reasoning in the first place.

• License — Apache 2.0 for Granite against the LFM Open License v1.0, which is free below $10 million in annual revenue and requires a commercial license above it.

What 30B dense costs that 1.73B does not

Granite 4.2 30B is dense, which means all thirty billion parameters run on every token. There is no active-parameter discount here: the compute cost per token is roughly seventeen times the small model's, and the memory cost is the full weight file. IBM ships quantisations to make that tractable, but there is no configuration in which it runs on a phone.

LFM3-1.7B's advantage is not primarily speed. It is that the model fits in the same memory budget as the rest of your application. A 1 GB model leaves room for a document store, a cache, and a second model on the same device — which is what makes a local agent possible rather than merely theoretically local. Liquid reports 1.8 to 2.8 times faster decoding than its predecessors on tested hardware and a 1.6 GB KV cache at 128K, both of which matter for an on-device agent holding a long conversation.

The counterweight is that Granite's 30B capacity is doing real work in the SWE-bench numbers. If your agent's job is to change code across a repository, the 13.6-point gap is not something a smaller model recovers through prompting, and the compute savings buy you a worse outcome.

Licensing, signing, and the procurement question

Apache 2.0 is the reason a large organisation can adopt Granite 4.2 30B without a legal review. There is no revenue threshold, no commercial trigger, no negotiation. IBM has also been cryptographically signing released Granite models since April 2026, which sounds like a detail until you are the person who has to prove that the weights in production are the weights that were vetted.

Liquid's LFM Open License v1.0 is genuinely permissive at startup scale — free for commercial use below $10 million in annual revenue — but above that line it requires a paid commercial license. For an individual developer or a small team, this is a non-issue. For a business unit inside a larger company, it is a conversation that starts before the first deployment and may not finish quickly. That asymmetry is not reflected in any benchmark and often decides the question on its own.

Running both without betting on either

The practical pattern for a team evaluating these two is not to pick one first. Both are open-weight and both are unproven by independent evaluators, which means the only benchmark that matters is your own. Route the candidate models through a single endpoint, run the same agent traces through both, and compare on your task rather than on BFCL or SWE-bench.

OrcaRouter is useful here less as a host than as a control surface: one key and one bill across more than 200 models, provider list prices passed through at 0% markup, and automatic failover so an evaluation run does not die because one provider had a bad hour. Neither LFM3-1.7B nor Granite 4.2 30B is on our catalogue today — both are open-weight downloads, and self-hosting is the path for each. Where routing earns its place is the surrounding stack: the frontier model your agent escalates to, or the second opinion you compare against when the local model's patch fails its tests.

Who should take which

Take LFM3-1.7B if the agent runs on the user's device, if the work is tool calling and structured extraction against an API, and if a 256K context with a 1 GB footprint is the thing that makes the product possible. Accept the vendor's own warning that it is not for agentic coding, and keep a larger model behind it for the cases that need one.

Take Granite 4.2 30B if the agent touches a codebase, if you need Apache 2.0 and signed weights for procurement, if the workload benefits from configurable thinking effort, and if you have a GPU to serve it from. The BFCL deficit is real but narrow: it measures schema correctness on a single call, and a 30B model with a well-designed tool schema closes much of that gap in practice.

Take the split if you are building the thing both vendors are aiming at — a local agent that handles routine tool calls in a gigabyte and escalates repository-scale work to a server. That architecture uses each model where its own benchmark table says it is strong, and it is the only arrangement in which the crossed axes stop being a problem.

The question worth watching is whether Liquid's agentic post-training recipe transfers to a larger checkpoint. If a future LFM model keeps the 71.39-class BFCL behaviour and adds capacity for repository work, the axis split collapses and this comparison becomes a straightforward size decision. Until then, the two models are not competing for the same job — they are the two halves of one.