Catalog Laguna XS 2.1 and S 2.1

[rammsguns]

Closes #26.

Adds laguna-xs-2.1 and laguna-s-2.1 to the catalog with hf-api provenance dated 2026-08-12.

What was verified, and how

Every figure is one curl away from the fact_source in the row:

	XS 2.1	S 2.1
createdAt	2026-06-20	2026-07-13
safetensors total	33,442,617,088	117,561,977,600
max_position_embeddings	262,144	1,048,576
experts / top-k	256 / 8	256 / 10
licence	openmdw-1.1	openmdw-1.1

tools and reasoning come from the chat template, which carries tool_call, tools, reasoning_content and enable_thinking.

The estimator, checked against real bytes

This is the part I'd most like reviewed, because it is the number every fit decision runs on:

Row	Quant	Estimated	Measured	Δ
laguna-xs-2.1	Q4_K_M	20,165 MB	20,274 MB	0.5%
laguna-s-2.1	UD-Q4_K_XL	73,353 MB	73,395 MB	0.06%

Measured = summed GGUF file bytes from the published repos on 2026-08-12. A test holds both to 3%.

Behaviour change worth a decision

Laguna XS 2.1 becomes the top medium pick on this machine, ahead of qwen3-coder-30b (81 vs 73), and Laguna S 2.1 becomes the top large pick. Nothing was weighted to make that happen. With every coding rating still unknown the quality term does no discriminating work, so the ranking runs on freshness, hardware fit, speed and features — and a June 2026 MoE with a 262k context wins all four against a July 2025 one.

That is the existing design behaving as designed. It is also an argument for finishing the local benchmark rather than for hand-weighting the table. Say so if you'd rather the new rows not be default picks and I'll change it.

Three judgement calls, flag any of them

1. CATALOG_MAX_ROWS 15 → 17 rather than retiring two rows. The comment now carries the date and reason, and says that past ~20 the answer is to retire instead. Retiring phi-4 and qwen3-1.7b was the alternative; that is a product call I didn't want to make silently.
2. Ratings stay unknown despite Poolside publishing 70.9% SWE-bench Verified for XS. Reasoning in the table comment. This is the first time the rule has cost us a real number.
3. SELECT_MAX_LISTED raised to match. Left at 15, the two lowest-scoring rows would have vanished from the menu with no message. A test now enforces that the caps agree.

Not done

Neither model has been downloaded or run here — that is 19 GB and 68 GB respectively, and the rows make no claim that depends on it. The architecture reached mainline llama.cpp in ggml-org/llama.cpp#25165 (merged 2026-07-22) and the binary on this machine is newer, so support is present; that is a version check, not a load test.

Tests

388 pass, 11 new (8 catalog, 1 score, 2 selector). Both runners green, including tests/isolated.sh.

Two existing score tests were changed rather than added to. They asserted a fixed list of three size classes, which was really an undocumented assertion that no catalogued model is unrunnable at 20 GB with zero offload. A 117.6B row makes that false, and it surfaced as a failure in the grouping tests rather than where the assumption lived. Both now assert the invariant score_rank documents — each class once, contiguous, unsupported last.

[rammsguns]

PM review: product decisions accepted.

• Keep CATALOG_MAX_ROWS and SELECT_MAX_LISTED at 17. Adding the two current, relevant rows is preferable to silently retiring useful coverage; revisit retirement before the catalog exceeds roughly 20 rows.
• Keep Laguna XS 2.1 and S 2.1 eligible for normal selection. Do not suppress or hand-penalize XS merely because metadata currently makes it the top medium pick. The unfinished local benchmark is the correct place to add comparable quality evidence.
• Keep both ratings unknown; the isolated vendor SWE-bench disclosure is not comparable with the rest of this catalog.
• No model download or runtime test is required for this issue. The PR clearly distinguishes sourced configuration/GGUF-byte facts from measurements not performed locally.

The acceptance criteria are covered and CI is green. One wording nit, not a blocker: the selector regression test enforces SELECT_MAX_LISTED >= CATALOG_MAX_ROWS, which is the safety invariant, rather than strict equality as the PR summary says.

Ready to merge from the PM side. Merge this before the TUNING.md queue because it does not participate in that conflict chain.