Claude Code Review is Anthropic's managed service that reviews every pull request in your GitHub repositories: several Claude agents hunt for bugs, a verification step throws out false positives, and the survivors land as inline comments ranked by severity. It left research preview on October 15, 2026 and is only for Claude Team and Enterprise organizations. If you are on Pro or Max, you still get a review by typing /code-review inside Claude Code, which runs in your own session on any plan.

This guide clears up that naming overlap first, then covers setup, comment commands, cost control, a starter REVIEW.md, a merge gate script we tested on sample check run output, and the process Anthropic's own Claude Code team published this week.

Claude Code Review vs /code-review: which one do you have?

Anthropic's Code Review docs list five ways to get Claude to review code. They differ in who starts the review, where it runs and who pays.

OptionStarts whenRuns onWho can use it
Code Review (the service)A PR opens, each push, or an @claude review commentAnthropic's serversTeam and Enterprise orgs on GitHub
/code-reviewYou type itYour Claude Code sessionAny plan
/code-review ultraYou type itA cloud sandboxclaude.ai accounts
Claude Code GitHub ActionYour workflow eventsYour own CI runnersAnyone with an API key
Your own reviewer skill or subagentYou or Claude call itWherever Claude Code runsAnyone who writes one

In plain terms: the service is what an admin turns on once to comment on every pull request, and the command is what a developer runs on their own branch before pushing. Also note that /review is now just an alias of /code-review. Before v2.1.223 it was a separate, single pass, read only review of a GitHub pull request, so older tutorials describe a different command.

How a Claude Code Review works

According to the docs, each review runs in four stages on Anthropic's infrastructure: several agents read the diff and the surrounding code in parallel, a verification step checks their candidate findings against the code, the remaining findings are deduplicated and ranked, and the result is posted on the pull request.

