Claude Code Review: /code-review vs Ultrareview

Anthropic’s Code Review for Claude Code is getting a lot of attention on X this week, mostly around the managed service that reviews GitHub pull requests for Team and Enterprise organizations. If you are a solo developer, the more useful news is that the same idea comes in three sizes, and two of them work on a personal plan.

This guide covers all three: the local /code-review command, the cloud ultrareview, and the managed Code Review service. Everything here comes from the official docs for Code Review, local review, and ultrareview.

The three options at a glance

There are two more routes in the docs: running Claude in your own CI with GitHub Actions or GitLab CI/CD, and writing your own reviewer as a subagent or skill. Most people should start with the command.

/code-review: the one you will use daily

/code-review is a command you type at the Claude Code prompt. With no target, it reviews your branch’s commits ahead of its upstream plus your uncommitted changes. If there is no upstream, it compares against main.

/code-review

It runs as a background subagent with its own context window, so the review does not fill your conversation. Findings land in your session when it finishes. /review is an alias.

Point it at something else

Type a target after the command. From the local review docs:

Flags worth knowing

• --fix asks Claude to apply the findings to your working tree. Edits still go through your permission mode.
• --comment posts the findings on a GitHub pull request as inline comments, or on a GitLab merge request as a single note (GitLab needs the glab CLI and v2.1.257+).
• --max-findings <n> or --max-findings all changes how many findings come back (v2.1.288+).

You can also pass an effort level. At low, the review reports only the findings it is most confident in, so you get fewer false positives. From medium up to max, coverage widens. If you skip the level, the command reuses the last one you typed, even from an earlier session.

/code-review high --fix src/payments

One gotcha with —fix

A background review applies its --fix edits outside your session’s checkpoints. The docs are explicit: after one, /rewind restores only files Claude had already edited in your conversation, so use git to revert the review’s other edits. Commit before you run --fix and this stops being a problem.

It follows CLAUDE.md

The local review reads your CLAUDE.md, including in a non-interactive -p run. If your project has rules like “no force unwraps in SwiftUI views” or “every network call goes through APIClient”, put them there and the review will check for them. More on how memory files load in Slash Commands & Memory.

If you want Claude to stop starting the review on its own (it can, when you ask in plain language or from a scheduled task), set this in ~/.claude/settings.json:

{
  "skillOverrides": {
    "code-review": "user-invocable-only"
  }
}

Ultrareview: the pre-merge deep pass

Ultrareview is a research preview. When you run /code-review ultra, Claude Code launches a fleet of reviewer agents in a cloud sandbox. According to the ultrareview docs, every reported finding is independently reproduced and verified, and a larger fleet explores the change in parallel.

/code-review ultra
/code-review ultra develop
/code-review ultra 1234
/code-review ultra check my auth changes

The first form reviews your branch against the default branch, including uncommitted and staged changes. Pass a branch name to change the base, a PR number to review a github.com pull request, or a sentence that becomes a note Claude relates the findings to (v2.1.218+).

Before it launches, a dialog shows the scope, your remaining free runs, and the estimated cost. The review then runs in the background. Use /tasks to check on it or stop it.

Requirements and limits

• You must be signed in with a claude.ai account. With an API key only, run /login first.
• It is not available on Amazon Bedrock, Google Cloud’s Agent Platform, or Microsoft Foundry, or for organizations with Zero Data Retention or the HIPAA configuration. In those cases /code-review ultra falls back to a local review.
• A branch review can include up to 500 changed files and 8,000 changed lines by default. The docs note the exact values can change.
• PR mode needs the repository on github.com and a GitHub account connected to Claude. Run /web-setup to connect your GitHub CLI login.

What it costs

The free runs are a one-time allotment per account and do not refresh. After that, the docs put a typical review at $5 to $25 in usage credits depending on the size of the change. A run counts once the cloud session starts, so a review you stop early still uses a free run.

That price is why the docs frame it as “pre-merge confidence on substantial changes” rather than something you run on every commit.

Running it from a script

claude -p '/code-review ultra' launches the cloud review and exits without waiting, so you never see the findings. Use the subcommand instead:

