[ashhart]

The model recipes against today's code: twelve wrong claims about the native server fixed across ten pages. Each commit cites the code that settles it. Python 0.6.6 sections and measured numbers are unchanged.

Page	It said	The code
gemma-4-native.md, gemma-4-12b-native.md	M1 to M4 are refused	Served through the row path; only the drafters refuse (families/gemma4/model.zig:92, weights.zig:234)
gemma-4-native.md	tool_choice: "required" and a named function get HTTP 400	Enforced through the token grammar, which writes Gemma's own call markup (server/server.zig:318, tool_grammar.zig's .gemma style)
qwen3.5-2b-native.md	zig build ... check-generated	No such step exists under zig/build/; dropped
qwen3.6-moe.md	tensorfold pull and info refuse the checkpoint on Metal	They read it, since the hub registers the model type. Metal has no qwen3_5_moe family, so it can't serve it
nemotron-3.5.md	The native binary refuses --tp, --rank and --master	The CLI reads them, but Nemotron has no tensor-parallel ranks on CUDA, so --tp above 1 is refused by name (native/cuda_refusal.zig:55)
nemotron-3.5.md	A request reserves +16 rows past its reply	+32, the widest verify window (cuda_state.zig:14). The worked example still gives 13 pages
exl3.md, exl3-universal-experts.md	No model serves EXL3, and #741 is in review	CUDA's EXL3 operators, projections and grouped routed experts landed in 1.1.0 (#740, #741, #806, #837); GLM-5.3-Flash runs its routed experts through them (families/glm/cuda_native.zig:22) and qwen3_5 serves dense EXL3 packs (families/qwen3_5/cuda_native.zig:29)
cuda.md	The CUDA CLI doesn't apply --alias	It does (server/serve.zig:141)
adding-a-zig-family.md	Flash Next on Metal serves one reply at a time	That's the default. An explicit --parallel above one on one Mac serves it through lane_host (families/flashnext/batch_meta.zig's shared, native/flashnext_batch_host.zig)
adding-a-zig-family.md	Draft levels 3, 6 and 15; MTP chains stop at 6	3, 6 and 8 on one Mac (3 or 7 on a pair), with the thresholds in families/flashnext/drafts.zig. Metal chains run up to 8; CUDA defaults to 6 (8 greedy), capped at 15
adding-living-weights-to-a-family.md	Nemotron is the only family in living/families.zig	It lists four. Nemotron's is the learning that landed on Metal (native/metal.zig:15)

Three more, from a check of every command the docs tell a reader to run:

• docs/api.md and the XPU recipe: the grammar library installs into zig-out/native/lib on every OS (zig/build/grammar.zig:44-46), not zig-out/lib. The server looks for it there, through ../lib from zig-out/native/bin.
• qwen3.5-2b-native.md's check block loses four things that are gone: the editable pip install (the setup file is a stub that refuses), the check-generated step, capture_qwen35.py (its import has no module) and pytest tests. What it actually needs, mlx-lm, is installed instead.

Docs only.

Revision (6 Nov)

An independent read found three more errors, now fixed:

• exl3.md called cuda: EXL3 projections behind qlinear (#593) #740 and cuda: EXL3 projections write fp32 too (qlinear decodeF32 and promptF32) #806 "in review"; both landed in 1.1.0 with cuda: EXL3 routed experts behind experts.Grouped (#593, stacked on #740) #741 and cuda: EXL3 linear and grouped routed experts, every codebook and width, a width per expert (#593) #837 (CHANGELOG's 1.1.0 EXL3 line).
• Both EXL3 pages left out GLM-5.3-Flash, whose two-rank CUDA engine runs its routed experts on this module, and exl3-universal-experts.md said qwen3_5 runs routed experts through it. qwen3_5 on CUDA is the dense family; it serves dense EXL3 packs.
• adding-a-zig-family.md said the widest draft level "runs only while nearly all drafts land". flashnext/drafts.zig holds depth 8 while the moving average stays at 0.62 or above (0.8 for depth 7 on a pair); the page now gives each move in order.

[ashhart]

/atc exchange 65f0de9478ffeb5126de0fee2bd7dfb0596690a60563ba569cd3528fa5b038fb