Claude Code Review: Four Ways to Get One and What Each Costs

Claude Code Review is Anthropic's managed service that reviews GitHub pull requests with several agents, checks each finding against the code, and posts the ones that hold up as inline comments. It needs a Team or Enterprise plan and bills each review as usage credits. On Pro or Max, a comparable review comes from /code-review, ultrareview or the Claude GitHub Action.

This is a documentation analysis of Anthropic's docs and pricing page as of October 18, 2026; I have not used the managed service, and the example below is fictional.

Which Claude review to use

Four products answer to the name. Anthropic's docs sort them by plan; here they are with timing and cost:

• /code-review runs inside your Claude Code session as a background subagent, on any plan, and counts toward your normal usage. It takes seconds to a few minutes. /review is now an alias; before v2.1.223 it was a separate, single-pass command.
• Ultrareview, started with /code-review ultra, sends a fleet of reviewer agents to a cloud sandbox and reproduces every finding before reporting it. It takes about 15 to 25 minutes and needs a claude.ai sign-in, not just an API key. Pro and Max accounts get three free runs that never refresh; after that a review typically costs $5 to $25 in usage credits.
• The Claude GitHub Action reviews each pull request on your own CI runners. It runs on your Claude subscription or an API key, plus GitHub Actions minutes.
• Code Review, the managed service, reviews pull requests from Anthropic's infrastructure when they open, on every push, or on an @claude review comment. It requires a Team or Enterprise organization on GitHub, and an Owner to turn it on.

Working alone on Pro or Max, I would run /code-review while iterating, spend ultrareview runs on merges that touch payments, sign-in or data you cannot easily restore, and add the Action only to get a comment on every pull request without opening a terminal. The managed service becomes worth its cost once other people open pull requests in your repository. On GitLab, /code-review --comment posts findings to a merge request through the glab CLI.

Run /code-review on your branch

The local review takes four steps:

1. Open Claude Code at the repository root, on your feature branch, and commit your work. A background --fix run edits files outside your session's checkpoints, so /rewind may not undo them; git can.
2. Type /code-review. With no target it reviews the commits ahead of the upstream branch plus uncommitted changes; without an upstream, it compares against main or the previous commit. To aim it elsewhere, type /code-review 42 for pull request 42, /code-review main...my-feature for two branches, or /code-review src/billing for a directory.
3. Pick an effort level once. /code-review low reports only the findings it is most confident in; medium through max widen the search. Later reviews reuse the level you typed, even in a new session.
4. Read the findings when they arrive and ask Claude to fix the ones you accept. --fix applies them in the same run, through your permission mode; --comment posts them inline on a GitHub pull request.

The review follows your CLAUDE.md but not REVIEW.md, which only configures the managed service, so rules every review should apply belong in CLAUDE.md. An empty report is not a clean bill either: in the docs' words, a review with no findings doesn't mean your code is error-free or secure.

“

Before a clean review reassures you about a class of bug, confirm the reviewer finds one instance of it in your code.

”

Check that the review catches a bug you planted

Before a clean review reassures you about a class of bug, confirm the reviewer finds one instance of it in your code. The example is fictional: an invoicing app whose rule is that a user only ever reads their own invoices. The rule goes in CLAUDE.md:

## Review rules
- Every read or write of an invoice, customer or payment checks that the record belongs to the signed-in account.
- Do not report formatting or naming; the linter handles them.

On a throwaway branch, created with git switch -c review-check, break your rule in one real function and commit the change. In the fictional app, it looks like this:

// src/invoices.ts
export async function getInvoice(invoiceId: string, userId: string) {
  const invoice = await db.invoice.findUnique({ where: { id: invoiceId } });
  return invoice;
}

userId is never compared with invoice.ownerId, so any signed-in user who knows an ID can read someone else's invoice. Run /code-review medium, or your usual level. The test passes when a finding points at src/invoices.ts and names the missing ownership check; it fails when nothing comes back, or only a style remark. On a failure, rerun one level higher, then check that the rule sits in the CLAUDE.md at the repository root. Finish with git switch main (or your default branch) and git branch -D review-check.

A caught bug shows that your rule reaches the reviewer, not that the next pull request is safe; repeat the test when you change rules or effort level. It is the fourth fix in Claude Code Reddit: Seven Mistakes and the Fix for Each, a check the agent did not write for itself, applied to the reviewer. Reading code is also not running it: the managed service works from the diff and surrounding code without building or executing anything, so behavior checks like the one in Vibe Coding Reddit: The Code That Only Looks Finished stay your job.

Ultrareview before a merge you cannot easily undo

/code-review ultra compares your branch with the default branch, uncommitted and staged changes included, by uploading a bundle of the repository. /code-review ultra 42 reviews pull request 42 on github.com instead, cloned through the GitHub account you link with /web-setup, and uploads nothing from your machine.

Before launch, a dialog shows the scope, your remaining free runs and the estimated cost. A stopped or failed run still uses a free run, and paid runs need usage credits turned on, which /usage-credits checks. A branch review accepts up to 500 changed files and 8,000 changed lines by default. The ultrareview page marks the feature as a research preview, so its pricing may change.

A comment on every pull request: the GitHub Action

In Claude Code, at the repository root, run /install-github-app. It needs a github.com repository you administer and the GitHub CLI logged in with gh auth login. Select the review workflow and choose your Claude subscription token over an API key: saved as the secret CLAUDE_CODE_OAUTH_TOKEN, it makes runs use your subscription instead of API billing. Create and merge the pull request it prepares. To write the file by hand instead, copy the review workflow from the docs and replace its anthropic_api_key line with claude_code_oauth_token: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }}.

Success is an inline comment per issue, or one summary comment when there are none. The plugin's README describes four parallel agents, for CLAUDE.md compliance, bugs and git history, and drops any issue scored under 80 out of 100. The workflow skips drafts, closed or trivial pull requests, and those that already carry a comment from Claude, so pushing fixes gets no second pass; run /code-review locally for that. On a public repository, pull requests from forks get no secrets, hence no review.

When the managed Code Review is worth a Team plan

The Team plan starts at two seats; a standard seat costs $20 a month billed annually or $25 billed monthly, in US dollars before tax, so the minimum is $40 a month on annual billing or $50 on monthly. Reviews come on top, billed as usage credits with no flat price; cost scales with the review level (Quick, Standard or Deep), the size of the change and the complexity of the code around it. Anthropic's launch post of March 9, 2026 put the average at $15 to $25 a review. At that average, twenty pull requests a month reviewed once each would cost $300 to $500.

A repository you add starts at "After every push", so every push is a billed review. Switch it to "Once after PR creation" or "Manual" and set a monthly spend limit before the first pull request.

In exchange, a later review focuses on what changed since the previous one and resolves its own threads when it judges an issue fixed. Findings are ranked Important, Nit or Pre-existing, the check run never blocks a merge, and a REVIEW.md on a protected default branch can cap nits or skip generated files. That matters when someone else writes the code, such as a cofounder or a contractor whose pull requests you would otherwise read line by line. If you write every line yourself, start with what costs nothing extra: put your two most expensive rules in CLAUDE.md, plant one bug on a throwaway branch, and run /code-review.