Claude Code Review: Complete 2026 Guide to a Costly Mistake

17 min read

Search for Claude Code Review and Google hands you results about three different products. One is a managed GitHub service most readers cannot switch on. One is a terminal command that ships free with the tool. One is a cloud review that bills separately and gives Pro users exactly three free runs, ever. They share a name, they do not share a price, and the coverage that travels furthest is about the one with the highest barrier to entry.

This guide separates them, prices each one from Anthropic’s own documentation, and is careful about what the published numbers actually establish.

Claude Code Review Is Three Products Sharing One Name

The confusion is not the reader’s fault. Anthropic ships all three under overlapping names, and the local command has been renamed twice. Here is the map, drawn entirely from the official documentation.

The costly mistake in the headline is treating one of these as the whole picture: teams budget for the managed service when the free terminal command would have covered their use, or individual developers read a glowing writeup and discover at signup that it is gated behind a Team plan.

How the Managed Service Works

The managed service is the one Anthropic announced on 9 March 2026. Its documentation opens with a restriction most summaries bury: “Code Review is in research preview, available for Team and Enterprise subscriptions.” It is also unavailable to organisations running Zero Data Retention.

When a review runs, several agents examine the diff in parallel against the surrounding codebase, each looking for a different class of problem. A separate verification step then checks each candidate finding against actual code behaviour before anything is posted. Surviving findings are deduplicated, ranked, and attached as inline comments on the specific lines involved.

Anthropic is explicit that this is advisory, not gating: “Findings are tagged by severity and don’t approve or block your PR, so existing review workflows stay intact.” The check run “always completes with a neutral conclusion so it never blocks merging through branch protection rules.” If you want a hard gate, you have to build it yourself by parsing the check run output.

The three severity markers

Every finding from the managed service carries one of three markers:

• 🔴 Important — a bug that should be fixed before merging
• 🟡 Nit — a minor issue, worth fixing but not blocking
• 🟣 Pre-existing — a bug that exists in the codebase but was not introduced by this PR

The pre-existing category is the easiest one to miss when you are planning a rollout. It means the reviewer reports bugs your diff merely walked past — useful on a neglected codebase, and a source of volume nobody budgets for. Anthropic documents it plainly in the severity table, and the nit caps and skip rules in REVIEW.md exist partly to control it.

Scope: correctness, not style

The documentation sets the default scope narrowly: “By default, Code Review focuses on correctness: bugs that would break production, not formatting preferences or missing test coverage.” If you were hoping to replace a linter or a coverage gate, that is not what this is.

What Anthropic’s Own Numbers Say, and the Condition Everyone Drops

The launch post publishes several figures, all measured on Anthropic’s own codebase:

• “Before, 16% of PRs got substantive review comments. Now 54% do.”
• On large PRs over 1,000 lines changed: “84% get findings, averaging 7.5 issues”
• On small PRs under 50 lines: “31%, averaging 0.5 issues”
• “less than 1% of findings are marked incorrect”

The number that travels is 84%. The condition attached to it usually does not. Read the pair together and the picture changes: on a PR under 50 lines — which is the size most teams are told to aim for — findings appear about 31% of the time, and the average across all such PRs is half an issue.

That is not a criticism of the tool. Big diffs are where review attention is scarcest and bugs hide best, so a reviewer that scales its output with diff size is behaving sensibly. It is a criticism of how the statistic gets quoted, and a warning against buying the tool for a workflow built on small PRs.

On Anthropic’s own codebase, findings appear on about 31% of PRs under 50 lines. The 84% figure that circulates belongs to PRs over 1,000 lines.

What the Numbers Do Not Establish

Two caveats belong next to these figures, and Anthropic states the first itself. They are self-reported, measured internally on one company’s repository — a codebase with a house style, a CLAUDE.md, and engineers who know how the reviewer behaves. Nothing published shows it achieving the same rates on an unfamiliar codebase.

The second is subtler. “less than 1% of findings are marked incorrect” measures what reviewers bothered to flag as wrong using the thumbs-down button, which is not the same quantity as a false-positive rate. A finding nobody rates is not a finding nobody disputed.

The most useful public account of day-to-day behaviour comes from the Hacker News launch thread, where jgraettinger1 described asking Claude or Codex to review staged work as a regular habit, usually after reviewing it himself:

“It will always find about 8 issues. The number doesn’t change, but it gets a bit … weird if it can’t really find a defect. Part of the art of using the tool is recognizing this is happening, and understanding it’s scraping the bottom of its barrel. However, if there are defects, it’s quite good at finding and surfacing them prominently.”

