Phase 1 of the local-model plan: prove the model before writing any plumbing.
`JUDGE=local` runs the existing done_when eval against Ollama on a GPU node.
Requests originate on that node rather than the gateway, because the model is
bound to 127.0.0.1 deliberately — it has no network exposure at all — and the
gateway has no GPU.
MEASURED on tank, 3 draws per case, against the incumbent on the same cases:
local (ornith-fleet:9b) 14/15 — one UNPARSED, never a wrong verdict
glm (glm-4.7) 13/15 — two WRONG verdicts on kernel-ok
kernel-ok is the case production actually hit and the one this script's header
says is expected to fail on glm-4.7. A 5.6 GB model on hardware we already own
did not get it wrong once in three draws.
The tag is `ornith-fleet:9b`, not `ornith:9b`, and that is the finding worth
keeping. Ollama defaults to a ~2K window whatever the model claims: stock
ornith:9b reported input_tokens=2050 for a 48000-word prompt and answered as
though nothing had been dropped — silent truncation, confidently. The fleet tag
pins num_ctx=131072, which measures 9.3 GB resident of a 16 GB card (the full
262144 also fits, at 13.6 GB, 100% GPU). These eval cases are a few hundred
tokens, so this eval would have passed either way; that is exactly why the tag
under test has to be the one production would use.
Also measured: Anthropic /v1/messages returns well-formed tool_use with
stop_reason=tool_use on both nodes; the reported count_tokens?beta=true hang is
absent in 0.31.1 (clean 404, server unaffected); ~60 tok/s generate, ~2800
tok/s prefill, 120072-token prompts accepted end to end.
Co-Authored-By: Claude Opus 5 <[email protected]>
The microvm scenario's judge assertion failed four runs straight. I blamed the
wording twice and rewrote it twice; the second rewrite made it worse. That was
guessing.
With scripts/judge-eval.sh in place the question is cheap to settle. Three
candidate conditions, three draws each, same evidence and same system prompt:
"its second line is …" MET UNMET MET flaky
"records the kernel version …" MET MET UNMET flaky
"contains both … and …" MET MET MET stable
So it was never noise in general — it is a reproducible weakness with
POSITIONAL and EXCLUSIVE phrasings. "its second line is X and nothing else"
invites this judge to invent requirements about the other lines, which is
exactly the reason it kept citing ("the first line contains 'test result: ok'").
Both fixtures now state what the file CONTAINS. The composed one was checked in
both directions — 3/3 MET on good evidence, 3/3 UNMET when the versions are
missing — because a wording that always answers MET would look stable and prove
nothing.
The eval keeps `kernel-ok` failing on purpose; it is the case production hit,
and tuning it green would turn a measurement into a decoration.
Harness: 24/24, including the assertion that had failed four times.
TWO FINDINGS, one from cleaning up and one from refusing to keep guessing.
THE LEAK. `./scripts/test.sh` left three containers running every time — 289 had
accumulated. The cause was a comment that lied: `warm_pool.rs` said "Shutdown
destroys assigned AND pooled sandboxes", while `SandboxManager::shutdown` drains
the POOL only. Its own doc says why — assigned sandboxes persist deliberately so
a redeploy can reuse them, and production reaps the strays with
`reconcile_orphans` at boot. A test has no next boot, so each one that assigned a
sandbox simply left it running. The three tests now call the `release_agent` that
already existed, and the comment says what the code does. Verified: 0 leaked,
where the same run leaked 3 before.
THE EVAL. The independent judge failed the same correct phase FOUR times, each
time citing a different invented requirement. I blamed the condition's wording
twice and rewrote it twice — the second rewrite made it worse, by naming a
command a tool-using judge then ran in its own container. Then a control showed
the same model answering MET to the same question asked directly, and a third
wording test showed a STRICTER phrasing scoring UNMET. Prose wording was not the
variable. Continuing to iterate would have been fitting the fixture to noise.
`scripts/judge-eval.sh` measures the thing instead: five cases drawn from real
incidents, each with an answer a careful human would agree with. This project has
557 tests and had zero evals, which is backwards — a test pins OUR code, an eval
pins the MODEL, and the model changes without us touching anything.
The result is why it was worth building:
glm-4.7 4/5 — wrong on kernel-ok: says UNMET when MET
kimi-for-coding 4/5 — wrong on goodhart: says MET when UNMET
Identical scores, opposite failure modes. GLM fails good work; KIMI passes work
where 14 assertions were deleted and the failing module removed to make a suite
"pass" — the exact incident the verifying judge was built after. Swapping the
validator to Kimi because it passes our failing case would have installed a
rubber stamp. Keep GLM: a judge that is too strict costs a re-run, a judge that
is too lenient costs the guarantee.
The eval also caught a bug in itself before I trusted it: Kimi answers with a
`thinking` block first, and a 160-token budget was consumed entirely by it, which
the harness scored as NO-ANSWER. An eval that misreads a model is worse than no
eval, so it now reads thinking blocks as a fallback and has room to answer.
557 tests pass, clippy clean.
Co-Authored-By: Claude Opus 5 <[email protected]>
