Claude Code GitHub Code Review: Bot vs Local Review

- Pricing, research-preview status, and the severity table below were cross-checked directly against code.claude.com/docs/en/code-review at the time of writing (2026-08-20); Anthropic flags this feature as fast-changing, so verify the live docs before depending on exact figures.

What the native GitHub Code Review bot actually is

It's a GitHub App an Owner installs at the organization level, choosing which repositories get it. Once enabled, reviews trigger automatically when a PR opens, on every push, or when someone comments @claude review on a PR - depending on how each repo's trigger is configured.

When a review runs, multiple agents analyze the diff in parallel, each looking for a different class of issue, in the context of your full codebase. A verification step then checks candidates against actual code behavior to filter out false positives. Results are deduplicated, ranked by severity, and posted as inline comments on the exact lines where issues were found, with a summary at the top. Alongside that, a check run named Claude Code Review shows up next to your other CI checks - if nothing was found, the check run updates to say so too. Source: code.claude.com/docs/en/code-review.

Beyond the inline comments, the check run's Details view lists every finding in one place sorted by severity - a 🔴 Important row pointing at, say, src/auth/session.ts:142 next to a 🟡 Nit row a few lines down - handy when you want the whole PR's findings on one screen instead of scrolling the diff. The same findings also render as annotations directly on the Files changed tab. If you push a new commit while a review is still analyzing an older diff, a flagged line that moved doesn't just vanish - it reappears under an Additional findings heading in the review body instead.

Bot vs local /code-review - the comparison nobody else makes

Most coverage of this feature either describes the bot alone or compares it against third-party SaaS tools. Almost none puts it side by side with the free review command Claude Code already ships. Here's the direct comparison:

If you also use Codex, its equivalent review command is /review - different presets, different setup - covered separately in Codex Code Review (/review).

The severity tiers, explained

Every finding gets exactly one of three tags, verbatim from the docs:

Each finding also carries a collapsible reasoning section explaining why Claude flagged it and how it verified the issue. You can react with 👍/👎 directly on a comment - Anthropic aggregates those after the PR merges to tune the reviewer, though a reaction doesn't trigger a re-review or change anything on the PR itself.

REVIEW.md - how to tune what gets flagged

REVIEW.md lives at your repo root and gets injected straight into the system prompt of every agent in the review pipeline as the highest-priority instruction block, overriding the default review guidance. Because it's pasted verbatim, the @path import syntax isn't expanded inside it - whatever you want the reviewer to know has to be written directly into the file.

CLAUDE.md is still read alongside it, but only as project context, and newly introduced violations get tagged Nit at most, never higher. It also works bidirectionally: if your PR makes a CLAUDE.md statement outdated, Claude flags that the docs need updating too.

The part that's easy to miss: the local /code-review command does NOT read REVIEW.md. It only follows CLAUDE.md, same as any normal Claude Code session. If you want to tune the managed bot specifically, REVIEW.md is the only file that has any effect there.

A condensed example, paraphrased from the docs (redefines Important, caps nits, skips generated files):

# Review instructions

## What Important means here
Reserve Important for findings that would break behavior, leak data,
or block a rollback. Style/naming/refactor suggestions are Nit at most.

## Cap the nits
Report at most 5 Nits per review; roll up the rest as "plus N similar items"
in the summary.

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

Setup - how an Owner turns it on

Go to claude.ai/admin-settings/claude-code, find the Code Review section - you need the Owner or Primary Owner role in your Claude organization, plus permission to install GitHub Apps in your GitHub org. Click Setup to start the GitHub App install flow: pick the GitHub org that owns your repos, choose which repos it can access, and approve the requested permissions. Once installed, select which repos to enable, then for each one choose a Review Behavior: Once after PR creation, After every push, or Manual (only runs when someone comments @claude review).

Important gate: this is not something a solo dev on Pro/Max can self-enable - it needs a Team/Enterprise organization, and someone has to hold the Owner role.

Once it's running, Owners can track adoption from the analytics dashboard at claude.ai/analytics/code-review: PRs reviewed per day, weekly spend, and how many review comments got auto-resolved because someone fixed the flagged issue, broken down per repository. Treat the dashboard numbers as estimates for spotting trends - for invoice-accurate spend, check your actual Anthropic bill.

