Can a cheaper model review code like Fable?

Nine reviewers replayed four changes on which Fable caught a real bug. Round one 29 October 2026, round two 30 October.

Updated 30 October. Round two re-ran the two bugs almost every reviewer missed, with a better review prompt and the subscription reviewers added. Every reviewer went from mostly missing the old-shell bug to catching it every time. The deadlock still split them. Skip to round two: give the reviewer the facts first.

Two AI reviewers, by the numbers counted seven weeks of every change in the lab reviewed by two Claude models. Fable is the more expensive of the two, at about $2.50 a review at list price. This asks whether something cheaper can do the same work, and in particular whether the largest open-weight models, the kind a 512 GB Mac Studio can hold, are good enough to be worth running at home.

The test

I took four changes on which Fable's live review raised a HIGH, a finding meant to block the merge, and that I had confirmed was a real bug. Each reviewer then reviewed each change again:

• Blind. A fresh copy of the repository as it stood at that commit, with no later history and no access to the original reviews.
• The same reviewer. The same prompt, tools and review harness as a live review. Only the model changed. The open models were reached through Anthropic-compatible endpoints: rented through OpenRouter, or running on my own 128 GB Mac Studio.
• Judged by a third model. A Sonnet model, which was none of the reviewers, compared each review with Fable's original finding.

The four bugs, described by what they would have done:

1. Unsafe file paths, two bugs in one plan. A tool holding credentials would write files wherever a third-party service's reply told it to, including outside the project. The same plan also required a test that another plan forbids.
2. Keychain guard. A guard meant to stop agents reading saved passwords could be bypassed by adding a comment to the command.
3. Status deadlock. A status check that waits for a review would also stop that review from running, so the change would wait forever.
4. Old-shell build. A build step used a shell feature that the build machine's older shell doesn't have, so it would fail on every run.

Round one: the results

What it shows

• One open model matched Fable. GLM-5.3 caught the same two changes Fable caught and missed the same two, with no false alarms, at about a tenth of the cost per review. On the keychain bug it ran the guard itself to show the bypass working. The copy I rented was compressed to 4 bits, which is about the size a 512 GB Mac Studio can hold.
• Size alone was not it. DeepSeek V3.2 and Mistral Large 3 are about GLM's size, and both missed the keychain bypass. DeepSeek checked some of the ways round the guard and not the one that worked. Mistral raised a false alarm: it reviewed a plan as if the code should already exist. Qwen3-Coder 480B, built for code, called the broken guard "elegant and secure" and approved it.
• A small model surprised me. gemma4 31B fits comfortably on the Mac I already have. It caught the keychain bypass with the exact comment trick, and one of the two file-path bugs. It was slow, though: 8 to 12 minutes a review, and it ran past the 30-minute limit on the other two.
• Nobody caught the deadlock this time, Fable included. Fable's live review had caught it. On the replay, Fable, Opus and GLM all approved the change. One review from the best model is not a guarantee, which is the case for having a second reviewer at all.
• The old-shell bug is hard for everyone. Nothing in the repository says the build machine has an old shell, so a reviewer can only know it from outside.
• Opus finds what Fable finds and rates it lower, the same pattern as in the earlier article, in about half the time and at about a fifth of the cost.

What I took from round one

• A cheaper second reviewer is plausible. On these four changes, an open model rented by the token did Fable's job for about 26 cents a review.
• Not yet a reason to buy the bigger Mac. A 4-bit GLM-5.3 would just fit in 512 GB, and the rented one took 4 to 7 minutes a review on data-centre hardware. At home I would expect 30 to 60 minutes. That is a guess, not a measurement. The reason to run it locally is privacy, not price: renting it sends the code to a third party.
• Four changes is a reason to run more, not to switch. The next round adds the remaining cells and the reviewers I already pay for by subscription: OpenAI's Codex, Google's Gemini and Meta's Muse.

Round two: give the reviewer the facts first

Two bugs got past nearly everyone in round one, Fable included: the status deadlock and the old-shell build. On the old-shell bug most reviewers read the line, named it, and rated it minor, because nothing in the repository says how old the build machine's shell is. Catching the deadlock means reading two design decisions the change cites and noticing that they contradict each other.

So round two kept the models and changed the question. The review prompt gained three things:

• Host facts. A short, measured list of what the machines actually run, such as the shell version on the build machine.
• Cited decisions. Every design record the change or its description names, pasted in as it stood at the change's base.
• A contract check. An instruction to test each claim the change makes about another component against that component's own record.

Each reviewer then ran each of the two changes four times on the old prompt and four times on the new one. The subscription reviewers, OpenAI's Codex, Google's Gemini and Meta's Muse, joined in this round.

Each cell counts runs that rated the bug HIGH, out of the runs made: old prompt on the left, new prompt on the right.

Green: every run caught it. Amber: some did. Red: none did. Every new-prompt run was judged by a Sonnet model against the original finding. None raised a HIGH the judge called wrong.

What round two shows

• The new prompt fixed the old-shell bug for every reviewer. Open or closed, cheap or expensive, every reviewer that ran it caught the bug in every run. The prompt changed three things at once, and I didn't test them separately. My reading is that the stated shell version did most of the work: on the old prompt the reviewers already named the line and only rated it low.
• The deadlock still separates the models. With the cited decisions in front of them, Opus caught it every time, Gemini three times in four and Codex twice. Muse Wonder named it in all four runs but rated it lower each time. The open models GLM-5.3 and Muse Spark Open missed it in all eight runs, and GLM, which caught it once on the old prompt, didn't repeat that. So round one's "GLM matched Fable" holds for the bugs a fact settles, not for the one that takes reasoning.
• Opus on the new prompt beat Fable on the old one. On the old prompt Opus caught these two bugs once in eight runs, and Fable four times. On the new one Opus caught them in eight of eight. Fable hasn't been re-run yet: it bills by the token outside my subscription, and I'd used this month's budget.
• The extra HIGHs were real, just overrated. Gemini, GLM and Wonder sometimes raised a second HIGH. I checked each against the code. Each described a real gap, already noted at a lower severity, that doesn't break anything today. One became a small fix and the other an issue. They were not wrong, but a HIGH blocks a merge, so in practice each one would have held up a change for something that could wait.

What I take from it now

• Give the reviewer the facts first. Telling every reviewer what the build machine runs and pasting in the design records a change cites did more for the old-shell bug than any choice of model. Before paying for a bigger model, write down what the reviewer can't see from the code.
• Keep a frontier model in the seat that approves. The deadlock takes reasoning across two documents. Only Opus, Gemini and Codex rated it HIGH, and Opus did so every time.
• An open model makes a good second seat. GLM-5.3 and Muse Spark Open caught the fact-shaped bug every time, and neither made a wrong finding. GLM sometimes rated a real but minor gap as HIGH. Muse Spark Open didn't. Both are the size a 1 TB machine could run at home, which keeps the code in the house.

Round two: method and limits

Not a held-out test. The new prompt was written after studying these two bugs, so this shows it can work, not that it generalises. The next round uses changes the prompt never saw.

Not isolated. The new prompt added host facts, cited decisions and a contract check together. Which of them moved which result is my interpretation, not a measurement.

Access differed. Opus reviewed with read access to the repository. The others got the change and the gathered context, and no tools. That favours Opus on the deadlock. Muse Spark Open's old-prompt cell is a single run.

Costs. The subscription reviewers cost nothing per review beyond the plan. The rented open models cost cents a review at their provider's rates.

Round one: method and limits

The sample. Four changes, all chosen because Fable caught something, so Fable's replay is being scored against its own earlier result. One run per reviewer per change. Fable and Opus repeated their keychain result in a second run, Fable at HIGH both times and Opus lower both times. The others ran once.

The gaps. "Not run" cells are models I tried on one change first, to decide whether to go further. "Timed out" means the review did not finish within 30 minutes on my Mac.

The harness. Every model ran inside the same Claude-based review tool. A model that is good in its own vendor's tool may do worse here, so a miss is a miss in this harness. In this round the open models had the same file access as the Claude reviewers. Future runs give a third-party model the change and nothing else.

Judging. The Sonnet judge's calls were not hand-checked against the code, unlike the earlier article's.

Costs. Fable and Opus at Anthropic's API list prices, computed from each review's own token counts. The reviews actually ran on a subscription. The open models are at their provider's per-token rates. The rented GLM-5.3 was served at 4-bit precision.

The aggregate this follows: Two AI reviewers, by the numbers.
The review loop itself: Nine rounds with a machine reviewer.