Qwen4-Coder,
explained.

Rungs 1 to 4 use sparsity to build models that would otherwise be unaffordable to run — enormous capacity at tolerable cost per token, on a cluster. This rung uses the identical mechanism for the opposite purpose: to make a genuinely capable model fit on a single machine someone owns. Nothing about the architecture is new here; what is new is recognising which of the two numbers matters for which constraint.

The arithmetic is worth doing explicitly, because it is the whole argument. What has to fit in memory is the total parameter count times the bits per parameter, divided by eight for bytes — so total parameters set whether the model loads at all. What sets how fast tokens come out is the active parameter count, because decoding one token reads only the weights that token's routing selects, and single-token decode is limited by memory bandwidth rather than arithmetic. Total parameters buy capability and cost you capacity; active parameters cost you speed. A mixture of experts lets you choose them separately, and on a laptop the right choice is as much total as will fit and as little active as the task tolerates.

Stated in the ladder's units, as the page carries them: 32B total with about 3B active — the same decoupling shape as rung 3's 671B/37B, at a fiftieth of the size — released under Apache 2.0, and reportedly reaching 82% on SWE-Verified while running on a MacBook. If that number holds, the interesting quantity is not the score but the ratio: a coding benchmark result in the frontier range from a model that needs no cluster, no API and no network.

Qwen4-Coder is a mixture-of-experts, the coding-specialized successor to Qwen3: roughly 32B total parameters split across many experts, with a router that activates only about 3B per token — under 10%. Every token flows through the shared layers plus a handful of routed experts; the other experts sit dormant for that token.

That's the entire trick behind "a strong coder on a laptop." A dense 32B model would need 32B of everything — memory and compute — on every token. The MoE keeps the 32B of knowledge but pays roughly 3B of compute. To see why that fits a Mac, you have to separate two costs people usually lump together.

Running a model locally has two independent bills. Storage: every weight must live in memory, because the router might pick any expert on any token — so you hold all 32B. Speed: decoding is memory-bandwidth bound, and per token the hardware only reads the weights it actually uses — the active ~3B. A dense model ties these together; an MoE cuts the knot.

You buy the RAM for a 32B model and get the throughput of a 3B one. That asymmetry is the whole product.

Storage is just arithmetic: bytes = parameters × bits ÷ 8. In 4-bit, 32B parameters weigh about 16 GB of bare weights (nearer 18 GB once per-group scales are stored) — which still slides into a 24 GB Mac's unified memory with a little room for the KV cache and the OS. In 16-bit it would be 64 GB and wouldn't fit; quantization is what makes it a laptop model.

Fits ⟺ store ≤ VRAM/unified RAM. Speed is a separate line: bandwidth ÷ active-bytes, so it's the 3B — not the 32B — that sets tokens/sec.

SWE-Verified is the hard one: real GitHub issues where a patch counts only if it applies and turns the failing tests green without breaking the passing ones. Reaching ~82% on it is frontier-class agentic coding — and this page reports Qwen4-Coder as the first open, Mac-runnable model to clear 80% there (it cites no primary source, so treat that as a claim to verify).

The significance isn't the two-point benchmark bump; it's where the capability now lives. A genuinely useful coding agent that runs offline, with open weights and an Apache-2.0 licence, changes who can build with it and under what constraints — no per-token API meter, no data leaving the machine.

Qwen4-Coder is the clearest proof yet that the sparse-MoE recipe has made local-first coding agents real. The playbook it validates is exactly the one in the local LLM stack and on-device AI handbooks: pick an MoE so RAM sizing and speed decouple, quantize to fit, and you get a capable model without a data center.

It also sharpens a mental model worth keeping: for any local model, compute the two numbers separately. Total × bits ÷ 8 tells you if it loads; active params vs your bandwidth tells you if it's usable. Dense models make those two move together; every strong on-device release from here will be an MoE precisely to pull them apart.

This page has no primary source, and the release details a reader would want, such as layer and expert counts, the attention design, context length, training data and the agentic training recipe, are not given here, so this section does not invent them. What can be described exactly is the procedure any sparse mixture-of-experts model of this shape goes through on a single machine, using the page's figures of 32B total and about 3B active parameters.

