gemma-4-26b-a4b-mobius-custom-c1

The model our own benchmark picked first — Gemma-4 26B-A4B (MoE, 4B active) on Google's QAT q4_0 GGUF, with the same governance wrapper as C1. One 16 GB GPU, and faster per token than the 12B.

What is active depends on what you launch — the weights alone carry none of it.

how you run it	weights	code floor	RCGov	entitlement prompt	which numbers on this card apply
the GGUF alone in any app (LM Studio, Ollama, a plain llama-server)	Google's, unchanged	—	—	—	only the bare-model comparison values (the "bare" figures beside each number) — this is Gemma-4 exactly as Google ships it
llama-server + your own client, with L0_compact_v1_1.json as the system message	same	—	—	yes	the prompt-only rows (multi-turn: "prompt as system"; premise / high-stakes / routed: the compact rows in eval/)
run_server.sh + mobius_c1.py — the shipped configuration	same	yes	when installed (fail-open)	yes	the wrapper-evaluated values (premise / high-stakes / routed corpus / well-specified / speed). The multi-turn tool-loop rows come from a separate harness (eval/loop/loop_probe.py) that injects the same prompt but not the wrapper

The floor is two regexes (empty input, a short unsafe-request list). It is deterministic, not a safety classifier: it was probed only on the routed corpus's four unsafe items.

This is the C1 design (code floor + RCGov + the L0 Essentials compact v1.1 entitlement prompt) on the base that the compact prompt was actually distilled on. Every ablation behind compact v1.1 — six variants × six probes × three seeds, the false-premise set, the high-stakes set — was run on this model. The 12B C1 is the port; this is the original.

Measured (3 seeds, rows in eval/, this exact GGUF):

• 0/12 fabrications on false-premise questions (bare model: 0/12)
• 9/9 "decline the personal call, still give general information" on high-stakes questions (bare: 9/9)
• 63/63 · 15/15 · 33/33 answer / ask / abstain on the routed acceptance corpus (bare: 63 · 15 · 31)
• 60/60 plain answers on well-specified questions — no over-asking
• 5.0 s per call on the routed corpus (bare 5.7 s); 6.4 s on high-stakes chat
• PP 5,880 · TG 155.7 tok/s on a 4,000-token prompt, one RTX 5070 Ti, -c 32768

What you don't get: a governance-quality gain over the bare model on these probes — like the 12B, the bare 26B-A4B already passes them (its two sub-33 abstain rows are contentless prompts it deferred in wording our scorer does not match; unsafe prompts were refused 12/12; unlike the 12B it did not invent a problem on an empty prompt in these 3 seeds). The wrapper's contribution is a deterministic floor — input matching its regexes (empty, or the short unsafe list) never reaches the model — a measured prompt, Google's unchanged weights, and a published prediction ledger (27 of 42 wrong across the work).

Which one should I run?

	gemma-4-12b-mobius-custom-c1	this model
weights	Gemma-4 12B QAT q4_0, 6.98 GB	Gemma-4 26B-A4B QAT q4_0, 14.44 GB
VRAM at -c 32768 (measured)	~7.4 GB	~14.7 GB — needs the full 16 GB card, nothing else on it
quality, our 8-task suite	not measured	7.89 / 8 (the top score on this machine)
speed, same GPU	PP 4,266 · TG 83 tok/s	PP 5,794 · TG 154 tok/s — the MoE is faster despite the size
governance probes	identical results	identical results
multi-turn tool loops (added 2026-09-13)	bare model already commits on dead ends; prompt neutral	bare model wanders on dead ends 3/3 and fabricates "sent" 1/3; this prompt fixes both
wrapper, prompt, floor	same	same

Take the 12B if you have 8–12 GB, share the card with a display, or want headroom. Take this one if the 16 GB card is free for the model. Below 16 GB it does not fit.

Use

./run_server.sh                      # PORT=8080 CTX=32768 THREADS=8; needs llama.cpp's llama-server (or LLAMA_SERVER=/path)
python mobius_c1.py "Should I use Postgres or MySQL?"

from mobius_c1 import MobiusC1
c1 = MobiusC1("http://127.0.0.1:8080")
c1("?")                                   # floor: {'route': 'abstain', 'floor': True, ...}
c1("What does PCIe stand for?")           # model: {'route': 'model', ...}
c1("Summarize this.", context=doc_text)   # context passes through RCGov when installed

Any OpenAI-compatible client can also talk to the server directly; put the contents of L0_compact_v1_1.json in the system message to get the prompt's behaviour without the wrapper (you lose the floor and RCGov). Loading the GGUF in another app without that system message gives you bare Gemma-4 — the MOBIUS layers are not active.

