Granite Guardian 4.1 8B · file← Granite Guardian 4.1 8B

MLX mixed_3_6

Our MLX copy: 95% on mlx_lm, 36.7% on oMLX. Later deleted. Made here.

Size: 3.8 GB
Status: Deleted 11 Oct 2026
Scored runs: 1
Smallest Mac: 8 GB estimate, 8K context

Results1 scored · 95% intervals

Suite	Score	95% interval	Passed	Runtime · profile	Recorded
screeninggranite-guardian-4.1-8b-mlx-mixed36	95.0%	86.3–98.3	Passed 57/60	mlx_lmextraction	2026-09-09

Runs marked unenforced were measured on a suite that requires constrained decoding, on a server shown not to apply the schema: mlx_lm accepts it and ignores it, and a few other servers and models break it. Those numbers do not measure what the suite is designed to measure. They are kept and labelled rather than deleted.

The recordHow it was made · how it was served · what went wrong · what happened to it

Rebuilt from the lab's records by Claude, an AI model. The results above come straight from the automated runs. How these pages are made.

File	`granite-guardian-4.1-8b-mlx-mixed36/`
Format	MLX, `--quant-predicate mixed_3_6`, 3.906 bpw, 3.8 GB by du
Where from	made here 2026-09-09 ~10:50Z from the safetensors
Status	deleted 2026-10-11

How it was made

Input: ibm-granite/granite-guardian-4.1-8b safetensors (Granite Guardian 4.1 8B BF16 safetensors (IBM, HF cache)).
Command (first attempt a one-off script):

MLX=mlx-venv/bin/python
$MLX -m mlx_lm convert --hf-path ibm-granite/granite-guardian-4.1-8b \
--mlx-path models/granite-guardian-4.1-8b-mlx-mixed36 -q --quant-predicate mixed_3_6
ln -sfn …/granite-guardian-4.1-8b-mlx-mixed36 $HOME/.omlx/models/granite-guardian

"Quantized model with 3.906 bits per weight".

Tool: mlx_lm in mlx-venv. The run log says 0.31.3, but that version is runtime_source "evidence", taken from the venv on 2026-10-21; it was not stamped at run time.
Date: 2026-09-09, done by 10:50Z.
Size: 3.8 GB by du -h; "4.1 GB" in decimal listings. Exact bytes never recorded.
Who asked / why: Alan, "can we convert granite?". The recipe was chosen because "on REAP plain q4 destroyed tool calling (5/12)" where mixed_3_6 preserved it (12/12), and "For a judge, precision is the whole job" (script header). The goal was to move the judge into the single oMLX pool, which "retires the separate llama.cpp process".

How it was served

label	dates (UTC)	binary and version	flags	harness profile	why this label exists
`granite-guardian-mlx-mixed36`	2026-09-09 11:12Z	oMLX 0.6.4 (`omlx-venv/bin/omlx serve`)	`--model-dir $HOME/.omlx/models --max-concurrent-requests 32 --paged-ssd-cache-dir $HOME/.omlx/cache --hot-cache-max-size 8GB --memory-guard balanced`	extraction	first validate arm; pre-flight used id `granite-guardian`, runner sent `granite-guardian-mlx-mixed36`, so all 60 rows were HTTP 404
`granite-guardian` (oMLX rows)	2026-09-09 11:22Z–12:37Z	oMLX 0.6.4	as above; the 12:37Z run restarted oMLX with `--no-cache` (B2) after a cached run (B1)	extraction	validate relaunched with the pool id; then the oMLX cause tests — reconstructed mapping of the 13:37:02 row to the `--no-cache` run, from the result-file mtime 13:37 local and the transcript
`guardian-mixed36-mlxlm`	2026-09-09 12:11Z	`mlx-venv/bin/python -m mlx_lm server --model <path>`	defaults	extraction	runtime A/B; label sent as the wire id, so all 60 rows were 404
`granite-guardian-4.1-8b-mlx-mixed36`	2026-09-09 12:13Z–12:18Z	mlx_lm server	defaults	extraction	the relaunch with `--model-id "$M36" --label guardian-mixed36-mlxlm`. The results were filed under the path-derived name (`screening__…-mlx-mixed36`), not the label; the run-log label is a later rename

Seats held: in the oMLX pool as granite-guardian 2026-09-09 10:50Z → 11:49Z, unvalidated, then unlinked and the pool restarted. Never seated afterwards. No --jinja/reasoning flags apply (MLX servers use the HF chat template).

Decisions

Made to consolidate the judge into oMLX. Linked into the serving pool before validation, which the assistant later called "the single most dangerous thing I did today".
Pulled from the pool 2026-09-09 11:48Z.
Kept 2026-09-09 14:07Z as "smallest usable" when the 8-bit and bf16 were deleted.
Survived a deletion by accident 2026-09-16. The inventory listed it as SUPERSEDED ("MIXED36 slower than the Q4_0 beside it"; that comparison was never measured). The rm targeted models/granite-guardian-4.1-8b-mlx, a truncated name, and reported "absent".
Named a publish candidate 2026-10-07: "Apache-2.0 base, stock mlx-lm loads it, 95% screening on mlx_lm server … Do not serve on oMLX". Not uploaded.
Deleted 2026-10-11 in the Tiers A & B sweep ("nuke tiers a & b"). The stated reason was "mixed-quant probes are dead ends by the fleet's own measurement". The measurement on record is 95.0% on mlx_lm.

What went wrong

oMLX 36.7%: the runtime finding. It cost the morning's fleet consolidation and voided four toolcall/1 runs of other models.
Two 404 runs (granite-guardian-mlx-mixed36, guardian-mixed36-mlxlm): wire id ≠ server id. That led to runner.py --label being added.
Label/file collision under granite-guardian: the GGUF arm overwrote the oMLX arm's results. The surviving file and its .superseded (mtime 13:31 local) both hold 22/60 oMLX runs.
--label did not take effect on the 12:13Z relaunch: results landed under the path-derived file name, and screening__guardian-mixed36-mlxlm__… still holds the 60 × 404 rows (file mtimes 13:12 and 13:18 local) — reconstructed.
Stale build stamp: the oMLX rows of granite-guardian (12:22:24, 12:28:45, 13:37:02) carry llama_build: 0.2.0-dev (build 10618 …) although oMLX served them.
Partial rows: 12:22:24 (5/60) and 12:28:45 (59/60).
Finding mismatch: Converting the judge to MLX destroyed it, from 100% to 36.7% still says conversion "destroyed" the judge.

What happened to it

Converted 2026-09-09 ~10:50Z → oMLX pool (unvalidated) → 36.7% on oMLX / 95.0% on mlx_lm, 2026-09-09 → unlinked 2026-09-09 → survived 2026-09-16 by a wrong path → publish candidate 2026-10-07 → deleted 2026-10-11 (the restore script lists it as a comment with no re-create command). Re-creatable from the safetensors in the HF cache with the command above; mlx_lm version should be stamped next time.