---
title: "Claude Code Review: What It Does, What It Costs, and Whether It's Worth $15-25 a PR (2026)"
description: "Anthropic's multi-agent PR reviewer reads your whole codebase, verifies its findings, and leaves inline comments before a human looks. Here's how it works, what it really costs, and the honest pros and cons."
date: "2026-10-14"
tags: [ai, claude-code, code-review, anthropic, github, developer-tools, pricing]
sources:
  - title: "Code Review (Claude Code docs)"
    url: "https://code.claude.com/docs/en/code-review"
  - title: "Find bugs with ultrareview (Claude Code docs)"
    url: "https://code.claude.com/docs/en/ultrareview"
  - title: "Anthropic rolls out Code Review for Claude Code"
    url: "https://venturebeat.com/ai/anthropic-rolls-out-code-review-for-claude-code-as-it-sues-over-pentagon"
---
Code review is the part of shipping software everyone agrees matters and nobody has time for. You open a 600-line PR, a teammate skims it between meetings, leaves "LGTM 🚀," and the race condition ships on Friday.

Anthropic's answer is Claude Code Review: a fleet of AI agents that reads your pull request against your whole codebase, verifies what it finds, and leaves inline comments before a human ever looks. It's also not cheap. So here's the honest breakdown: what it actually does, every way to run it, what each one costs, and where it falls short.