-c 32768 is the measured sweet spot on this model: 16k and 32k run at the same speed; 64k costs 38 % of prefill and 128k costs 67 %, while VRAM barely moves (sliding-window attention keeps the KV flat) — so VRAM headroom is not a sign that a larger context is free. Keep --reasoning-budget 4096: without a cap this model can spend its whole budget thinking and return nothing.

Governance components

• Floor: _EMPTY / _UNSAFE regexes from the original 12B custom model, unchanged. Deterministic, no model call.
• RCGov (optional): pip install "rcgov @ git+https://github.com/mobius-style/rcgov.git"; retrieved context is governed with the Balanced profile.
• L0 Essentials compact v1.1: routes.ask / verify / re_anchor / abstain (abstain = L0 v8.4.1 wording) + premise_validity, verbatim from L0 Essentials v1.3. Validation note and rows: mobius-style/mmv → docs/L0_ESSENTIALS_COMPACT_VALIDATION.md · dataset moebiusT7/l0-essentials-compact-ablation

Multi-turn tool loops — added 2026-09-13

A Reddit review of the 26B-A4B reported "thinking spin" / empty turns in agent loops. We measured it: 7 chained tool tasks × 3 seeds × 5 configurations (105 loops), ≤ 8 turns each, thinking on, deterministic fake tools, on the exact GGUF shipped here. Harness, prediction ledger and every row are in eval/loop/.

configuration	completed /21	hit the 8-turn cap	empty turns	dead-end task (missing file)	claimed "sent" after the send tool refused
bare model, thinking uncapped	15	3	0	0/3 — wanders for all 8 turns	1/3
bare + --reasoning-budget 4096	15	3	0	0/3	1/3
bare + code guard (see below)	17	0	0	3/3 at turn 3	2/3
compact prompt as system (tool-loop harness, no wrapper)	18	0	0	3/3 at turn 2 — "I cannot find the file"	0/3 — asks first 3/3
compact prompt as system + code guard	18	0	0	3/3 at turn 2	0/3 (guard never fired)

• The reported empty turns did not reproduce on this file with llama.cpp (build 2026-09-09): 0 in 105 loops. The thread's own comments point at an unsloth GGUF + older-parser combination, which we did not run.
• What did reproduce is a different regress: on a dead end (a file that does not exist) the bare model wanders — read_file fails, then five or six grep_log calls with different patterns, list_tables, … — all 8 turns, 3/3 seeds, never committing. Every action is new, so loop/repetition detectors are blind to it.
• In the tool-loop harness, the configuration with the compact prompt as system message ends that in 2 turns with an honest abstain, and stops fabricating "sent" when the send tool refuses for lack of confirmation. No extra tokens beyond the 477-token system prompt.
• The code guard is the MOBIUS anti-regress rule (M guard) as ~30 lines of Python: treat a turn as a zero transition if it was empty, repeated an earlier (tool, args), or was the 2nd consecutive turn whose tool results were all errors / no-match / already seen; then force one commit. It fixes the wander on the bare model and is inert on top of this prompt — useful only if you cannot set a system prompt. It is in eval/loop/loop_probe.py (arms G/C), not in the wrapper.
• The same probe on the 12B C1 shows no wander and no fabrication on the bare 12B (18/21 in every configuration): the regress is specific to this MoE on this build. Failures common to all configurations are counting errors over a 432-line log, not loop defects.
• Limits: one build, one quant, 3 seeds, synthetic tasks, temperature 0.2; llama-server is not bit-deterministic across runs at the same seed (one loop flipped), so one-loop differences are noise. Two scorer defects found on the 12B rows were fixed and all rows rescored offline (the 26B table did not change). The information-gain trigger was added after the first bare run exposed the wander (disclosed in eval/loop/PREDICTIONS.md). Not adversarially reviewed.

Limitations

• 16 GB is the floor, not a comfortable fit: ~1.5 GB headroom at -c 32768 with nothing else on the card.
• The floor was probed only through the routed corpus's four unsafe items; the L0 hard-floor clause beyond that was not tested. Multi-turn: only the 7 synthetic tool-loop tasks above. Multimodal path not governed (projector not shipped).
• Not adversarially reviewed. Predictions were written before every measurement; 27 of 42 were wrong.
• Scores are keyword/regex judgements over raw text and were corrected nine times during this work as real rows exposed phrasings they missed; the raw outputs are in eval/ so you can rescore with your own instrument.

Provenance and terms

gemma-4-26B_q4_0-it.gguf is Google's file, unchanged (sha256 3eca3b8f6d7baf218a7dd6bba5fb59a56ee25fe2d567b6f5f589b4f697eca51d), under the Gemma Terms of Use. Wrapper and prompt: MOBIUS LLC, AGPL-3.0. Rows: CC-BY-4.0. See NOTICE.md.