Pricing - what it actually costs

Each review averages $15-25, billed on actual token usage, scaling with PR size and codebase complexity. That cost is billed separately through usage credits and does not count against your Team/Enterprise plan's included usage. Your trigger choice multiplies the total noticeably: Once after PR creation runs exactly once per PR, Manual only runs when someone comments, and After every push re-runs on every push - the most expensive of the three. Orgs can set a monthly spend cap in admin settings; when it's hit, reviews pause and resume automatically at the next billing period (or immediately if an admin raises the cap).

For comparison: the local /code-review command costs nothing beyond the usage you're already paying for.

Does it block the merge?

No - never. The check run always completes with a neutral conclusion, so branch protection can't gate on it directly even if you wanted it to. That's a genuinely surprising detail for a team evaluating this as a hard merge gate: to actually enforce one, you have to parse the machine-readable severity breakdown at the end of the check run's output yourself, in your own CI, for example:

gh api repos/OWNER/REPO/check-runs/CHECK_RUN_ID \
  --jq '.output.text | split("bughunter-severity: ")[1] | split(" -->")[0] | fromjson'
# => {"normal": 2, "nit": 1, "pre_existing": 0}

The normal key is the count of Important findings; a non-zero value means there's at least one bug worth fixing before merge.

One more nuance worth knowing: reviews are best-effort. If the run hits an internal error or times out, the check run's title changes to Code review encountered an error or Code review timed out - but the conclusion stays neutral either way, so a failed run doesn't block you any more than a clean one does. Comment @claude review to retry; the Re-run button in GitHub's own Checks tab does not retrigger Code Review.

A third option - a local, customizable reviewer

Beyond the managed bot and the free local command, there's a third path worth naming honestly: AgentKit's Engineer Kit ships a local review agent (code-reviewer), invoked via /ak:review - similar to running /code-review, but bundled with the kit's other agents/workflows and customizable to how you define your process, not gated to Team/Enterprise, and not billed per review - it's a one-time kit price instead. This isn't a feature-parity claim against Anthropic's own bot - just an honest third comparison point for readers who don't want either of the other two. For the local command in depth, see the local /code-review walkthrough. For an overview of the product, read the AgentKit review.

Which one should you use?

Not mutually exclusive - many teams run more than one:

• Solo dev, any plan: the local /code-review command - free, sufficient.
• Team wanting automatic coverage on every PR without teaching a command: the managed bot - budget for $15-25/review.
• Want a customizable reviewer without per-review billing, on any plan: the kit-based review agent.

Frequently asked questions (FAQ)

What is Claude Code's native GitHub Code Review?

A GitHub App bot, enabled by an org Owner, that automatically reviews pull requests on GitHub and posts inline comments tagged by severity. It's currently in research preview.

Is it free?

No. It averages $15-25 per review, billed separately through usage credits, not counted against your plan's included usage. The local /code-review command is the free option.

What plans get Code Review?

Only Team and Enterprise (research preview), and it's unavailable to organizations with Zero Data Retention enabled. Pro/Max can't self-enable the bot, but every plan can use the local /code-review command.

Does it block merging?

Never. The check run always completes with a neutral conclusion, so branch protection can't gate on it directly - a hard gate requires parsing the machine-readable severity breakdown yourself in CI.

What's the difference between REVIEW.md and CLAUDE.md?

REVIEW.md is review-only and gets injected as the highest-priority instruction into every review agent. CLAUDE.md is general project context, and new violations there only get tagged Nit. The local /code-review command reads CLAUDE.md but not REVIEW.md.

Can I use the local /code-review command instead?

Yes, and it's free on every plan. The trade-off: you have to run it yourself, you don't get automatic coverage on every PR the way the bot provides, and it doesn't read REVIEW.md.

Conclusion

Three options, three situations: the GitHub Code Review bot is research preview on Team/Enterprise, $15-25/review, and never blocks a merge; the local /code-review command is free on every plan but you run it yourself; the kit-based review agent is the customizable, one-time-priced option. Want the local command in depth? See AI code review with /code-review. Need a different review layer entirely, focused on security? See security audits with /security-review.