← The board
Models / Diff review ■ HOLD

Diff review

The second pair of eyes on every diff. Recall over politeness, and never the model that wrote it.

Patch 2026.07 · Updated 25 Jul 2026
GPT-5.6-Sol
2 Claude Opus 5
3 Claude Fable 5

The thesis of this slot fits in one sentence: Sol will catch the bugs, Opus will catch the reward hacks, and Fable will catch the thousand lines of unnecessarily over-engineered bloat. Ideally you’d run all three, because they’re catching different things. For most diffs, Sol alone is more than enough - and here’s the evidence.

Why Sol takes gold

This is the best-evidenced pick on the entire board, because someone whose product is code review published numbers. CodeRabbit’s July eval - roughly 100 seeded error patterns from real open-source PRs - has Sol catching 69.7% of known issues against Opus 5’s 55.2%, while emitting 23 review comments to Opus’s 92. Higher recall and a quarter of the noise, at fewer tokens per review. The literalism that needs supervision everywhere else (see Delivery engine) is precisely what review wants: it checks every claim against every line and never gets bored or generous. Even Sol’s harshest community critics converge here - the recurring practitioner line is ‘right now I only use it for review’.

The runners-up

Claude Opus 5 is the precision specialist - best actionable-precision score in the same eval - and the reviewer whose stubbornness is a feature: it holds positions under pushback rather than folding. Its distinctive value is catching the reward-hack-shaped failure: code that satisfies the letter of the tests while betraying the intent, which is exactly the pathology the gold medallist is documented to produce. Reviewer and author from different labs is the design, not paranoia.

Claude Fable 5 catches the failure neither of the others is tuned for: over-engineering. Present-day models produce code that is too defensive, too complex, too local in its reasoning - the maintainer community’s most durable complaint - and the model with the most judgement per token is the one that says ‘these 400 lines should be 40, and here’s why’. Bloat review is a real axis no benchmark measures yet.

Honourable mention: Gemini 3.1 Pro. One practitioner ran it as the standing adversarial reviewer on a cryptography project and reported it ‘corrected Opus 4.8 many times, surfaced blindspots’ - and as a third-lab reviewer it’s independent of both major authoring families, with the cleanest contamination record of any lab. Nobody has published a recall number for it. Somebody should.

What to do now

Wire Sol in as the standing reviewer on everything. Add Opus when the diff was written by Sol. Add Fable when the diff is large - size is the bloat signal. Always review with fresh context, never in the session that wrote the code. And keep the deterministic tools running underneath - a linter costs nothing and doesn’t hallucinate.

Copied - paste it to your agent