Model family← Models
Laguna-XS.2
A coding model from poolside, built as a sparse mixture of experts. We held two builds and never got a score from either: one wouldn't load, and the other was never run.
- Files tested
- 2
- Scored runs
- 0
Made by poolside · Apache 2.0
How this page was made. The tests run automatically on our Mac Studio, and every score here comes straight from those runs. This overview was written by Claude, an AI model, from the lab's own records: the run log, notes kept at the time, and the working sessions where each decision was made. Quotes are Alan's words, with spelling fixed. How these pages are made.
Why we tested it
On 7 September Alan asked: "laguna-xs.2 is another worth looking at?" It is a mixture-of-experts model that uses only 8 of its 256 experts for each token, which put it among the fast models our tests favoured rather than the slow dense ones. Of four new candidates on the list that night, our agents picked it to pull first.
What it took
More than it gave back. Our overnight queue ran the MLX build on an mlx_lm that didn't know its design. The newer mlx_lm did, but couldn't load this build: the part that picks which experts to use had been compressed in a form mlx_lm doesn't expect. llama.cpp knew the design, so we fetched a GGUF instead.
What happened
- The MLX build hung for hours. The server reported itself ready while every request failed. Alan, the next morning: "Delete laguna, what else is potential for killing off".
- The GGUF was never tested. Its first download failed and took the queued tests with it; a later download landed, but the tests weren't queued again. On 11 September Alan asked "What’s the laguna model all about", and a look at the file found its chat template pointed to a separate file that wasn't included. llama.cpp ships poolside's template, but we didn't load it beside our live agent without Alan's go-ahead, and none came.
- Both files are gone. The MLX build was deleted on 8 September, the GGUF in a clear-out on 11 October.
What it taught us
- "Ready" isn't ready until the model answers. Our readiness checks now ask for a real reply. HTTP 200 does not mean a model is loaded.
- A community conversion can fail to load on every version of its runtime available at the time.
Should you use it?
We can't say: no build produced a score here. If you try it, use a GGUF on a recent llama.cpp and supply poolside's chat template, which llama.cpp ships, though we never tried that. Avoid the mlx-community 4-bit build, which wouldn't load on mlx_lm in September. Its maker, poolside, builds for coding, and we never tested it on code.
- MLX 4-bit
mlx-community's 4-bit MLX copy. No version of mlx_lm we had could load it; deleted the next day.
Mlx-community · Deleted 8 Sep 2026 · 18.8 GB · never scored · smallest Mac 32 GB
- Q4_K_M GGUF
A GGUF from Lucebox. Downloaded, found to have a broken chat template, never run, later deleted.
Lucebox · Deleted 11 Oct 2026 · 20.3 GB · never scored
Decisions, in order
- 2026-09-07 21:07Z — runtime matrix. mlx_lm 0.31.3 lacked
laguna; a separate git-main venv (mlx-main-venv, 0.32.0) was built rather than upgradingmlx-venv, "Your qwen3.8-27b and Qwen3-Next MLX numbers were produced by 0.31.3, and changing it under them would silently break comparability". - 2026-09-07 21:56Z — queued the MLX 4-bit (17.5 GiB) behind the GLM work, as stage 4 of the overnight chain. Decided by the assistant; Alan had asked about the model.
- 2026-09-07 23:04Z — benched on the wrong venv. The overnight script pinned
bench_mlxtomlx-venv0.31.3. The assistant at 05:54Z: "That's my error, and it blocked Muse-Glimmer and the DFlash test behind it". - 2026-09-08 05:55Z — retried on 0.32.0 with a generation-based readiness probe; "NOT READY". Root cause: the quantised router.
- 2026-09-08 07:31Z — switch to GGUF. "GGUF is the better route anyway — llama.cpp has
LLM_ARCH_LAGUNA"; a one-off script queued a Lucebox Q4_K_M with screening/grounding/nullschema. - 2026-09-08 07:46Z — MLX build deleted. Alan: "Delete laguna, what else is potential for killing off", after the assistant called it "genuinely dead weight; it cannot load in any mlx-lm version".
- 2026-09-08 10:10Z — Laguna-S-2.1 considered and ruled out. Alan: "would that put something like laguna2.1s on the table if REAP is viable?". Answer: 118B needs ~50% REAP pruning, which nobody had published for Laguna.
- 2026-09-08 — the GGUF arrives but is never benched. The first download failed at 10:25Z (xet transfer error), so the bench script exited. The serial re-download that landed the file at 13:11Z only downloaded. No bench was re-queued (reconstructed).
- 2026-09-09 — listed as "never scored" in the disk audits.
- 2026-09-11 19:15Z — diagnosed the GGUF. After Alan's "What’s the laguna model all about", the template was found to be
{% include 'chat_template.jinja' %}with nothing embedded. llama.cpp shipsmodels/templates/poolside-Laguna-XS.2.jinja. The assistant declined to load it next to Hermes "without you saying go". It was never run. - 2026-09-12 08:04Z — kept as the "Sole build of their model" in that sweep.
- 2026-10-11 — deleted in Tier B ("benched-once, abandoned") on Alan's "nuke tiers a & b". The RESTORE entry calls this build benched; it never was (see Laguna-XS.2 Q4_K_M GGUF (Lucebox)).
What we learned, in the lab's words
- Nothing about the model. No Laguna build has a measured case. The run-log row is a runtime failure.
- HTTP 200 does not mean loaded. mlx_lm 0.31.3 answered
/v1/modelswith 200 while it could not resolve the architecture, and the screening run hung for hours (HTTP 200 does not mean a model is loaded). - A model-card quant can be unloadable on every runtime version. The mlx-community checkpoint quantised the MoE router (
mlp.gate.proj.{weight,scales,biases}where mlx_lm expects a plainmlp.gate.weight), and mlx_lm main at7fb4be44could not load it. - Pre-registered, never tested: KV ~0.051 MB/token from head ratios, and ~52 tok/s from 1.70 GB read per token at the ~22% bandwidth efficiency measured for sparse MoE.
Why it was tested, in the lab's words
- Alan, 2026-09-07 21:04Z (typed while the assistant was busy): "laguna-xs.2 is another worth looking at?". It came three minutes after "check mlx support too" and "muse glimmer on mlx would be interesting too", and straight after he raised granite 4.2 30B.
- The assistant's case for it, 21:10Z: "Laguna-XS.2 is now the clear one to pull. It's the only candidate of the four in the fast MoE band your table rewards (8-of-256 active...) rather than the dense band it explicitly rejects".
- Compared against: granite-4.2-30b, Muse-Glimmer-30B and GLM-4.7-Flash (the same four-model shortlist). It was also listed with devstral, ornith and qwen3-coder-30b as a coder awaiting a coding suite.
- 2026-09-11, Alan: "also what models remain downloaded but untested", then "What’s the laguna model all about". That question surfaced the template bug (below).
Open questions
- Does Laguna-XS.2 load and score on current llama.cpp with the bundled poolside template? It would also test the sparsity-vs-bandwidth finding at 8-of-256.
- Which context is right: 262k (config) or 131k via YaRN (GGUF header)?
- Is it a code model? There is still no coding suite on the board to say.
The model in detail
| field | value |
|---|---|
| vendor | poolside ("they're a coding shop") |
| upstream repo | not on record (the base safetensors repo was never fetched; poolside/Laguna-XS.2-FP8 and -NVFP4 were seen in an HF search) |
| revision | not on record |
| licence | apache-2.0 (HF API check) |
| released | not on record |
| parameters | ~33B total MoE, 256 experts, 8 active (config read) |
| architecture (from the Lucebox GGUF header) | laguna; size label 256x2.2B; 40 blocks; embedding 2048; expert FFN 512; per-layer head count [48,64,64,64,...]; sliding window 512; vocab 100,352 |
| context | 262k from the config; 131,072 via YaRN from 4,096 in the GGUF header. The two records disagree and neither was tested. |
| runtime support | llama.cpp LLM_ARCH_LAGUNA present at eb25b7263; mlx_lm 0.31.3 none; mlx_lm git main 0.32.0 has laguna.py |