Could a small open model be post-trained to judge code?

Short answer: for the verification / judge role a ~30B-class open-weight coder model is a realistic target after post-training on 10k runs; for the agent role (the 25+7-turn graph search at ~95k tokens a turn) nothing under the ~100B-A10B MoE class is likely to hold up, and even that is a stretch. Reasoning below, grounded in what the repo has measured.

What the three roles actually demand

Spec 082 is the key number: on held-out findings Sonnet scored 16/19, Opus 17/21, GLM-5.3 Flash 26/46, DeepSeek V4 Flash 33/63. The Flash models are already failing at the judge step, not the search step. So the place a custom model earns its keep is the final check, and the bar to clear is "better than Flash on a narrow task", which 10k examples can plausibly deliver.

Which open-weight base

• Judge / final check: a Qwen3-Coder-class 30B-A3B MoE or ~32B dense is the right size. It runs on one GPU, the task is short-context and structured, and SFT + preference training on 10k×(finding, verdict, re-ask trail) is exactly the regime where a small model closes the gap to a Flash model. I would not go smaller than ~14B; the refutation rules (specs 087–088) need real code reading, not pattern matching.
• Agent: the honest answer is a GLM-Air / ~100B-A12B MoE class, and I'd expect it to match Flash on recall only after RL, not SFT alone. gpt-oss-120b scored 43.55 vs Flash's 79 on the ingestion bench (model_benchmarks.json), so cheap-and-big is not enough — base coding quality matters. Below that class I'd expect the 30-turn trajectories to drift.
• Planner: anything 7–14B is fine; not worth a separate effort.

I'm stating model families from what I know up to mid-2026; check current open-weight releases before committing to a specific checkpoint.

The thing that matters more than the base model

10,000 "successful PRs" is not 10,000 labels. What counts as success has to come from outside the judge — merged PR plus maintainer accepted the posted comment, or a human label — otherwise you distil the judge's ceiling (GLM-5.3's 26/46) into a smaller box. Two assets you already have make this tractable:

1. answer.ts keeps refuted findings. Those are the negatives for DPO/GRPO; most teams have to generate them.
2. The final-check reader (readBaseComparison, readAccounting, the @base citation rule) is a deterministic verifier. That is a reward function already written — RL with verifiable rewards on the verdict format, with Sonnet/Opus labels only for the semantic correctness part.

So the recipe I'd actually run: SFT a 30B coder on the judge trails from the SQLite trail store (spec 086), filtered to runs whose findings survived a human; then GRPO against the program checks plus an Opus-graded correctness reward; measure on the 21 held-out cases in sim/final-check/labelled-findings/held-out before touching the agent role at all. The simulator exists, so the loop is cheap.

If you want, I can write this up as a spec in code_history/ with the data-extraction plan from the trail store — say so and I'll draft it.