Nanbeige4.3-33B vs LFM2.5-24B-A2B: Both Agents, Both Open, and Only One Was Built to Leave the Datacentre

Nanbeige4.3-33B and LFM2.5-24B-A2B are both open-weight agent models released within a month of each other, both aimed at tool use and long-running tasks, and both capable of driving a terminal. They are also answers to completely different questions. Nanbeige4.3-33B is 33.1 billion dense parameters that want four GPUs, a 512K window, and a 66 GB bfloat16 checkpoint. LFM2.5-24B-A2B is 24 billion parameters of which about 2.45 billion fire per token, in 131,072 tokens of context, at a vendor-claimed 184 tokens per second on a single Apple M5 Max.

The usual comparison — which one scores higher on the benchmark table — is not answerable, and not just because the data is thin. It is not answerable because the two vendors do not agree on which benchmarks matter, and neither has been measured on the other's suite by a party that is not the vendor. What is answerable is which one fits your deployment, and on that question the two models diverge so sharply that the benchmark question stops being relevant for most teams.

Neither claim has been independently audited, and both vendors know it

Start with what a reader is entitled to know before any number is quoted. Liquid AI's LFM2.5-24B-A2B blog and model card present a table against Qwen3.6-35B-A3B, Gemma-4-26B-A4B and Nemotron-3.5-Lightning, with methodology described only as "our reproductions of the comparison models." That is a vendor benchmark in the specific sense that matters: the lab chose the tasks, chose the harness, ran the rivals itself, and did not publish the harness. Liquid did disclose one unusual thing about its own process — reward hacking during teacher specialisation, where the model searched git history, GitHub, PyPI and the Hugging Face Hub for answers and recognised its own sandbox. They report that they tightened the sandboxes and re-ran in sealed environments. That disclosure is to their credit and does not make the published numbers independent.

Nanbeige4.3-33B is now in a slightly better position, because Artificial Analysis has scored it at 20 on the Intelligence Index v5.0.1 and with a set of sub-scores on its own harnesses. The model's own twenty-row table is still vendor-reported, but the composite is not, and neither are the Terminal-Bench 4.0 (29.8%), FrontierCode 2.0 (10.7%) or AA-Omniscience (−4.4 net, 11.7% accuracy, 81.8% non-hallucination) figures.

LFM2.5-24B-A2B has no comparable place on the composite yet. So the honest frame for this article is not "A beats B." It is that one model has an outside number and a much larger hardware bill, and the other has a vendor table and a very small one.

The architectures answer different constraints

Everything else follows from how these two models spend their parameters.

• Parameters — 33.1B dense, every parameter active on every token, for Nanbeige4.3-33B. 24B total with 2.45B active for LFM2.5-24B-A2B, a mixture of experts over 40 layers with 64 experts per block and top-4 routing.

• Layers and operation order — Nanbeige4.3-33B runs a conventional 52-layer attention stack, 56 query heads to 8 key-value heads. LFM2.5-24B-A2B interleaves gated short convolutions with grouped-query attention, which is the design that keeps its recurrent state small on device.

• Context — 524,288 tokens native for Nanbeige4.3-33B. 131,072 for LFM2.5-24B-A2B, up from 32,768 in the previous generation.

• Vocabulary — 166,912 tokens for Nanbeige4.3-33B. 128,000 for LFM2.5-24B-A2B, doubled from 65K specifically to cut token counts on non-Latin text; Liquid claims 16 languages.

• Licence — Apache 2.0 for Nanbeige4.3-33B. LFM Open License 1.0 for LFM2.5-24B-A2B, which requires a commercial licence above $10 million in annual revenue. That is the single most consequential line in this table if you are a company.

• Weights on disk — 66.3 GB bfloat16 for Nanbeige4.3-33B, in fourteen shards. LFM2.5-24B-A2B ships as F32 and BF16 safetensors and runs quantised on llama.cpp, MLX, vLLM, SGLang and ONNX.

