Most "best AI code review tool" comparisons start and end with a benchmark score. That score hides almost everything a team needs to decide with. The useful move is to read the method behind the number, because the number only means what the method lets it mean.
Entelligence published a comparison last week between two models on the same pull requests: GPT-5.6 Luna at $0.20 per million input tokens against GPT-6 Astra at $10. One Luna review cost $0.0041, one Astra review cost $0.113, a 28x gap (Entelligence, Sep 14 2026). It is a vendor benchmark and the model that is also a judge in its own verification could be favored, so treat the scores as direction, not law. But the post is worth reading for what it does right, and for what it shows a comparison needs before it is useful.
What the aggregate score hides. Overall, Luna found 69 verified bugs to Astra's 92, with 74% precision against 96%. Those two numbers are the ones a headline picks up. The post then splits by codebase, and the aggregate falls apart. In Sentry, Discourse and Grafana, Luna came within two verified bugs of Astra. In Cal.com the gap widened to 21 versus 30. In Keycloak, an identity and access management server, Luna found 6 verified bugs to Astra's 14 and only half its findings held up, against 93% for Astra. On security bugs specifically, Luna caught 9 of 24 and Astra 19.
So the headline answer to "is the cheap model good enough" is wrong for every codebase at once. It is good enough for the everyday correctness bugs in SDK and forum code, and it is not good enough for auth. Two of the bugs it missed on Keycloak only show up by reasoning about the permission model after the change: a global view permission overriding denials on individual clients, and federated recovery codes never marked as used so they could be used more than once. No single line looks wrong. That is the class of bug that decides whether a tool watches your auth code or not.
What it leaves out. The authors are honest about the biggest gap. Every PR in the benchmark includes a defect added on purpose, so none of those exact bugs are in the models' training data. But the surrounding code is public and old, with commit dates back to 2013, so a model that has seen the correct version of a file has a real advantage. There is no way to test that split here because none of the PRs fall after either model's training cutoff. That is a real limitation: it is common to almost every public code review benchmark, and it means the scores above likely overstate how these models will do on your codebase, which the model has never seen.
The repeatability check is the most useful part. The authors reran two PRs per codebase a second and third time. On ten PRs, Luna had 15 verified bugs on its first run, but only 7 came back in both repeats and 12 in at least one. Astra had 15 verified, with 10 in both repeats and 14 in at least one. The sample is small, so treat it as rough, but it makes a point that no aggregate score will ever show you: a model that finds a bug on one run can miss it on the next. Single-run benchmarks flatten that variance into a number, and the number looks more stable than the tool is.
What to actually do with this. The practical lesson is not which model won. It is that a comparison only earns your attention if it tells you both where the tool is strong and where it is weak, and if it tells you on what baseline it measured. Ask for the split by codebase and by bug class, ask whether the benchmark PRs are newer than the model's training data, and ask what the precision was on the code you actually write. An overall score answers none of those. A method does.
The load that an AI review tool puts back on your human reviewers is roughly its error rate, because a wrong comment still has to be read, ranked and dismissed. When a quarter of a cheap model's findings are noise, that is not a free tier, it is a tax on every developer who opens the diff.
