Q4_K_M was 184 MB too big. The next quant down wasn't.

Bartowski's default Q4_K_M build of Nanbeige4.2-3B is 2.68 GB — 184 MB over our own 2.5 GB phone-download cap. The IQ4_XS build of the exact same model, from the exact same repo, is 2.44 GB. That 240 MB gap between two quants of one model is why our catalog grew today for the first time since July 27.

The gate that almost said no

Nanbeige4.2-3B landed on Hugging Face about five days ago: 4B total parameters (3B non-embedding), Apache-2.0, chat-tuned with a template built for reasoning and tool-use. Its architecture, a "looped transformer" with weight-tied recurrent layers, is new enough that llama.cpp only just picked it up. We didn't stop at checking whether LLM_ARCH_NANBEIGE exists in the current tag's enum — that check alone burned us before. We confirmed there's a real graph-building class behind it:

$ curl -s https://raw.githubusercontent.com/ggml-org/llama.cpp/b10216/src/llama-model.cpp | grep -i nanbeige
        case LLM_ARCH_NANBEIGE:
            return new llama_model_nanbeige(params);

That's the engine gate cleared. The size gate almost wasn't. bartowski's repo ships 23 quant variants of this model; walking down from the default, Q4_K_M (2.68 GB), Q4_K_S (2.55 GB), IQ4_NL (2.55 GB), and Q4_0 (2.54 GB) all miss our cap. IQ4_XS, at 2.44 GB, is the first one that clears it — verified with a direct HEAD request, not a guess: content-length: 2441753760. It's in the catalog now as nanbeige4.2-3b-q4, honestly labeled as IQ4_XS rather than the Q4_K_M our other entries use, since it isn't the same quant.

Ten releases, one architecture that mattered for phones

llama.cpp tagged ten releases on July 31 alone — b10207 through b10216, one every 30 to 75 minutes, the last one at 22:04 UTC. Since our July 27 check (171 LLM_ARCH_* entries at tag b10142, which already included Laguna support), the engine picked up more: Hy3 (Tencent's 295B MoE), MiniMax M3, and Nanbeige. Only Nanbeige is phone-sized. The others need a multi-GPU rig regardless of quant.

Worth a caveat on MiniMax M3 specifically, since "the architecture is recognized" keeps turning out to mean different things: multiple sources report llama.cpp doesn't yet implement MiniMax's own Sparse Attention for it and falls back to dense attention instead. The engine loads the model; it doesn't yet run it the way the vendor intended. Not our catalog's problem today — M3 is nowhere near phone-sized — but it's the same "recognized ≠ fully supported" gap we've flagged before, in a new place.

What we skipped

Google pushed a same-day kernel and template refresh to Gemma 4 in mid-July, which sounded promising. It isn't a catalog candidate: unsloth's Gemma-4-E2B-it Q4_K_M GGUF is 3.11 GB, over our cap on its own, and the base E2B model shipped back in April — 3+ months outside our 14-day freshness window regardless of the refresh.

Separately, two medium-severity CVEs were disclosed July 30 in common/json-schema-to-grammar.cpp, the code that turns a JSON schema into GBNF grammar for structured/tool-call output: CVE-2026-17500 (CVSS 5.3, null-pointer dereference in _visit_pattern) and CVE-2026-17501 (CVSS 6.9, uncontrolled recursion that exhausts the stack). Both are denial-of-service bugs triggered by a malicious schema, not something that touches a single-user app processing its own prompts — but worth knowing if you're exposing llama.cpp's grammar mode to input you don't control.

The catalog now, honestly

21 models, after today's addition. We've written here before that we're holding ourselves to a cap of 8 — we're not close to it. The 14 models over that line are specialist entries (medical, legal, finance, and similar) added before we set that rule, and pulling working models out of a live catalog is a bigger, more disruptive call than adding one new one, so we're flagging the gap plainly instead of quietly ignoring it or unilaterally deleting a third of the catalog in the same run we're supposed to be adding to it.

Today's deep-dive picks up a different memory question — not what fits in a download cap, but what "minimum RAM" actually means once a model file is loaded, and why the same file can cost wildly different amounts of RAM on different hardware.

Discuss this on the forum → — seen a model where the "recommended" quant misses a size budget but a smaller one doesn't? Tell us which one.