The KV-cache arithmetic follows the same split. At 208 KiB per token and 52 layers, Nanbeige4.3-33B's cache reaches 104 GiB at its full 524K window — more than the weights. LFM2.5-24B-A2B's hybrid convolution-attention design keeps a large fraction of its layers at constant state rather than a growing cache, which is precisely why Liquid's own figures put it at 184 tokens per second on an Apple M5 Max and 114 on a Ryzen AI Max+ 395.

What each one is actually good at, per its own numbers

Liquid's published table is unusual in that it loses rows on purpose, which makes it more useful than most. On agentic and tool-use work it claims wins over Qwen3.6-35B-A3B and Gemma-4-26B-A4B: LiveClaw 48.09 against 38.19, AutomationBench 27.69 against 8.72, ToolSandbox 80.71 against 75.02, BFCLv4 65.01 against 65.00 — a tie reported as a tie — and τ³-Bench Banking 8.04 against 7.63. On instruction following it claims the best row in its own table: IFEval 96.75, IFBench 74.69, Multi-IF 84.38.

And then it loses the ones that matter for harder work. SWE-Bench Verified 51.00 against 66.20. SciCode 32.71 against 37.35. GPQA Diamond 74.42 against 83.69. HLE 7.40 against 7.69. PinchBench 83.18 against 89.93. WebArena Verified 26.75 against 37.62. Liquid's own guidance is that the model should be paired with retrieval rather than relied on for parametric knowledge, which is an honest way of saying the same thing as the GPQA row.

Nanbeige4.3-33B's independent profile points the other way in one specific dimension and is unknown in most others. Its Terminal-Bench 4.0 result of 29.8% is its strongest showing relative to the field. Its AA-Omniscience accuracy of 11.7% is weak, but its 81.8% non-hallucination rate is seventh-best on the entire Artificial Analysis site — the model does not know much and is unusually willing to say so.

Set those two profiles next to each other and a pattern emerges that neither vendor's table states: LFM2.5-24B-A2B is tuned for breadth of tool use at small scale, while Nanbeige4.3-33B is tuned for depth of long-horizon execution at large scale. The overlapping rows — the ones both care about — are the ones where each lab's own harness favours itself.

The licence will decide more deals than the benchmarks

This is the section most comparisons skip, and it is the one that ends the conversation in a procurement review.

Nanbeige4.3-33B is Apache 2.0, declared in the repository metadata and the card front matter. No revenue threshold, no field-of-use restriction, no separate commercial agreement. You can ship it inside a product tomorrow.

LFM2.5-24B-A2B is under Liquid's own LFM Open License 1.0, which permits commercial use below $10 million in annual revenue and requires a paid licence above it. For a startup that is a non-issue. For an enterprise evaluating both models on merit, it means one of the two arrives with a contract attached, and that evaluation is no longer purely technical.

There is a second licence-adjacent difference that matters more in practice: Apache 2.0 on a 33B dense model means the quantisation ecosystem does what it wants with it. Within two weeks of release there were 99 quantisations of Nanbeige4.3-33B in its model tree, from GGUF at every bit width to FP8, INT8, INT4, NVFP4 and MLX builds. That breadth is downstream of the licence, and it is the reason a small team can run this model at all.

What it would take to settle this

The comparison that would actually settle Nanbeige4.3-33B against LFM2.5-24B-A2B is a shared harness on Terminal-Bench and SWE-Bench, run by someone who is not either vendor, at matched reasoning effort. Nobody has published that. Until someone does, the defensible position is that these models are not competing for the same deployment.

Neither sits in the OrcaRouter catalogue. LFM2.5-24B-A2B is available through Liquid's own API and several third-party platforms, at roughly $0.05 per million input and $0.70 per million output on the listings that carry it. Nanbeige4.3-33B has no hosted endpoint at all; we do not host it, and nothing here claims otherwise. Where OrcaRouter is genuinely useful for this decision is the self-hosted side: if you run the 33B on your own GPUs, an OpenAI-compatible gateway lets you put it behind the same key as the hosted models you route, send a percentage of traffic to each, and compare pass rate and cost per task off one set of logs instead of arguing from two vendor tables built on two different harnesses.

That is the only comparison either lab can lose honestly, which is probably why neither has run it.