Most AI code reviewers fail in one of two directions: they flood the PR with style nits, or they stay so quiet they miss the bug. Claude Opus 5 is notable for being good in both directions at once — a high rate of genuine bugs found, with the extra findings mostly real rather than noise.
This page is written for teams running AI-assisted pull request review. If you want the model overview first, start with the complete Claude Opus 5 guide.
| Best effort level | high |
| Context available | 1M tokens — enough for real working material, not just snippets |
| Cost | $5 per million input tokens, $25 per million output |
Why Claude Opus 5 suits code review
- High precision and high recall at the same time, rather than trading one for the other.
- It stays accurate at lower effort levels, which makes a cheap fast pass at commit time plus a thorough pass at review time genuinely practical.
- Long context means it can read the diff and the surrounding modules, so it catches the bug that only exists because of what the caller does.
- It explains findings clearly enough to act on without re-reading the code yourself.
A workflow that works
- Run a cheap pass early. Low or medium effort on each commit catches the obvious class of mistake before review.
- Run a thorough pass at PR time at
highorxhigh, with the full diff plus the files it touches. - Ask for coverage, not curation — see the pitfall below. Let a second pass or a human rank the findings.
- Have it report confidence and severity per finding, so you can filter downstream instead of asking the model to filter for you.
- Feed test output back in. It reasons well about intermittent failures and will tell you a flake is a flake rather than declaring victory after one green run.
Settings to start from
Set the effort level to high. Review is intelligence-sensitive but rarely latency-sensitive. high is the sweet spot; xhigh is worth testing on security-adjacent or concurrency-heavy code.
Leave adaptive thinking on — it is the default on Claude Opus 5, and turning it off introduces failure modes that are not worth the saving. See effort levels explained if you want to tune this properly.
What to watch out for
- Never write "only report high-severity issues" or "be conservative." Opus 5 follows those instructions literally — it finds the bugs, then declines to report them. Measured recall drops even though the underlying bug-finding got better.
- Security-focused analysis may be refused. Opus 5 ships with elevated cybersecurity safeguards, and benign security work occasionally trips them.
- It is not a substitute for tests. Treat findings as leads, not verdicts.
The verdict
Prompt for coverage and filter afterwards. That single change is usually worth more than any model upgrade.
If cost is the constraint, read how to cut Claude Opus 5 costs before downgrading — routing and caching usually beat switching models.
More on Claude Opus 5
Start with the complete Claude Opus 5 guide for the overview, or go deeper:
Ready to go deeper?
Read the full Claude Opus 5 guideFrequently Asked Questions
Why does Claude Opus 5 find fewer bugs when I ask it to be conservative?
Because it obeys. Instructions like "only report high-severity issues" or "don't nitpick" are followed literally: the model investigates just as thoroughly, identifies the same bugs, then withholds anything it judges below your stated bar. Ask it to report everything with a confidence and severity label, and filter in a separate step.
Can Claude Opus 5 review an entire repository at once?
Within reason. The 1M-token context window fits a large codebase, and the model keeps instruction-following and reasoning quality across the window. In practice, scoping a review to a diff plus the modules it touches produces sharper findings than dumping everything in.
Is a cheaper model good enough for code review?
For a first-pass sweep, often yes. Opus 5's advantage shows on subtle, cross-file, and concurrency bugs. A common setup runs a cheap model on every commit and Opus 5 at pull-request time.
