gemma-4-12b fast — 4/9 (MinimalPi, K=1)

First fast-set run of gemma-4-12b, launched to answer "how does gemma 4 12B compare with qwen" on a timescale of hours instead of the ~30 h a full suite costs. Config matched to the existing qwen MinimalPi baselines so the numbers are comparable: MinimalPi, K=1, AGENT_TIMEOUT_MULT=2.0, the set's default TASK_SET_fast_TIMEOUTS cap map, all config/harness.env defaults (thinking on, preamble on, write/loop guards on, qwen_tools on, bash_timeout 90, max_tokens 65536).

Companion run: fast2__gemma-4-12b__20260727-014500 (2/6).

Result: 4/9, elapsed 39m38s

task	gemma-4-12b	qwen3.6-35b-a3b	qwen3.6-27b
fix-git	PASS 35s	PASS 8s	PASS 30s
nginx-request-logging	PASS 42s	PASS 24s	PASS 53s
openssl-selfsigned-cert	PASS 41s	PASS 15s	PASS 1m04s
cancel-async-tasks	PASS 59s	FAIL cut@3m	FAIL 1m20s
sparql-university	FAIL 2m11s	PASS 1m17s	PASS 2m48s
sanitize-git-repo	FAIL cut@3m	PASS cut@3m	PASS 2m25s
query-optimize	FAIL 4m40s	FAIL 5m05s	PASS 6m19s
regex-log	FAIL 9m53s	FAIL cut@10m	PASS 6m38s
filter-js-from-html	FAIL 2m49s	FAIL 40s	FAIL 2m43s
total	4/9	5/9	7/9

Baselines: fast__qwen3.6-35b-a3b__20260710-213727, fast__qwen3.6-27b__20260706-124744.

K=1 on 9 tasks — a ±1 difference is noise. The per-task pattern is the signal, not the count.

regex-log: the -n 65536 cap works, and the task still fails for a DIFFERENT reason

This closes the open ledger question from first light. The trial is 4 assistant turns, and zero tool calls in the entire session:

turn	stopReason	thinking	text	tools	output tok
1	–	0	1021	none	–
2	length	18932	1573	none	65536
3	–	0	279	none	–
4	stop	18835	1891	none	8872

• Turn 2 stopped at exactly 65536 output tokens — the server-side -n 65536 added after first light firing as designed. The runaway generation still HAPPENS; the cap converts it from unbounded (215,206 tokens / 30 min, the first light ERR) into a bounded ~9-minute turn. The cap is load-bearing: without it this trial would have ERRored the same way again.
• 65536 + 8872 = 74,408 = the run's reported output tokens. Accounting checks out.
• The task fails because the model never called a tool. Its final message is the answer as a fenced Python snippet ending in with open("/app/regex.txt", "w") as f: f.write(regex) — written about instead of executed. Nothing landed on disk.
• Runaway recovery fired once (rec:1) and did not change the outcome.

So the server fix did its job and the remaining failure is a separate, task-specific pathology: on this task gemma narrates the solution instead of executing it. Note it is task-specific, not model-wide — fix-git, nginx, openssl and cancel-async all pass in under a minute, which requires working tool calls. regex-log was also the single failure in the first-light smoke.

Where gemma differs from the qwen models

It wins the quick tasks and loses the grindy ones. The four passes average 44 s of agent time. Every failure is either a cap cut or a multi-minute grind.

cancel-async-tasks is a genuine gemma win — 59 s pass on a task the 35b MoE lost to its own 3-minute cap and the 27b failed outright.

Token churn is much higher than qwen's. sanitize-git-repo burned 2.23 M input tokens in a 3-minute capped window (peak context 136 k, one harness prune). The 27b did the same task in 403 k and passed. This is the pattern to watch — see the fast2 notes, where it is far more extreme.

False-success shape is present and RULE 2 is not landing. 4 of the 5 failures self-declared done on a clean stop, and 0 of those had run any check (V=0 on query-optimize, sparql-university, filter-js-from-html). The preamble's "verify before declaring done" rule flipped openssl FAIL→PASS for qwen; on gemma the verify-command counts are 0–1 on every failure. Worth an explicit PREAMBLE=off A/B before assuming it helps this model at all.

Two near-misses are one assertion away: query-optimize and sparql-university both passed at least one hidden subtest. These are the cheapest candidates for a follow-up.