Opus 5 for code review: Cleaner actionable comments, noisier overall

Anthropic just released Opus 5, the next major version of the Opus family many of us have grown to love (at least until Fable stole the spotlight). It's a good moment to step back and look at how Opus has evolved across our testing at CodeRabbit.

We've put every Opus release on the bench since version 4, so we have a pretty good picture of how it's evolved. Opus 5 is the first release where the story isn't simply "it finds more bugs."

How the Opus family evolved: Opus 4 surface detection → 4.1 actionability → 4.5 system context → 4.7 coverage → 4.8 coverage parity → Opus 5, where precision rises (+4.1 pp) while coverage drops (−5.9 pp) and nitpicks quadruple.

Fig. 1 — Every Opus release climbed the same ladder until now: Opus 5 trades coverage for precision, and adds a 4× nitpick tail.

Opus 5 model review — @coderabbitai

What's new in Opus 5

The release is less of a raw-capability bump than it is a shift in how the model is controlled and where it spends its effort. Five changes matter for review and coding work:

Effort becomes the primary control. Thinking is on by default and can only be disabled at high or lower effort. Task and effort budgets can now be changed per-turn, mid-conversation, without invalidating the cache. Our data backs the framing: effort was a routing decision — x-high bought a precision gain at a coverage cost, and nothing improved uniformly.
Long context, claimed stable. The context window moves to 1M tokens as both default and maximum, with performance claimed to hold throughout. This directly addresses the 200k-token degradation we reported on Opus 4.8.
Long-horizon agentic work is the headline strength. Guidance recommends a complete task specification up front, longer autonomous sessions, and multi-agent writer-verifier patterns.
Behavioral shifts that change prompts. The model follows review instructions literally (conservative language suppresses recall), produces longer default output that responds to prompting rather than the effort setting, verifies its own work without being asked, and can expand task scope. Three of those four show up in our data, unpacked further down.
Elevated cybersecurity safeguards. As we saw with Fable 5, benign security work can occasionally trigger them. It happened less frequently with Opus 5.

What we tested

The comparison covers about ~100 common error patterns (EPs), drawn from verified issues in real open-source pull requests. We ran each configuration three times and compared the averages with three runs of our current production model mix. The comments in this report are post-pipeline outputs, meaning they have already passed through verification, deduplication, and assertive filtering.

Four measurements matter here. Two of them ask "did the model catch the bug?" (counted per known issue); two ask "was the comment worth reading?" (counted per comment):

Actionable pass rate: share of EPs caught by a confident, actionable comment.
Full-stream pass rate: share of EPs caught by any comment class, including outside-diff and assertive/nitpick (low confidence).
Actionable precision: share of actionable comments that hit their target issue.
Full-stream precision: the same, but across every comment the model produced.

We ran three CodeRabbit review configurations: a junior-reviewer profile at the default effort level (medium), a senior-reviewer profile at high effort, and a senior-reviewer profile at x-high effort.

Results table, three-run average over the same 96 evaluation patterns: production baseline catches 61.1% actionable / 63.5% full stream with 23 nitpicks; Opus 5 junior/default 56.9% / 67.0% with 110 nitpicks; senior/high 55.6% / 62.8% with 91; senior/x-high 55.2% / 60.8% with 39.3% actionable precision and 92 nitpicks.

Fig. 2 — Three-run averages across the same evaluation patterns. Orange marks the best rate per column — and the fewest nitpicks.

TL;DR

Opus 5 is not the best general-purpose code reviewer we tested. Its x-high configuration produced a more precise actionable-comment stream than our production baseline, 39.3% versus 35.2%, but caught fewer of the benchmark's known issues, 55.2% versus 61.1%. It also generated roughly four times as many nitpicks, and its precision fell below baseline when we counted the full post-pipeline stream, 28.6% versus 32.8%.

Four-panel comparison, production baseline vs Opus 5 x-high: known issues caught 61.1% vs 55.2%; actionable precision 35.2% vs 39.3%; nitpicks 23 vs 92; full-stream precision 32.8% vs 28.6%. The nitpick tail flips the precision advantage.

Fig. 3 — The headline trade: cleaner actionables, lower coverage — and a nitpick tail that flips the precision advantage once the full stream counts.

Our read is deliberately narrow: Opus 5 may become a useful precision-oriented lane inside a routed ensemble, but these results do not support using it as the only reviewer or as the primary safety net on high-risk changes.

What this means for developers

Opus 5 x-high is not a straightforward upgrade to the production reviewer. It produced the cleanest actionable subset, 39.3% precision versus 35.2%, but caught fewer known issues and generated four times as many nitpicks. For developers, that means just a slightly better chance that an actionable comment is useful, but a greater risk that important issues are missed and more low-value feedback needs triage. The practical fit is as a second, precision-oriented reviewer.

More reasoning did not consistently produce a better review. The junior/default configuration found the most issues when every comment class was counted, but its full-stream precision fell to 26.4% and it produced 110 nitpicks. X-high was more selective among actionable comments, yet remained noisy overall. Teams should therefore treat effort as a choice between failure modes: decide whether the workflow needs broader exploration or a cleaner actionable subset, then measure the filtering burden each choice creates.