What you see on GitHub:

  • Inline comments on the lines concerned, each tagged 🔴 Important (fix before merging), 🟡 Nit (minor), or 🟣 Pre-existing (a real bug the PR didn't introduce). Many have a collapsed "Why this was flagged" section.
  • A summary in the review body.
  • A check run named Claude Code Review. It concludes as neutral, never as a failure, and the review never approves or blocks the PR. Merging stays a human decision.

The review only reads code: it doesn't build or run anything, and it never pushes commits. By default it focuses on correctness, meaning bugs that would break production, not formatting or missing tests.

Anthropic's GA announcement says most reviews now finish in about 6 to 10 minutes, down from roughly 20 during the preview, and that findings now state the problem, what triggers it and the fix in a few sentences.

How to set up Claude Code Review on GitHub

Setup is done once by an Owner of your Claude organization, and no workflow files go into your repositories. Per the setup guide:

  1. Check eligibility. You need a Team or Enterprise plan and repositories on GitHub (GitHub Enterprise Server and GitHub Enterprise Cloud with data residency also work). It isn't available with Zero Data Retention, the HIPAA configuration or customer managed encryption keys.
  2. In claude.ai, open Admin settings, then Claude Code, then the Code review section, and turn on Allow code review.
  3. Connect GitHub and install the Claude GitHub App on the organization that owns the repositories. Installing it takes a GitHub organization owner. The app asks for a broader permission set than a review uses, because other Claude features share it.
  4. Pick repositories, click Continue, then Finish. If you close the last dialog any other way, the repositories stay added but reviews stay off.
  5. Open a test pull request that is not a draft. A check run named Claude Code Review should appear within a few minutes.

Choose a review level and when reviews run

Two settings decide both quality and spend:

  • Review level: Quick (fastest, cheapest), Standard (the default) or Deep (most thorough, slowest, most expensive). Set one for the organization and override it per repository, for example Deep on your payments service and Quick on internal tools.
  • Review runs: Once after PR creation, After every push, or Manual. New repositories start at After every push, which runs the most reviews, so change this first if cost matters.

Drafts and pull requests from forks are never reviewed automatically, whatever the setting.

Request a review with @claude review

Anyone with write access can start a review by posting a new top level comment on the PR (not an inline comment, not an edited one):

  • @claude review runs one full review of the whole PR now.
  • @claude review always runs one and subscribes that PR to a review on every later push.
  • @claude review once is the same as the plain command.

Look for the check run titled "Code review queued...", not the 👀 reaction. If you also run the Claude Code GitHub Action with its default @claude trigger, both will fire, so give the Action a different trigger_phrase.

To dismiss a finding, resolve its thread. Replying alone doesn't dismiss it, though the next review reads your reply and may resolve the thread itself. Pushing a fix also clears it on the next review.

Claude Code Review cost and how to cap it

There is no flat price per review. The costs page says Code Review is billed on token usage through usage credits, separately from your plan's included usage, and charged to the organization rather than to the developer who asked. Cost per review grows with the review level, the size of the change, the complexity of the surrounding code and how many candidate issues need verifying.

A sensible pilot, following Anthropic's own advice:

  1. Set a monthly spend limit for the Claude Code Review service in claude.ai usage settings.
  2. Turn it on for a few typical repositories with Review runs set to Once after PR creation or Manual.
  3. After several reviews, read the Average cost column in the Repositories table, then multiply by your monthly PR count (and by pushes per PR if you plan to review every push).

When the spend limit, the org limit or the credit balance runs out, reviews are skipped and the PR gets a comment saying why. Eligible Enterprise organizations can claim at least $10,000 in Code Review credits by January 15, 2027; the announcement says those credits expire 30 days after you claim them.

For individuals, local /code-review counts toward your normal plan usage. The cloud /code-review ultra gives Pro and Max accounts three free runs (once per account, they don't refresh), then typically costs $5 to $25 in usage credits per review, according to the ultrareview docs. An ultrareview takes roughly 15 to 25 minutes.

Tune what gets flagged with REVIEW.md

Code Review reads two kinds of file. CLAUDE.md holds project context that every Claude Code task uses (our AGENTS.md guide covers how to write one), and the service flags changes that break its rules. REVIEW.md sits at the repository root and holds rules for reviews only. You can add more REVIEW.md files in subfolders for stricter checks on, say, services/billing/.

Here is a short starter. Keep each rule about a decision the reviewer has to make:

# Review instructions

## What Important means here
Important is for bugs that break behavior, leak data or block a rollback.
Naming, style and refactoring ideas are Nit at most.

## Cap the nits
Report at most five Nits per review.

## Do not report
- Anything CI already enforces (lint, formatting, types)
- Generated files under src/gen/ and any *.lock file

## Always check
- New API routes have an integration test
- Claims about behavior cite a file and line, not a guess from a name

Three details matter:

  • The service reads REVIEW.md from the base or default branch, never from the PR itself, so merge changes to it first. That also stops a PR from rewriting its own review rules.
  • Lowering severity, skipping paths and capping nits are only honored when the default branch is protected (a classic rule or a ruleset).
  • The local /code-review command reads CLAUDE.md but not REVIEW.md. Put rules you want in both places in CLAUDE.md.

Turn findings into a merge gate

Because the check run never fails, it can't block a merge alone. The docs show how to read its machine readable severity counts with the GitHub CLI. We wrapped that in a small gate for CI and tested it on sample check run text with zero, two and missing Important counts:

#!/usr/bin/env bash
# Usage: review-gate.sh OWNER/REPO CHECK_RUN_ID
important=$(gh api "repos/$1/check-runs/$2" --jq \
  '.output.text | (split("bughunter-severity: ")[1] // empty) | split(" -->")[0] | fromjson | .normal')

if [ -z "$important" ]; then
  echo "No verdict from Code Review. Ask a person to look."; exit 1
elif [ "$important" -gt 0 ]; then
  echo "$important Important finding(s) still open."; exit 1
fi
echo "No open Important findings."

The normal key counts Important findings, and it includes older findings whose threads are still open. A missing line means no verdict (a failed, canceled or superseded review), not zero bugs, so the script fails closed. If you would rather block on unresolved threads, GitHub's "require conversation resolution" branch rule does that without a script.

Run /code-review before you push

On any plan, the local command is the fastest feedback loop:

  • /code-review reviews your branch's commits plus uncommitted changes. Add a target such as 1234 (a PR), main...my-feature or src/auth.
  • --fix applies the findings to your working tree, through your normal permission mode. --comment posts them on the GitHub PR.
  • An effort level trades coverage for confidence: /code-review low reports only what it is most sure of, and higher levels widen the search.
  • The review runs as a background subagent with its own context, so it doesn't fill your conversation.

/security-review is a separate command for vulnerability checks, and Anthropic also publishes an MIT licensed security review GitHub Action. If you want reviews inside your own CI, the Claude Code GitHub Action docs include a workflow that runs the code-review plugin on each PR. For a reviewer of your own, write a review skill (see our Agent Skills guide) or a mod (see Claude Code mods).

What the Claude Code team does with it

Anthropic's engineering post, How the Claude Code team does code review (October 15, 2026), is the most useful read for teams. Its main points:

  • Claude verifies its own work (tests, build, a fresh context subagent review) before a PR exists.
  • Every PR gets the AI review plus a separate security review, and every finding must be fixed or resolved with a reason.
  • A classifier sets the number of human approvals by risk, from none for docs and flagged additive changes to two for the most sensitive paths. An agent's approval never counts as a person's.
  • Review has to converge. After three rounds the reviewer asks the author to rethink the approach, and later passes review only the new diff. The team reports first round passes rose from 65% to 78% after that change.

Those are Anthropic's internal results, not a promise for your repository. The lesson travels well: start on one repository, move repeated comments into REVIEW.md, and cap review rounds.

Who should use Claude Code Review

  • Teams already on Claude Team or Enterprise with GitHub: turn it on for one repository on Manual or Once per PR, set a spend limit, and widen from there.
  • Pro and Max users: use /code-review while you work and save /code-review ultra for large changes.
  • GitLab teams: the managed service is GitHub only. Use /code-review --comment (which posts through glab) or Claude in GitLab CI.
  • Teams on Copilot: GitHub Copilot has its own PR review. Our GitHub Copilot vs Claude Code comparison covers how the two products differ, and Claude Code vs Codex vs Gemini CLI compares the terminal agents.

FAQ

Is Claude Code Review free?

No. The managed service bills token usage as usage credits on top of a Team or Enterprise plan, with no flat per review price. The local /code-review command has no extra charge; it counts toward your normal plan or API usage.

Can I use Claude Code Review on a Max plan?

Not the managed GitHub service, which is limited to Team and Enterprise organizations. On Max you can run /code-review in any session and get three free /code-review ultra cloud reviews.

What is the difference between /review and /code-review in Claude Code?

They are now the same command: /review is an alias of /code-review. Before Claude Code v2.1.223, /review was a separate single pass review of a GitHub pull request.

Does Claude Code Review approve or block pull requests?

No. It posts comments and a neutral check run. To block merges you need branch protection that requires resolved conversations, or a CI gate like the script above.

Does Claude Code Review work with GitLab or Bitbucket?

The managed service supports GitHub only, including GitHub Enterprise Server. For GitLab, run /code-review --comment on a merge request or use Claude Code in GitLab CI/CD.

How long does a Claude Code Review take?

Anthropic says most reviews now finish in about 6 to 10 minutes. A cloud ultrareview usually takes 15 to 25 minutes, and a local /code-review takes seconds to a few minutes.