Read in full, that is not a debunking — it is a working practitioner’s calibration note, and it is more useful than either the marketing or the backlash. The finding count is a poor signal. The finding quality is the signal, and it degrades gracefully rather than failing loudly when there is nothing to find. Note also that he is describing his own review habit across two vendors’ tools, not the managed Code Review service specifically.

What It Costs, and the Setting That Matters More

Pricing is stated plainly: “Each review averages $15-25 in cost, scaling with PR size, codebase complexity, and how many issues require verification.” Crucially, “Code Review usage is billed separately through usage credits and does not count against your plan’s included usage.” Your Team seats do not cover it.

The per-review price is not the expensive part. The trigger setting is. Each repository gets a Review Behavior dropdown with three options — once after PR creation, after every push, or manual — and the documentation says outright that “Reviewing on every push runs the most reviews and costs the most.” A PR that takes eleven pushes to land costs eleven reviews.

The per-review price is not the expensive part of Claude Code Review. The trigger setting is.

On Hacker News, nnennahacks ran the arithmetic upward:

“If you’re a big shop pushing, say, 2,000 PRs a week and reviews average $15–25, that’s on the order of $30k–$50k a week in AI review spend, or $1.5-2.5M a year.”

That figure assumes one review per PR. On the every-push setting it is a floor, not a ceiling.

There is a guardrail. Organisations can set a monthly spend cap, and when it is reached, Code Review posts a single comment on the PR explaining the review was skipped rather than failing silently. Reviews resume at the start of the next billing period or as soon as an admin raises the cap. Set the cap before you set the trigger, not after.

The Free Path: A Code Review in Your Terminal

This is the version of Claude Code Review most readers actually need, and it is the least written about. The /code-review command runs a review of your working diff locally, on any plan, without installing a GitHub App. Per the documentation, it “reports correctness bugs and reuse, simplification, and efficiency cleanups.”

/code-review

With no argument it reviews your branch’s commits ahead of upstream plus any uncommitted changes. You can point it elsewhere with a file path, a PR number, a branch name, or a ref range:

# review a specific range
/code-review main...my-feature

# review and apply the findings to your working tree
/code-review --fix

# review and post findings as inline PR comments
/code-review --comment

Two behaviours are worth knowing before you rely on it. By default it runs as a background subagent with its own context window, so it does not fill your conversation — but that also means --fix edits land outside your session’s checkpoints, and /rewind will not undo them. Use git to revert. When the review runs in the foreground instead, it edits during your own turn and /rewind restores its edits as usual.

The local review also reads your project instructions but not your review-specific ones: “The review follows your CLAUDE.md like any Claude Code session, but it doesn’t read REVIEW.md.”

The command has been renamed twice, which is why older guides disagree about it. /review is now an alias for /code-review; before v2.1.223 it was a separate command that ran a single-pass read-only review of a GitHub PR. And before v2.1.147 the command was called /simplify, which still exists today as a narrower, separate command that applies cleanups without hunting for bugs. If you scripted either, check what you are actually invoking.

Ultrareview: The Middle Tier Most Guides Skip

Between the free local command and the managed service sits /code-review ultra, which uploads your branch to a remote sandbox and runs a larger fleet of agents against it. Its documentation carries the same warning label as the managed service: “Ultrareview is a research preview feature. The feature, pricing, and availability may change based on feedback.”

Its selling point over the local review is verification — “every reported finding is independently reproduced and verified, so the results focus on real bugs rather than style suggestions.” A run typically takes five to ten minutes.

The pricing has a trap in it. Pro and Max accounts get three free runs, and the documentation is unusually direct that “the three Pro and Max runs are a one-time allotment per account and don’t refresh.” Team and Enterprise get none. After that it is roughly $5 to $25 per review in usage credits, and your account or organisation must have usage credits switched on before a paid run will launch at all. Worse, “A review you stop early or that fails to complete still uses a free run” — so a mistyped branch name can burn a third of your lifetime allowance.

Note that published figures for this feature have moved. A widely-linked May 2026 writeup states the cost as “costs $5–$20 per run after your first three free ones on Pro or Max plans”, where the current documentation says $5 to $25. Both may have been accurate when written. For a research-preview feature, check the docs rather than any guide, including this one.

Tuning the Managed Service With CLAUDE.md and REVIEW.md

The managed service reads two files from your repository, and they are not interchangeable.

CLAUDE.md is your general project context. Code Review reads it and treats newly introduced violations as nit-level findings — never Important, unless you say otherwise. It also works in reverse: if your PR makes a statement in CLAUDE.md outdated, Claude flags that the docs need updating.

