GPT-5.6 루나 vs GPT-6 아스트라: 1.2달러 모델로 코드 리뷰가 가능할까?

GPT-5.6 Luna vs GPT-6 Astra: Is a $1.20 Model Good Enough for Code Review? Aditya Jha Sep 14, 2026 Aditya Jha Sep 14, 2026 GPT-5.6 Luna costs $0.20 per million input tokens and $1.20 per million output tokens. GPT-6 Astra costs $10 and $50. On the same pull requests, one Luna review cost $0.0041 and one Astra review cost $0.113, a 28x difference. Our last post compared Astra with GPT-5.6 Sol. This time we wanted to know what you give up if every pull request goes through the cheapest model. The short answer Luna found 69 verified bugs across 50 pull requests. Astra found 92. Luna cost $0.20 for the whole run and Astra cost $5.66. Luna was wrong more often, with 24 of its 93 findings failing verification against Astra's 4 of 96, and it found 9 of the 24 security bugs where Astra found 19. Our read: Luna is good enough for everyday correctness bugs at that price, and we wouldn't let it review authentication or permission code on its own. How we ran it We reused the setup from the Astra vs Sol post so the numbers line up. The pull requests are the 50 public benchmark PRs in the AI-Code-Review-Evals organization, ten each from Cal.com, Sentry, Discourse, Keycloak and Grafana. Each one introduces defects against a clean base branch. Luna and Astra got the same prompt on the same diffs. The prompt asks for correctness, security, concurrency, resource and error-handling bugs, and excludes style, naming, docs and test suggestions. Each model returned structured findings. Verification works the same way as before. For every pull request, the findings from Astra, Sol, Luna and the public Entelligence reviewer comments go into one anonymized list. GPT-6 Astra and GPT-5.6 Sol each judge that list separately against the diff, grouping duplicates and deciding whether each issue is a real bug. An issue only counts as verified when both judges call it real. They agreed on 91% of findings, and 143 distinct bugs passed both. Adding Luna's findings changed the pool the judges saw, so everything was judged again. Astra's verified count moved from 91 in the last post to 92 here, and Sol's from 107 to 108. Astra is also one of the two judges, which could favor it slightly. The limits section covers that. The results Luna found 75% as many verified bugs as Astra for 3.6% of the money. Per verified bug, Astra cost 20x more. Luna wrote 3.1x as many output tokens per review as Astra and still came in far cheaper, because its output price is 42x lower. It was also faster, at 23 seconds per review against 36. Your team would feel the precision gap first. About one Luna comment in four was wrong, while Astra was wrong 4 times in 96. Developers who already skim AI review comments will skim harder when a quarter of them are noise. Where Luna falls behind Readers of the last post asked us to split results by codebase and by bug type, because an overall score can hide a model that does well on one repository and badly on another. On this data, the split shows where Luna's missing bugs come from. In Sentry, Discourse and Grafana, Luna came within two verified bugs of Astra. Cal.com had a wider gap, 21 to 30. Keycloak had the widest: Luna found 6 verified bugs to Astra's 14, and only 50% of its Keycloak findings held up, against 93% for Astra. Keycloak is an identity and access management server, and most of its benchmark PRs change authentication and permission logic. The bug-class split points the same way. We labeled every verified bug by root cause. GPT-5.6 Sol, which isn't one of the two models compared here, labeled all 143 bugs in one pass against written definitions. The labels are committed alongside the benchmark data so anyone can check them. On data and logic bugs, the largest group, Luna found 39 to Astra's 47. On concurrency it found 10 to 13. On security, Luna found 9 of 24 and Astra found 19. Two of the Keycloak bugs Astra caught and Luna didn't: Federated recovery codes were never marked as used, so a recovery code could be used more than once. A global view permission overrode denials set on individual clients. Neither looks wrong on any single line. You only see them by working out what the permission model allows after the change. What Luna catches that Astra misses Luna also found bugs Astra missed. Of the 143 verified bugs, 44 were found by both models, 48 only by Astra, and 25 only by Luna. Of the 25 Luna-only bugs, 16 are data and logic bugs and 4 are concurrency bugs. In Discourse, repeating an unsubscribe request kept lowering a user's notification level. In Sentry, a concurrency bug replaced unhealthy worker threads without stopping the old ones. Running both models on every pull request would have found 117 of the 143 verified bugs (82%) for $5.86 in total. That is Luna's $0.20 on top of Astra's $5.66, for 25 more verified bugs. What readers asked us to check Did the models just remember the fixes? One reader pointed out that these repositories are public, and the fixes for the benchmark bugs may sit in their history. A model trained after those fixes landed could be recalling a patch it has already seen. The suggested test was to split the pull requests by date and see whether the ranking holds on changes made after each model's training cutoff. We can't run that split on this benchmark. We pulled the commit date behind every PR, and they range from 2013 to July 25, 2025. 20 are from 2025, and none are recent enough to fall after either model's cutoff. The post-cutoff group would be empty. The risk is smaller than it sounds, because the defects were added to these PRs for the benchmark on purpose, so the exact bug in each diff is not a commit a model could have trained on. The surrounding code is old and public, though, and a model that knows what the correct version looks like has an advantage. Testing that properly needs pull requests newer than the models, and this benchmark can't provide them. Do the models find the same bugs twice? Another reader asked us to rerun some PRs with identical settings. We picked two PRs per codebase and ran each model two more times. From its first run, Astra had 15 verified bugs on those ten PRs. 10 came back in both repeats and 14 in at least one. Luna also had 15. 7 came back in both repeats and 12 in at least one. The sample is small, so treat these as rough. A model that finds a bug on one run can miss it on the next, which applies to every single-run number in this post, and Luna did it more often than Astra. What about bugs nobody flagged? The third request was to track false negatives, meaning real bugs every model missed. Measuring that needs a complete list of the bugs in each PR, which the benchmark doesn't publish. We can give a lower bound. 26 verified bugs were missed by both Luna and Astra and caught only by Sol or the Entelligence reviewer. Two of them are the Discourse security bugs from our last post: a postMessage origin check that used a substring match, and a remote fetch that followed redirects past a host allowlist. The true number of missed bugs is higher, because bugs no reviewer flagged never enter the pool. Limits of this comparison Apart from the ten repeated PRs, each model reviewed each PR once, and the repeat runs show that results move between runs. Astra is both a contestant and one of the two judges. Requiring Sol to agree reduces the bias without removing it. Every PR predates both models' training cutoffs, so the date split readers asked for isn't possible here. Both models saw the diff and nothing else. They had no repository history, call graph, or production data. Verified counts are a floor on the bugs present, and the benchmark has no complete bug list to measure against. What a diff doesn't tell the model On this benchmark, a cheap model did well on most changes and badly on authentication and permission code. A diff alone doesn't tell the model which kind of change it is reviewing. Knowing that a file sits on an authorization path, that a function is called from a login flow, or