Let the Cheap Model Decide: Luna-First Code Review Found 12 More Bugs Than GPT-5.6 Sol at the Same Cost

Our last two posts compared models one at a time. GPT-6 Astra against GPT-5.6 Sol showed the most expensive model wasn't the best reviewer. GPT-5.6 Luna against Astra showed a $1.20 model finds three-quarters of the bugs for almost nothing.

Both posts assumed a team picks one model and runs it on every pull request. For this one we went back to the reviews we already had and let the model change from one pull request to the next.

The short answer

Run the cheap model on every pull request and add the stronger one when the cheap model flags something. On 50 pull requests, that found 120 verified bugs for $4.13, against 108 for $4.15 with GPT-5.6 Sol alone. Precision fell from 86% to 77%, so developers see more comments that turn out to be wrong.

How we ran it

We made no new model calls for this post. Everything comes from the saved reviews behind the Luna vs Astra post.

The setup is unchanged:

• Pull requests: the 50 public benchmark PRs in AI-Code-Review-Evals, ten each from Cal.com, Sentry, Discourse, Keycloak and Grafana.
• Reviews: GPT-5.6 Luna, GPT-5.6 Sol and GPT-6 Astra each reviewed every PR once, with the same bug-only prompt.
• Verification: GPT-6 Astra and GPT-5.6 Sol judged a pooled, anonymized list of findings per PR. A bug counts only when both judges call it real. 143 distinct bugs passed.

A routing policy decides which model reviews each PR. We replayed each policy against the saved results, adding up the verified bugs found and what those reviews cost. Where a policy runs two models on a PR, a bug both models found counts once.

What we compared

We tested three kinds of policy.

1. One model everywhere. Luna, Sol or Astra on all 50 PRs.
2. Pick the model before the review. Send a fixed set of PRs to Sol and the rest to Luna. We tried an auth-keyword rule on file paths and titles, the largest diffs, and a random choice as the baseline. Each sends 18 PRs to Sol.
3. Escalate after the cheap review. Luna reviews every PR. Sol also reviews it when Luna raised at least 1, 2 or 3 findings. We report all three thresholds.

We also computed a ceiling: for each PR, the cheapest single model that found the most verified bugs. It uses the answers, so no real system can match it. It shows how much room per-PR choice leaves.

The results

The escalation line sits above everything else at a similar cost:

• At 1+ findings, Sol reviewed 45 of 50 PRs on top of Luna. That found 12 more verified bugs than Sol alone for the same money, because Luna's review adds almost nothing to the bill, and it's the clearest result in the data.
• At 2+ findings, Sol reviewed 29 PRs. It found 111 bugs to Sol's 108 for 26% less. A 3-bug difference is within the run-to-run variation we measured in the last post, so read this one as "about the same bugs for a quarter less."
• At 3+ findings, Sol reviewed 16 PRs. It found 99 of Sol's 108 for 48% of Sol's cost, and more than Astra-on-everything (92) for 35% of Astra's cost.

Picking the best single model per PR, which needs the answers in advance, would have found 114 bugs for 27% less than Sol alone. Luna was that pick on 18 of the 45 PRs with a verified bug. On those, the $1.20 model matched or beat both frontier models.

Why the cheap model's output worked as a signal

The escalation rule uses something you only have after the cheap review: how much Luna found. That turned out to be a better guide than anything we could see in the diff beforehand.

The auth-keyword rule was our first idea, since Luna fell furthest behind on Keycloak's authentication code in the last post. It picked 18 PRs, 9 of them from Keycloak. It still beat random choice by only 3 verified bugs. Routing the largest diffs did 11 bugs better than the keyword rule.

On the PRs the rule flagged, Luna found 43% of the verified bugs and Sol found 75%. On the rest, Luna found 51% and Sol 76%. Sol's edge was 32 points on flagged PRs and 25 on the rest. That difference is real but small, and the flagged PRs were also more expensive to review ($2.00 against $1.63 for a random pick), so the rule bought few extra bugs for the money.

Our read is that Luna's finding count works because it measures the PR through the review itself. A PR where the cheap model raises several issues is usually a PR with several things wrong, and that's where a second, stronger review pays off.

The cost you pay in review comments

On an escalated PR, the developer sees Luna's findings and Sol's, including the ones that don't hold up.

At the 1+ threshold, 35 findings didn't hold up, against 18 for Sol alone. That's 17 more comments someone has to read and dismiss across 50 PRs.

Whether that's worth 12 extra bugs depends on the team. There are two easy ways to cut the noise:

• Post only the stronger model's findings on escalated PRs, and use the cheap model's output purely as the trigger.
• Raise the threshold to 3+, which cuts the spend by 36% at the same precision.

We didn't replay the first option, because it changes which bugs get reported. It's the next thing we'd test.

Limits of this comparison

• Small sample. 50 PRs is enough to see a pattern and not enough to set a threshold for your codebase.
• Thresholds chosen after the fact. We tested three and report all three. A real deployment should pick its threshold on held-out PRs.
• One run per model. The Luna vs Astra post showed results move between runs, especially for Luna.
• Judge overlap. Sol and Astra are both judges and both contestants. Luna isn't a judge, which could slightly understate it.
• Replayed, not live. Latency and the cost of the orchestration itself aren't included.

What this means beyond code review

This benchmark routes code reviews, one pull request at a time. The same idea applies anywhere a team runs AI on units of work that vary in difficulty: most units don't need the strongest model, and the useful question is which ones do.

For coding agents, Entelligence Model Router makes that choice on every turn. It evaluates each turn and routes it through an efficient, mid-tier or frontier lane based on task difficulty, latency and cost. It works with agents like Claude Code, Codex, Cursor and OpenCode. On Terminal-Bench, it solved 71 of 89 tasks while spending 65.5% less than Claude Opus 5 alone. That's our own benchmark, so read it the same way you'd read this one.

Both results point the same way. Choosing the model per unit of work found more bugs than any fixed choice at the same cost, and a signal from the work itself beat a rule written from file names.

Running this on your own reviews

1. Save every AI review with its cost, and record which findings your team accepted or fixed.
2. Run a cheap model on every PR for a few weeks, and a stronger model on a random sample.
3. Replay escalation thresholds against that sample before you change anything live.
4. Track precision next to bugs found, since the extra comments are what developers notice first.

Summary

Running the cheap model everywhere and escalating on its own findings beat every single-model setup at the same cost. At Sol's price it found 12 more verified bugs than GPT-5.6 Sol, and a stricter threshold roughly matched Sol for 26% less. Both come with more comments to dismiss. The routing rule we expected to work, sending auth code to the stronger model, barely beat random.

See how Entelligence Model Router picks a model per turn for coding agents.

Methodology: saved reviews of 50 public pull requests from AI-Code-Review-Evals by GPT-5.6 Luna, GPT-5.6 Sol and GPT-6 Astra, one run each, identical bug-only prompt, September 2026. Findings were pooled per PR and judged separately by GPT-6 Astra and GPT-5.6 Sol; a bug counts only where both agreed. Routing policies were replayed over these results with no new model calls. Costs are the recorded API cost of each review at $0.20/$1.20 (Luna), $4/$20 (Sol) and $10/$50 (Astra) per million input/output tokens.