claude ultrareview 1234 --json --timeout 45

It blocks until the review finishes, prints findings to stdout, and exits 0 on completion, 1 on failure or timeout, 130 on Ctrl-C. Add --post to post the findings to the PR as one comment from your GitHub account (v2.1.227+).

The managed Code Review service

This is the part behind most of the recent headlines. With Code Review, Claude reviews pull requests in your GitHub repositories without you running anything. A review runs in four stages: several agents examine the diff and surrounding code in parallel, a verification step filters false positives, the remaining findings are deduplicated and ranked, and the results are posted.

Each review leaves inline comments, a summary, and a check run named Claude Code Review. Findings are marked by severity:

A review never approves or blocks the pull request, and the check run never concludes as a failure. Inside a review, repository access is read-only and it does not build or run your code.

Setup in short

An Owner of the Claude organization turns it on in Admin settings, Claude Code, Code review on claude.ai, installs the Claude GitHub App, and picks repositories. The full steps are in Set up Code Review. Two settings matter most:

• Review level: Quick, Standard (default), or Deep. Deeper costs more.
• Review runs: once after PR creation, after every push (the default for new repositories), or manual.

On a PR, anyone with write access can comment @claude review for one review, or @claude review always to subscribe that PR to reviews on every push. Drafts and PRs from forks are skipped by automatic reviews, but a comment command still works.

Billing

There is no flat price per review. The costs page says reviews are billed on token usage through usage credits, separately from plan usage, and charged to the organization. Cost scales with review level, change size, code complexity, and how often reviews run. “After every push” multiplies cost by the number of pushes, so switch to “once after PR creation” or manual if your PRs get many small commits. You can set a monthly spend limit for the Code Review service in the usage settings.

Tuning it with REVIEW.md

The service reads two files from your repo. CLAUDE.md is project context, and violations become findings. REVIEW.md is for review-only rules: what counts as Important, a cap on nits, paths to skip, checks to always run. A short example based on the customize docs:

# Review instructions

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

## Do not report
- Anything CI already enforces: lint, formatting, type errors
- Generated files and any *.lock file

## Always check
- New API routes have an integration test

REVIEW.md is read from the base or default branch, never from the PR’s own changes, so merge it first. Some instructions, like lowering severity or excluding paths, are only honored when the default branch is protected.

Which one should a solo developer use?

If you ship alone on a Pro or Max plan, the managed service is out of reach anyway. The workflow that fits the docs looks like this:

1. While building, run /code-review at a natural stopping point, before you commit a chunk of work. Use low effort when you only want high-confidence bugs.
2. Before opening a PR, run /code-review main...my-branch so the review sees the whole change.
3. Before merging something risky (payments, auth, a data migration, a StoreKit change), spend one of your free ultrareview runs, then decide if a paid run is worth it next time.
4. Keep rules in CLAUDE.md, since that is what the local command reads.

If you run several branches at once, parallel sessions with worktrees let each branch get its own review without stepping on the others. If you want checks to run automatically as Claude edits, a hook or a custom reviewer subagent can do part of that job without the managed service.

Small iPhone apps, like the focus and sleep apps in the app catalog (Molip, SnoozeLog), get plenty of changes that are UI tweaks, and a local review is enough for those. Save the deep pass for changes that can break things for every user at once, like in-app purchases or a data migration.

What none of these do

The docs include a plain warning: Code Review uses AI and may miss bugs, security issues, or other problems, and a review with no findings does not mean the code is error-free or secure. None of these options run your test suite for you (the managed service does not build or run code at all). Keep tests and CI. Treat the review as another reader, not a gate.

Sources

• Code Review overview and comparison: code.claude.com/docs/en/code-review
• Local review with /code-review: code.claude.com/docs/en/code-review-local
• Ultrareview: code.claude.com/docs/en/ultrareview
• Setup: code.claude.com/docs/en/code-review-setup
• Reading and requesting reviews: code.claude.com/docs/en/code-review-pull-requests
• Customizing with REVIEW.md: code.claude.com/docs/en/code-review-customize
• Costs: code.claude.com/docs/en/code-review-costs