Claude Code Review Merge Gates, Tools, and Pricing: A Practical Guide

Verified against Anthropic's Code Review and ultrareview documentation as of July 2026. This surface moves fast— check pricing and availability before you budget against any number here.

Part 1 covered which of the five review layers to automate and how to encode that in REVIEW.md. Writing the criteria file is half the job. The other half is what happens once the reviewer finds something — whether it's true that a Claude Code review "can't block a merge," which of five different delivery mechanisms actually fits your team, and what all of this costs once the free runs are gone.

Key takeaways

• The check run's neutral conclusion doesn't mean you can't gate on it: a machine-readable severity payload lets you build your own merge block.

• @claude review silently subscribes a PR to push-triggered reviews — the single-shot command is @claude review once.

• Five delivery mechanisms exist and each does a different job; picking one and expecting it to do all five is the most common tooling mistake.

• Budget off the cost tail, not the average — a monorepo review doesn't cost what a 70-line diff costs.

How to Build a Claude Code Review Merge Gate on a Reviewer That Officially Can't Block

The documentation is explicit: Code Review doesn't approve or block your PR. Findings post as inline comments, and the check run always completes with a neutral conclusion so it never trips branch protection. Every article on this topic stops there and concludes you simply can't gate on it.

That conclusion is wrong, and it's the most useful thing in this whole product that nobody writes about.

Every review writes a severity table into the Claude Code Review check run, and the last line of that check run's output is a machine-readable payload. You can read it from your own CI:

gh api repos/OWNER/REPO/check-runs/CHECK_RUN_ID \

  --jq '.output.text | split("bughunter-severity: ")[1] | split(" -->")[0] | fromjson'

That returns counts per severity — something like {"normal": 2, "nit": 1, "pre_existing": 0}, where normal is the Important count. A non-zero normal means Claude found at least one bug it considers worth fixing before merge.

Which means you can build the gate yourself, in your own required check, on your own terms:

• Advisory (the default): do nothing. Comments stay comments.