## Table of Contents
1. [What Claude Code Review Actually Is](#what-it-is)
2. [How a Review Works](#how-it-works)
3. [The Three Ways to Get a Claude Review](#three-ways)
4. [What It Costs](#costs)
5. [Tuning It With REVIEW.md](#review-md)
6. [The Pros](#pros)
7. [The Cons](#cons)
8. [Who Should Actually Pay for It](#who-should-use-it)
9. [TL;DR](#tldr)

---

## What Claude Code Review Actually Is {#what-it-is}

Claude Code Review is a managed GitHub integration. An org admin installs the Claude GitHub App, picks which repos to cover, and from then on Claude reviews pull requests automatically and posts findings as inline comments on the exact lines it's worried about.

A few things make it different from the "paste your diff into a chatbot" approach:

- **It reads the whole codebase, not just the diff.** A change that looks fine in isolation but breaks a caller three files away is exactly what it's built to catch.
- **It's multi-agent.** Several specialized agents each hunt for a different class of problem (logic errors, security holes, broken edge cases, regressions) in parallel.
- **It verifies before it posts.** A separate verification step checks each candidate finding against what the code actually does, to filter out false positives.
- **It never blocks your merge.** The check run always finishes as "neutral." Findings are advice, not a gate, unless you wire up your own CI to make them one.

By default it focuses on **correctness**: bugs that would break production. It deliberately skips formatting opinions and "you should add more tests" nagging. That's a choice I really appreciate.

It launched in March 2026 and is still labeled a **research preview**, available on **Team and Enterprise** plans. It works with GitHub only.

---

## How a Review Works {#how-it-works}

Once it's turned on, each repo gets a **Review Behavior** setting that decides when reviews fire:

| Trigger | When it runs |
|---|---|
| **Once after PR creation** | When a PR opens or is marked ready for review |
| **After every push** | On every push to the PR branch, and it auto-resolves threads when you fix the issue |
| **Manual** | Only when someone comments `@claude review` |

You can also summon it on demand in any mode by leaving a top-level PR comment:

- `@claude review` runs one review
- `@claude review always` runs one review and subscribes the PR to a fresh review on every future push

A review takes about **20 minutes on average**. When it's done, you get inline comments tagged by severity:

| Marker | Severity | What it means |
|---|---|---|
| 🔴 | Important | A bug you should fix before merging |
| 🟡 | Nit | Minor, worth fixing, not blocking |
| 🟣 | Pre-existing | A real bug, but this PR didn't introduce it |

That purple one is sneaky-useful. It's the reviewer saying "not your fault, but while we're here, this was already broken." Every finding also has a collapsed **"Why this was flagged"** section that shows how Claude verified the problem, so you're not just taking its word for it.

There's also a **Claude Code Review** check run next to your CI with a severity table of every finding, and the last line of its output is machine-readable JSON (counts of important, nit, and pre-existing findings). If you want to block merges on red findings, that's your hook.

Two quirks worth knowing up front: replying to a Claude comment does **not** make it respond (fix the code and push instead), and resolving the thread is how you dismiss a finding you disagree with.

---

## The Three Ways to Get a Claude Review {#three-ways}

This is where people get confused, because "Claude code review" now means three different things:

| Option | Where it runs | Best for |
|---|---|---|
| **`/code-review`** in your terminal | Locally, inside your Claude Code session | Fast feedback while you're still writing the code |
| **`/code-review ultra`** (ultrareview) | Anthropic's cloud, multi-agent fleet | A deep pass before merging something big |
| **Code Review** (the GitHub App) | Anthropic's cloud, automatic on every PR | Teams who want every PR reviewed without anyone remembering to ask |

**`/code-review`** is the one most people already have. It reviews your branch (or a file, a branch name, or a PR number) and reports correctness bugs. It runs as a background subagent so it doesn't eat your conversation's context. Handy flags:

- `--fix` applies the findings to your working tree
- `--comment` posts them to the PR as inline comments
- `/code-review low` for fewer, high-confidence findings, up to `max` for broader coverage

**Ultrareview** (`/code-review ultra`) is the heavyweight version you trigger yourself. It spins up a bigger fleet of reviewer agents in a cloud sandbox, and every finding is independently reproduced before you see it. It takes 15 to 25 minutes and keeps your terminal free while it runs.

**Code Review** (the GitHub App) is the managed, always-on version this post is mostly about. Nobody has to remember to run anything.

---

## What It Costs {#costs}

Here's the part everyone actually clicked for.

| Option | Cost |
|---|---|
| **`/code-review`** (local) | Counts toward your normal Claude plan usage. No extra charge. |
| **Ultrareview** | 3 free runs (one-time, Pro and Max), then roughly **$5-25 per review** in usage credits |
| **Code Review** (GitHub App) | Token-based, averaging **$15-25 per review**, billed as usage credits on top of your plan |

A few important details on the managed Code Review pricing:

- **It does not come out of your plan's included usage.** It's billed separately through usage credits.
- **Bigger PRs cost more.** Cost scales with PR size, codebase complexity, and how many findings need verifying.
- **Your trigger choice is a cost multiplier.** "After every push" runs a full review on every push. A PR with eight pushes is eight reviews. At ~$20 each, that one PR just cost $160.
- **There are guardrails.** Admins can set a monthly spend cap, and there's an analytics dashboard showing PRs reviewed, spend, and an average cost per review for each repo. If you hit the cap, Claude skips the review and leaves one comment saying why. It never blocks the PR.

Quick gut-check math: a team merging **100 PRs a month** on "once after PR creation" lands somewhere around **$1,500-2,500 a month**. Switch to "after every push" and that number can easily double or triple.

Is that expensive? Compared to an engineer's time, not really. One senior engineer spending a focused 30 minutes on a review costs more than $20 in salary. Compared to linters and static analysis that cost basically nothing per run, absolutely.

If you want more control, there's also a fourth route: the **Claude Code GitHub Action** runs Claude inside your own CI, billed at standard API token rates. More setup, more knobs, and you own the workflow.

---

## Tuning It With REVIEW.md {#review-md}

Out of the box, Claude reviews production code against a production-code bar. If that's not your repo, you tune it with two files:

- **`CLAUDE.md`**: your general project instructions. Code Review reads them, flags newly introduced violations as nits, and even flags when your PR makes a `CLAUDE.md` statement out of date.
- **`REVIEW.md`**: review-only instructions that go straight to the agents finding and verifying bugs. This is where the real control lives.

Things you can put in `REVIEW.md`:

- **Redefine severity.** "Only data leaks, broken logic, and non-backward-compatible migrations are Important. Everything else is a Nit at most."
- **Cap the nits.** "Report at most five nits, mention the rest as a count."
- **Skip paths.** Generated code, lockfiles, vendored deps, anything CI already enforces.
- **Add always-check rules.** "New API routes must have an integration test." "Log lines never include emails."
- **Stop the endless re-review loop.** "After the first review, only post Important findings."

That last one matters more than it sounds. Without it, a PR on "after every push" can get a fresh round of style nits on every tiny fix.

Keep it short, though. A long `REVIEW.md` dilutes the rules you actually care about.

---

## The Pros {#pros}

**1. It catches the bugs humans skim past.** Anthropic says that internally, before Code Review, about 16% of their PRs got substantive review comments. After, 54% did. On large PRs (1,000+ lines changed), 84% got findings, averaging about 7.5 issues each.

**2. The noise is low.** Anthropic reports engineers mark under 1% of findings as incorrect. The verification step is doing real work here. (More on how to read that number in the cons.)

**3. It focuses on correctness, not taste.** No bikeshedding about variable names unless you ask for it in `REVIEW.md`.

**4. It doesn't break your workflow.** It never approves, never blocks, and runs alongside your normal CI and human reviewers.

**5. The "pre-existing" tag is genuinely useful.** You find real bugs in old code without the PR author getting blamed for them.

**6. It's configurable without code.** `REVIEW.md` is plain markdown. Anyone on the team can tune it.

**7. Spend is visible and cappable.** Per-repo cost averages, a monthly cap, and a dashboard. No surprise $40k invoice if you set it up right.

---

## The Cons {#cons}

**1. It's expensive at scale.** $15-25 per review is fine for a 10-PR-a-week team. For a busy monorepo with dependabot, it adds up fast, and "after every push" multiplies it.

**2. It's slow.** Twenty minutes on average. Fine for async teams, painful if you're used to sub-minute CI feedback. If you push while it's running, some findings may point at lines that no longer exist.

**3. Team and Enterprise only.** Solo devs and folks on Pro or Max don't get the managed GitHub App. You get `/code-review` locally and ultrareview runs instead.

**4. GitHub only.** No GitLab or Bitbucket for the managed version. (GitLab users can run `/code-review --comment` locally, or set up Claude in their own CI.)

**5. Compliance gaps.** Not available for orgs with Zero Data Retention or the HIPAA configuration, and not covered under Anthropic's BAA. If you're in healthcare or another regulated space, this may be a non-starter today.

**6. It doesn't talk back.** Replying to a comment does nothing. If you think a finding is wrong, you resolve the thread. There's no "actually, this is intentional because..." conversation.

**7. That "under 1% incorrect" stat is softer than it looks.** It counts findings an engineer actively resolved without fixing. It doesn't count the ones people quietly ignored. Good signal, not a full accuracy measure.

**8. It's still a research preview.** Features, pricing, and behavior can change. The `@claude review` command already changed meaning in a July 2026 update (it used to subscribe the PR to future reviews; now you need `@claude review always` for that).

**9. It's not a replacement for a human.** It won't tell you the feature is a bad idea, the architecture is wrong, or the PR solves the wrong problem. It finds bugs. That's it, and that's fine, but don't fire your reviewers.

---

## Who Should Actually Pay for It {#who-should-use-it}

**Worth it:**
- Teams on Team or Enterprise shipping production code where a missed bug costs real money
- Teams where review is the bottleneck and PRs sit for days
- Repos with large, gnarly PRs (that's where the 84% hit rate lives)

**Start with "Manual" mode if:**
- You're cost-sensitive or have a high-traffic repo. Let people opt in with `@claude review` on the PRs that matter, then widen it once you see the per-repo cost.

**Skip the managed version if:**
- You're solo or on Pro/Max. Use `/code-review` while you work, save your 3 free ultrareviews for the scary merges.
- You're on GitLab or Bitbucket, or need ZDR or HIPAA.
- Your PRs are mostly tiny. On PRs under 50 lines, only about 31% get any findings at all.

My honest take: run `/code-review` locally before you even open the PR. It's included in your plan and catches a lot. Then let the managed reviewer or ultrareview be the expensive second opinion on the changes that actually deserve one.

---

## TL;DR {#tldr}

| | `/code-review` | Ultrareview | Code Review (GitHub App) |
|---|---|---|---|
| Runs | Locally | Cloud, on demand | Cloud, automatic on PRs |
| Cost | Included in plan usage | 3 free, then ~$5-25 | ~$15-25 per review |
| Speed | Seconds to minutes | 15-25 min | ~20 min |
| Who gets it | Claude Code users | Pro, Max, and up | Team and Enterprise |
| Best for | Feedback while coding | Big pre-merge changes | Reviewing every PR, hands off |

- **What it does:** multi-agent review of your PR against the whole codebase, verified findings, inline comments tagged 🔴 / 🟡 / 🟣
- **Biggest pro:** catches real bugs with very little noise, especially on big PRs
- **Biggest con:** $15-25 a review adds up fast, and "after every push" multiplies it
- **Pro tip:** write a short `REVIEW.md`, start in Manual mode, set a spend cap

---

**More posts:**
- [Claude Code Mods, Explained: I Built One That Watches My Own Agent](/blog/claude-code-mods-2026)
- [The Habits I Use Coding With Claude (A Security-First, Token-Conscious Workflow)](/blog/senior-dev-habits-coding-with-claude)
- [Claude Code Finally Reads AGENTS.md (Here's Exactly How It Works)](/blog/claude-code-agents-md-support-2026)

---

*// hereshecodes.com*