REVIEW.md is review-only, sits at the repository root, and reaches the finding and verification agents directly. It is the stronger lever. The documentation lists what it is actually good for — redefining what Important means for your repo, capping how many nits a single review posts, listing paths to skip, adding repo-specific checks, and raising the evidence bar before a class of finding gets posted.

One warning from Anthropic that is easy to ignore: “a long REVIEW.md dilutes the rules that matter most.” The file is read as plain text, and @ import syntax is not expanded, so referenced files are not pulled in. Put the rules in the file itself.

Four Setup Traps to Know About

1. Private organisation membership silently blocks the trigger

This is the most under-documented failure and it looks like a bug. If your GitHub organisation membership is private — which is GitHub’s default — GitHub does not identify you to Claude as a member. The documentation is precise about what you see: “Claude may still react to your comment with 👀, but it doesn’t start a review unless you were added to the repository directly as a collaborator, even when a team or the organization’s base permissions give you write access.” The eyes emoji appears, nothing happens, and you assume the service is broken. Fix it by making your membership public or being added as a direct collaborator.

2. The July 2026 change to @claude review

The command’s meaning changed mid-year: “Before a July 2026 update, @claude review subscribed the PR to push-triggered reviews.” It no longer does. If you followed a guide written before July and expected every subsequent push to be reviewed, use @claude review always instead. Any tutorial that does not mention this is describing the old behaviour.

3. Fork pull requests are never reviewed automatically

“Claude doesn’t review a pull request from a fork automatically, regardless of the repository’s Review Behavior setting.” Only a comment command starts one. Clicking Re-run does not. Pushing new commits does not, even on the every-push setting. For an open-source project taking outside contributions, this is the difference between the feature working and the feature never firing.

4. Replies do not reach Claude

“Replying to an inline comment does not prompt Claude to respond or update the PR.” To act on a finding you fix the code and push, or request a fresh review with a top-level comment. Threads of developers arguing with a bot that cannot hear them are a predictable outcome of not knowing this.

What the Other Guides Get Right and Wrong

In fairness to the field, the coverage here is better than the usual pattern for a new vendor feature. CodeAnt AI’s writeup states the plan restriction correctly — “Claude Code Review is not available to individual developers on Pro or Max plans” — carries the $15–25 figure, correctly attaches the 84% to PRs over 1,000 lines, and has a comparison table covering all three products. It is also published by a company selling a competing review product, which is worth knowing while reading it.

The gaps are narrower and more specific than “nobody explains the pricing”. The New Stack’s launch coverage reports the figures and the $15–25 average accurately but does not use the phrase research preview anywhere, which is the single most consequential fact for a reader deciding whether to plan around the feature. The widely-linked ultrareview writeup covers the local-versus-cloud split well while not addressing the managed GitHub service at all, and quotes an ultrareview price that no longer matches the documentation.

The pattern worth noticing is that each guide is accurate about the product it chose and silent about the other two. That is why the same reader can come away from two well-researched articles with two incompatible ideas of what Claude Code Review is and what Claude Code Review costs.

Should You Turn It On?

A defensible reading of the evidence:

• Individual developer on Pro or Max: you cannot use the managed service. Use /code-review locally, which costs you nothing beyond normal plan usage, and spend your three ultrareview runs on changes that genuinely worry you.
• Small team, small PRs: the vendor’s own data says findings on sub-50-line PRs are the exception. Run Claude Code Review on manual mode and use @claude review on the PRs that matter, rather than paying $15–25 per PR to be told nothing is wrong.
• Larger team with big PRs: this is the case the published numbers actually support. Set a spend cap before you set a trigger, and avoid every-push until you have a real cost-per-PR figure from your own repository.
• Anyone on Zero Data Retention: the managed service and ultrareview are both unavailable. Anyone on Bedrock, Google Cloud’s Agent Platform, or Microsoft Foundry: only ultrareview is unavailable — the managed GitHub service still works. The local command works everywhere.

The honest summary is that Claude Code Review has a real published track record on one company’s codebase and very little public evidence about anyone else’s. The practitioner accounts that do exist suggest the finding count is noise and the finding quality is signal. Run it on one repository, at manual trigger, for a month, and you will know more about your own codebase than any article can tell you.

If you are comparing AI coding tools more broadly, our AI coding tools hub breaks the space into the three categories that matter, and our breakdown of how Gemini 3.7 Flash stacks up against Claude Code and GitHub Copilot covers the wider field, and our guide to whether AI generated code can be detected looks at the review problem from the opposite direction. The official announcement is on the Claude blog.

Claude Code Review FAQ