• Soft gate: fail your own check when normal > 0, but only on protected paths — src/billing/**, src/auth/**, migrations. Everywhere else, stay advisory.

• Hard gate: fail on any normal > 0, anywhere. Only sane once your precision audit (below) is clearing 80%.

This is the single highest-leverage thing most teams aren't doing. It turns a bot people learn to scroll past into a control with actual consequences — scoped to the paths where consequences are warranted. Start on one directory and watch how fast that directory's REVIEW.md gets tightened once a false positive costs someone a merge.

Two caveats that matter. Runs are best-effort: a failed run posts nothing and doesn't retry on its own, so your gate has to treat "no result" as pass, not fail, or a timeout turns into an outage. And don't build this until precision is actually good — a hard gate on a noisy reviewer isn't a quality control, it's a lesson in how to route around branch protection.

Claude Code Review Options: Five Mechanisms, Five Jobs

Teams routinely pick one of these and expect it to do all five jobs. It won't.

One version note that has broken people's scripts: the local command was called /simplify before v2.1.147. From v2.1.154, /simplify became a separate cleanup-only review that applies fixes without hunting for bugs. If you scripted /simplify expecting bug detection, switch to /code-review --fix.

The custom skill is the option most teams haven't reached for, and it's where the interesting work happens. It's just a markdown file with frontmatter — name, description, allowed tools, model — whose body is the review instruction. That's the entire mechanism.

The wrong use of a skill is "do a code review." The built-in reviewer already does that better, with an agent fleet and a verification pass you'd otherwise have to rebuild from nothing. The right use is the review your team already does by hand and dreads:

• Is this migration backward-compatible with the version currently deployed?

• Is every new user-facing string in the i18n catalogue?

• Does this API change break the mobile client on version N-1?

• Does this endpoint's response shape still match what the OpenAPI spec promises?

• Does this touch a field the data-retention policy says we must not persist?

Narrow, repeatable, expensive to do by hand, cheap to specify. That last one isn't hypothetical — in a regulated environment it's the difference between a routine merge and a compliance incident. If your review surface spans cross-system contracts rather than a single codebase, this overlaps with the broader integration risk covered in our piece on enterprise API integration in Australia.

The rule: generic check, use the built-in reviewer and tune it with REVIEW.md. Check that's yours alone, write a skill.

Five Ways Teams Break Claude Code Review

Every failure mode below is one I've watched a competent team walk into. None of them are stupid mistakes — each is a reasonable default that turns out to be wrong once you've run the tool on a real codebase for a month.

Putting review criteria in CLAUDE.md. The single most common one. The reviewer reads CLAUDE.md, so the rules appear to work — but everything it finds comes back tagged as a nit, because that's the only severity CLAUDE.md violations get. The team concludes the tool has no judgment. It has exactly the judgment its config gave it, in the wrong file. Criteria that need to block go in REVIEW.md — see Part 1.

Running on every push. Reasonable-sounding: catch problems early. In practice you pay for — and are asked to read — a review of every intermediate broken state, at 3–5x the cost of reviewing once, for a quality gain close to zero. Worse, @claude review silently subscribes the PR to this mode even for teams that thought they were in Manual. Review once on PR open; re-read deliberately with @claude review once.

Gating before precision is good. A team sees the severity payload, gets excited, and wires a hard merge block to it in week one. The reviewer's precision is still 50%, so half the blocks are false, and within a sprint the engineers have learned to bypass branch protection — a habit that outlasts the reviewer. Earn the gate. Advisory until precision clears 80%, then soft-gate one protected directory, then widen.

Reading the bot's silence as approval. The check run completes neutral whether the reviewer found nothing or simply didn't run — best-effort means a timeout posts no comment at all. A green-looking PR is not a reviewed PR. If your process treats "no comments" as "Claude approved," a failed run becomes a silent skip on exactly the change nobody else looked at either.

Never revisiting the criteria. REVIEW.md gets written once, during setup, and then rots. The codebase moves, the reviewer keeps flagging the deliberate loose typing in the legacy adapter, engineers start muting it, and six weeks later nobody reads it. Criteria are a living document. Every dismissed finding is a missing line, and the file only converges if someone adds those lines.

The pattern underneath all five: teams treat the reviewer as a product to install rather than a policy to maintain. The install takes an afternoon. The policy is the job.

How to Improve Claude Code Review Accuracy Over Time

Criteria aren't configuration you set once. They're a document maintained against evidence, and almost nobody does this.

Use the built-in signal. Every Code Review comment arrives with 👍 and 👎 already attached. Anthropic collects reaction counts after the PR merges and uses them to tune the reviewer. It costs a click — tell your team to use it. It's worth knowing what reacting doesn't do: it doesn't re-run the review, and replying to an inline comment doesn't prompt Claude to respond. To act on a finding, fix the code and push.

Run a precision audit at four weeks. Pull the last thirty reviews. Classify every comment: acted on, wrong, or irrelevant. Precision — the share of findings that were real and relevant — is the number that decides whether engineers keep reading. Below roughly 60%, they stop, and at that point recall doesn't matter because nobody's looking anymore.

Every dismissed finding is a missing line in REVIEW.md. This is the actual feedback loop. If the reviewer keeps flagging the deliberate loose typing in the legacy adapter, that's not a defect in the reviewer — it's an unwritten rule in your codebase. Write it down. Over two or three cycles the noise floor drops sharply, and permanently, because the rule now lives with the code.

Track the right number. "PRs reviewed" only tells you the tool is running. What matters is already on the analytics dashboard: comments auto-resolved because a developer actually addressed the issue. If that number stays flat while spend climbs, the reviewer is talking to an empty room. Anthropic's own internal benchmark: after deploying Code Review, the share of PRs receiving substantive review comments went from 16% to 54%, with engineers marking fewer than 1% of findings as incorrect. That's the bar. If you're nowhere close, the problem is your criteria, not the model.

Claude Code Review Pricing: What Reviews Actually Cost

Cost is almost entirely absent from public writing on this topic, and it's the first question any engineering manager actually asks.

The documented shape as of mid-2026:

Two corrections to what's floating around elsewhere:

• The free runs are a one-time allotment, not a trial window. Anthropic's docs are explicit that Pro and Max subscribers get three free ultrareview runs per account, that they don't refresh monthly, and that once they're gone every run bills to usage credits. A stopped or failed run still counts against the three. Anthropic hasn't published a fixed calendar date for when the offer itself closes — the current docs describe it as ending "after the free run period ends," without a date — so budget for the runs disappearing per-account rather than assuming a specific cutoff. You also need usage credits enabled before you can launch a paid run at all; Claude Code blocks the attempt and points you to billing settings if you haven't turned that on.

• The $15–$25 average is an average, and the tail runs long. Practitioners have published measurements of a single review costing $31.54 on a 70-line Markdown diff, and $77.96 on a PR in a larger Go codebase. Anthropic's own figure scales with PR size, codebase complexity, and how many findings need verification — and "codebase complexity" is doing a lot of quiet work in that sentence.

Key takeaway: Budget off the tail, not the average. A monorepo doesn't behave like a 70-line diff, and the invoice will say so.

Run that against a team merging forty PRs a week and the reviewer becomes a real line item — plausibly comparable to a headcount fraction. Which makes scope and criteria cost controls, not just quality controls:

• Every-push triggering multiplies spend by your push frequency — typically 3–5x, for a marginal quality gain. And remember @claude review silently enrolls a PR into that mode.

• Excluding generated files removes tokens from the review, not just comments from the PR.

• Effort level is a direct cost dial. Reserve max, and ultrareview, for paths where a defect is genuinely expensive. The rule is simple: run the deep review where a production bug would cost more than the review itself. Short list. Real one.

• Set the monthly spend cap before rollout, not after the first invoice. Code Review supports an organisation-level cap in admin settings. When it's hit, Code Review posts a single comment explaining the review was skipped and resumes next billing period — a far better failure mode than a surprise bill, but only if someone chose the number on purpose.

• Watch the per-repo average cost column. Within a week it'll tell you which repository is quietly eating the budget.

Teams that abandon these tools over cost usually aren't actually paying for review. They're paying for reviews of lockfiles, on every push, at maximum effort.

Here's the version that survives a budget conversation. A team of eight merging forty PRs a week, reviewing once on PR open at the default effort, at the documented $15–$25 average, lands somewhere around $2,600–$4,300 a month. Turn on every-push triggering and stop excluding generated files and that number can triple without anyone deciding it should. Against it: the reviewer exists to catch the class of defect — the double-charge, the missing auth check, the non-reversible migration — where a single production incident costs more in engineer-hours and customer trust than a quarter of review spend. The tool isn't competing with your linter, which is free and which you already half-ignore. It's competing with the cost of the bug it's configured to find. Frame the line item that way and it defends itself; frame it as "AI review, $4k/month" and it dies in the first cost review.

Checklist: Gating, Tooling, and Cost

Scope and cost

• Choose a trigger: once on PR open, unless you have a specific reason to review every push.

• Tell the team: @claude review once, not @claude review, unless they actually mean to subscribe the PR.

• Set effort per code path, not globally. Reserve ultrareview for changes where a bug costs more than the run.

• Set the monthly spend cap before the first full week of use.

• Sanity-check the worst case: what does your largest repo's average review actually cost?

Gate

• Parse the check run's severity payload in your own CI. Start advisory.

• Once precision clears 80%, soft-gate on normal > 0 for protected paths only.

• Confirm the gate fails open when a review times out.

Keep it honest

• Book a thirty-review precision audit for four weeks out. Put it on someone's calendar now.

• After the audit, convert every dismissed finding into a line in REVIEW.md.

Continue the Series

Gating and tooling assume your team can run the managed product at all. A lot of regulated teams can't — Code Review and ultrareview are both unavailable under Zero Data Retention, which rules out exactly the organisations with the strongest case for using them. Part 3 covers that constraint, the prompt-injection risk of running any agent in CI, and what stays firmly a human's job regardless of how good the tooling gets.