1. Quantize the weights. A 4-bit format stores each weight as a 4-bit integer plus a shared scale, and often an offset, for each small group of weights. With groups of 64 and two 16-bit values per group, the real cost is 4.5 bits per weight, so 32B parameters take about 18 GB rather than the 16 GB of the bare 4-bit arithmetic. Many formats also keep the embeddings and other sensitive layers at higher precision.
2. Load everything. All experts must be resident, because the router can pick any of them for any token at any layer. Total parameters decide whether the model loads at all.
3. Prefill the prompt. A coding agent's prompt holds instructions, tool output, file contents and diffs, often tens of thousands of tokens. Prefill processes all of them in parallel through every layer, filling the KV cache. This phase is limited by arithmetic, roughly 2 FLOPs per active parameter per token plus attention, so on a laptop a long prompt can take many seconds before the first output token appears.
4. Decode one token at a time. For each new token, every layer runs attention over the KV cache, then its router picks a few experts and only their weights are read. Decoding a single sequence does little arithmetic per byte read, so speed is set by memory bandwidth: the bytes read per token are about active parameters × bits ÷ 8, plus the KV cache for the whole context.
5. Keep the KV cache in budget. The cache grows linearly with context: per token, 2 × layers × key-value heads × head size × bytes per value. Sparsity in the experts does nothing to shrink it, so at long context it competes with the weights for the same memory and adds to every decode step's reads.
6. Run the agent loop. For benchmarks like SWE-bench Verified the model sits inside a scaffold that reads the repository, proposes edits, runs commands and tests, and feeds the results back as new prompt tokens, repeating until it submits a patch. Every turn is another prefill and decode, so total time depends on both phases.
7. Score the patch. The benchmark applies the final patch to the repository and runs the issue's tests. The task counts as resolved only if the previously failing tests now pass and the previously passing tests still pass.

Steps 3 and 4 are why "fast on a laptop" needs two numbers: prompt-processing speed, which scales with compute and active parameters, and generation speed, which scales with bandwidth and the bytes read per token.

• Ntotal = 32B, Nactive ≈ 3B — the page's figures; b — bits per weight; g — the quantization group size, with two 16-bit values (a scale and an offset) per group, so 4-bit at g = 64 gives b_eff = 4.5.
• MKV(L) — the key-value cache for L tokens: keys and values (the 2), for every layer, key-value head and head dimension, at B_kv bytes per value.
• Mother — runtime buffers, activations and everything else on the machine.
• BW — memory bandwidth in bytes per second. The bound assumes every needed byte is read once per token, so real speeds land below it.

At the extremes: at short context M_KV ≈ 0, and speed is set by the active weights alone. As L grows, the KV term grows without limit, and at long enough context it, not the experts, dominates both memory and speed. A dense 32B model has N_active = N_total, so the same bandwidth buys about a tenth of the speed.

The page cites no primary source, so the model-specific figures below are claims to verify, not measured results.

The benchmark itself is well documented. SWE-bench (Jimenez and colleagues, 2024) collected 2,294 real GitHub issues from 12 popular Python repositories. SWE-bench Verified is a 500-task subset that OpenAI had human annotators screen in 2024 for well-specified issues and fair tests. An 82% score means about 410 of those 500 issues resolved.

What the claim has to survive

Scores on agentic benchmarks move with the scaffold: the tools offered, the turn limit and the number of attempts allowed. Two numbers on the same benchmark are often not comparable. The tasks come from public repositories that predate recent training corpora, so a model trained on a large code crawl cannot easily be shown not to have seen the fixes. And a score produced at full precision does not predict the quantized copy a laptop runs: lower precision generally costs some quality, with losses usually small at 8 bits and larger and more model-dependent at 4 bits and below, so a 4-bit result has to be measured rather than assumed.

The benchmark figure is vendor-reported and should be treated as such. Two specific cautions apply to this class of claim rather than to this model in particular. First, agentic coding benchmarks are scored by running tests in a harness, and results are sensitive to the scaffold — the retrieval, the retry policy, the number of attempts — so two reported numbers on the same benchmark are frequently not measuring the same thing. Second, benchmarks drawn from public repositories carry a standing contamination risk, and a model trained on a large code corpus cannot easily be shown not to have seen the fixes.

There is also a cost that the headline hides: running locally in practice means running quantised, and quantisation is not free. The memory arithmetic above is exactly what makes that trade visible — fewer bits per parameter is how a large total fits, and quality is what is spent to get there. A published score at full precision is not a prediction of what a reader will experience at four bits.

What would settle it: independent evaluation on held-out tasks under a disclosed scaffold, and quality measurements at the quantisation levels people actually deploy rather than at the precision the score was produced with. Whatever those show, the structural point on this rung stands on its own and does not depend on the number — sparsity is a dial between storage and speed, and pointing it at consumer hardware is a use nobody had in mind when rung 1 was written.

Work each one out before you open it — a number, a prediction or a reason, not a definition. Producing the answer is what makes it stick. Your progress is kept on this device.

Sparsity: route each token to a few experts and buy parameter count without paying for it at inference. 2017 idea, 2026 frontier default.

1. 1Mixture of Experts2017
2. 2Switch Transformer2022
3. 3DeepSeek-V32024
4. 4DeepSeek-V42026
5. 5Qwen4-Coder2026

All 110 papers, in 19 ladders →