Opus 5 is strongest on configuration errors and code quality. It is good at spotting integration details and maintainability problems, although that broader review style also produces more noise. Its weaker areas are logic errors, race conditions, and API misuse. That makes Opus 5 useful as an additional perspective, but not the only reviewer for correctness-heavy changes, especially around concurrency or API behavior.

Category-level signals: configuration errors and code quality promising; null references mixed; logic errors, API misuse, and data validation weaker; race conditions clearly weaker (−10 to −20 pp actionable pass). Directional evidence, not a leaderboard.

Fig. 4 — Category signals: treat the upside as a hypothesis; treat logic, race, and API gaps as routing constraints.

How Opus 5 fits into the recent model landscape

Historical CodeRabbit results provide context, not a leaderboard. The reports used different EP counts, model mixes, judges, prompts, and pipeline versions, so small numeric differences should not be treated as head-to-head wins.

The frontier models have split into two camps: recall-oriented reviewers that catch more and lean on the product to clean up after them, and precision-oriented reviewers that say less and are right more often. GPT-5.6 Sol anchors one end of the spectrum with 69.7% of known issues caught, but only 31.6% of its comments were worth keeping.

Opus 5 x-high anchors the other end of the spectrum with the cleanest actionable stream on the chart at the lowest coverage of any Opus lane we have tested. Its nearest neighbor is Sonnet 5, which reached similar precision earlier. The difference is that Opus 5 holds slightly more coverage, while producing a noisier full stream. Opus 4.8, sitting next to the baseline, remains the family's balanced option.

Scatter chart, cleaner actionable subset vs more known issues caught: Opus 5 x-high at 55.2% caught / 39.3% precise anchors the precision end; GPT-5.6 Sol at 69.7% / 31.6% anchors the recall end; production baseline at 61.1% / 35.2%; Sonnet 5, GPT-5.6 Terra, and Opus 4.8 in between. Directional only.

Fig. 5 — The frontier split: precision-oriented reviewers on the left, recall-oriented on the right. Opus 5 x-high anchors the precision end.

Where Opus 5 shines: code generation

Opus 5 makes a stronger case as a builder than as a reviewer. One of our engineers described it as "less anxious" than earlier Opus models. It takes time to clarify the goal, offers several credible approaches, and handles open-ended projects without rushing into the first solution. It also documents its work thoroughly, which improves explainability, but can consume a lot of tokens.

On larger agentic tasks, Opus 5 coordinated hundreds of background agents and showed much better design judgment than Opus 4.8. It was still slower and less efficient than Fable 5, occasionally hit limits, and remained overly cautious around security-related tasks. Our early read: it is a clear step up from Opus 4.8, especially for ambiguous, design-heavy projects, but it is not a Fable-contestor.

Token consumption per review call

For every review call, Opus 5 reads about 50% more and writes about 65% more than the frontier models in our baseline. It averaged ≈60.5k input tokens per call (55k to 64k depending on configuration) and ≈9.5k output tokens (8.1k to 10.8k), against ≈40.5k in and ≈5.8k out for the GPT-5.6 lanes doing the same job in the same runs. In practice, every Opus 5 review call carries a bigger context in and returns a longer answer back, which is where the comment volume, and part of the cost premium, comes from.

Bar chart, tokens per review call: production baseline reads ≈40.5k and writes ≈5.8k; Opus 5 average reads ≈60.5k and writes ≈9.5k, with whiskers showing junior-to-x-high variation.

Fig. 6 — Bigger context in, longer answer out: where the comment volume and part of the cost premium come from.

X-high was the heaviest writer, producing 10.8k output tokens per call. More effort did not automatically mean more output: high wrote less than junior/default, while x-high increased both thinking and output.

How to evaluate Opus 5 yourself

Don't judge it on one headline score. Opus 5 can produce cleaner actionable comments while missing more known issues and creating more noise overall. Your evaluation needs to capture both what it finds and what developers must sift through.

Test every relevant effort level, including low and medium. More reasoning changed the trade-off in our runs; it did not consistently improve the review.
Compare restrictive prompts with broader reporting followed by filtering. Instructions such as "only report high-severity issues" may suppress useful findings.
Tune conciseness and severity before rollout, and before developers learn to skim the review.
Remove redundant verification instructions and watch their effect on runtime, tokens, and cost.
Break down misses by category and severity. If missing an issue is the expensive failure, pair Opus 5 with a recall-oriented reviewer.

Our verdict: give it a specific role

Opus 5 is easier to recommend as a builder than as a standalone reviewer. For ambiguous, design-heavy coding tasks, it is a meaningful step up from Opus 4.8. It's more deliberate, better at exploring options, and more capable of coordinating complex work. Fable 5 still looks stronger and more efficient for long-running orchestration.

For code review, Opus 5 x-high is a specialist. It produces a cleaner actionable subset, but catches fewer known issues and adds a substantial nitpick tail. Use it where precision matters, pair it with recall-oriented coverage, and filter its output before it reaches developers.

— Hendrik