AI Code Review Tools Compared by Where They Run

The Product Hunt listing for CC Auto Review runs one line: a macOS app that reviews GitHub PRs with your local Claude Code. That reads like a tagline, but it is really an architecture spec, and it encodes the three questions that decide which AI code review tools earn your credentials: where the reviewer executes, whose token it spends, and what a reviewed pull request costs at your PR volume.

Most comparison content grades these products on model quality. That axis matters less than buyers assume. The major tools ship comparable frontier models, so the differences that show up in your audit log and your invoice come from the execution surface, meaning where the reviewer runs and whose credentials it spends. Surface choice sets your trust boundary, the context the reviewer can read, and whether cost per PR trends toward zero or climbs with usage.

This piece maps the four surfaces, compares them on trust, context, and cost, and closes with a vetting checklist. One disclosure up front: this is an architectural review. Claims about CC Auto Review come from its public listing, and claims about Copilot, CodeRabbit, Greptile, Graphite Diamond, Devin, and Codex come from vendor documentation. Nothing here is a hands-on verdict.

What CC Auto Review actually is

Per its Product Hunt listing, CC Auto Review is a macOS app that automates pull request review by driving your locally installed Claude Code rather than calling a vendor's own cloud model. Two properties follow from that sentence alone. The reviewer executes on your hardware, and the model doing the work is the one your Claude subscription already authenticates. No vendor-hosted review model sits in the loop, and no third party receives standing repository access as a consequence of the review itself.

Mechanically, apps in this class wrap a local CLI: they watch for PR events, assemble the workspace or prompt locally, and let the binary you already trust do the reading and commenting. Claude Code pull request review done this way inherits whatever your local environment already has, which for most developers is a full working-tree checkout and their own git credentials.

Evidence note: this section describes listed behavior, not tested behavior. Before relying on any local wrapper, verify at install time exactly which GitHub scopes it requests and whether comments post through your account or a bot identity.

The four execution surfaces of AI code review tools

An AI PR reviewer can execute in exactly four places: on your machine, inside the platform hosting the PR, on a vendor's cloud, or inside a vendor-managed sandbox. Which cluster a tool sits in predicts its security posture and its billing shape better than any benchmark.

The cloud SaaS row is the most crowded, spanning CodeRabbit and Greptile at the review-native end and Graphite Diamond among reviewers attached to a broader workflow tool. At the sandbox end sit Devin and OpenAI's Codex, whose cloud agent docs describe tasks delegated to OpenAI-managed environments. If you have read about a Devin code review agent autonomously pushing fixes to a branch, that is this surface.

Trust boundaries and whose credentials get spent

Each surface answers the credential question differently, and the answer is the blast radius.

Local-first spends what you already hold. Your Claude auth stays in your local config, and the wrapper needs no new standing grant to a third party. If the tool misbehaves, the damage is bounded by what your own environment can already do. That is also the honest limit of the guarantee: the reviewer is exactly as powerful as you are.

Embedded review adds no new party. GitHub Copilot code review executes inside GitHub's pipeline, so you are not granting a newcomer anything. The trust question collapses from "do I trust this vendor" to "do I already trust GitHub", which most teams answered long ago. What you trade away is context and control, covered next.

Cloud SaaS redistributes the decision. CodeRabbit, Greptile, and Graphite Diamond install through a GitHub App, which means granting repository access to the vendor. The recurring question, does CodeRabbit need full repo access, has a two-part answer: the install flow typically lets you scope which repositories the app can see, but within an installed repo the app works through GitHub's standard permission model, commonly contents read plus pull request write. CodeRabbit's own GitHub App setup for GitHub Enterprise Server walks through the same grant path. The trust decision shifts from GitHub to the vendor's security posture and data retention terms, so read those before installing on anything sensitive.

Sandbox agents hold the widest grants. Devin-class agents keep standing credentials for your repositories and connected services inside a vendor-managed VM. That is precisely what lets them run tests and open follow-up branches, and it is what enlarges the blast radius from reading code to taking authenticated write actions on your behalf. Every integration you connect, issue trackers, cloud consoles, package registries, becomes reachable from that VM. Scope what the sandbox can touch before connecting anything you would not hand a new contractor.

Context access and what each surface can read

The second variable is reach. What can the reviewer actually read when it comments?

• Local-first sees your repo the way you do. Full working tree, CLAUDE.md instruction files, untracked local state, and potentially your test suite, because the same machine that holds the code can run it.
• Embedded review is diff-first by default. Copilot reviews the changed lines, and broader repository context requires additional setup such as instruction files, all inside GitHub's trust boundary. Fast, bounded, and cheap.
• Cloud SaaS can index the whole tree. Fetched over the API and often embedded for semantic search, this is the deepest automated context short of a sandbox, at the price of the widest read.
• Sandbox gets shell, network, and tools. Maximum context, maximum reach, matching maximum credential exposure.

Here is the architectural point that model-quality comparisons miss: diff-first review is blind to cross-file regressions regardless of model quality. Rename a function in one file and break a call site in a file the diff never touches, and a diff-only reviewer cannot notice. No benchmark score fixes that, because it is a property of the execution surface, not the model. This is also why the CodeRabbit vs GitHub Copilot code review question resolves to context depth and trust boundary rather than cleverness: one reviews from an indexed whole-repo view on vendor infrastructure, the other from the diff inside GitHub's pipeline.

Cost per reviewed PR, flat quota versus seats and meters

AI code review pricing comes in three shapes: flat subscription quota you may already hold, per-seat SaaS, and metered units. One formula covers all of them:

cost per reviewed PR = monthly spend attributable to review ÷ PRs reviewed that month

The shapes differ in which term grows. Run five scenarios:

Plug in real numbers to see the shapes diverge. A $20 plan reviewing 20 PRs a month is a dollar a PR all-in. A per-seat tool at an assumed $30 per developer, three developers, same 20 PRs, is $4.50 a PR. Same workload, different bill, purely from pricing shape.

The flat shape has a hard ceiling, though. Anthropic's usage limit guide describes usage windows that reset on a schedule plus weekly caps that scale with plan tier. For Claude Code rate limits for code review, the practical meaning is throughput: subscription-backed local review drives the marginal cost per PR toward zero right up until mid-sprint, when automated reviews and your interactive sessions draw from the same pool and one of them stops. The curve is flat, and the ceiling is real.

Embedded review is the quiet bargain if you already pay for it. Copilot's plans page lists the tiers, and review availability depends on tier, so treat it as included only after checking your plan rather than assuming. At the other extreme, Devin's ACU billing meters agent compute units per task, which makes per-PR cost equal to units consumed times unit price, with the variance as the story: an agent that investigates before commenting can spend several times what a diff-only pass costs, with nobody watching.

That is the trade in one sentence: per-seat and metered pricing makes monthly cost a function of reviewer count and review volume, and at some volume profiles it exceeds the cost of a subscription you already hold. The formula tells you where your profile sits. Plug in your own N before a demo convinces you.

Where each architecture breaks

Each surface fails differently, and the failure mode tells you which surface you are actually looking at.

1. Diff-blindness. Embedded-by-default review and any diff-only configuration approve changes that break untouched files. Symptom: a green review on a rename that breaks a call site. Fix: whole-tree context, via SaaS indexing or a local full-tree reviewer.
2. Quota exhaustion mid-sprint. Local-first review silently degrades or stops when plan limits bind, because automation and interactive use share a pool. Fix: schedule reviews off-peak, or size the plan tier to review volume before the sprint, not after.
3. Credential sprawl. Sandboxes accumulate standing grants to repositories and connected services, and each integration is permanent attack surface. Fix: scope every grant, rotate tokens, disconnect what the task does not need.
4. Unanswerable retention questions. Security review asks where your code went and whether a vendor trains on it, and nobody can answer from memory. Fix: read the retention terms before installing, and if compliance blocks vendor clouds entirely, remove the question with self-hosting. Greptile documents a self-hosting option, the strongest form of self-hosted AI code review for teams that cannot ship code off-premise.

A decision framework for choosing your surface

No surface dominates all three variables, so the right choice correlates with team size, compliance constraints, and review volume, not benchmark scores.

• Solo to a few engineers, existing Claude subscription, moderate PR volume. Start local-first. Local-first AI tools spend quota you already hold instead of opening a new billing relationship or a new standing grant, which makes this the cheapest trustworthy on-ramp. Escalate when quota or team growth bites.
• Organization standardized on Copilot, zero appetite for new vendors. Use embedded review, and extend its context with instruction files before shopping for anything else. Weakest default context, lowest friction.
• Distributed team, high PR volume, needs an audit trail and support. Cloud SaaS fits, budget per seat, read the retention terms first, and prefer vendors offering a self-host path if compliance is tight.
• The reviewer must run tests, fix its own findings, or work from tickets. Sandbox is the only surface that qualifies. Treat it like an intern with production access: scoped credentials, short-lived grants, human review of everything it writes.

Before granting any reviewer access, get written answers to five questions. Exactly which GitHub App permissions are requested, and can installs be scoped to selected repositories? What is the data retention window, and is customer code used for training? What are the rate ceilings, reviews per month and requests per hour, at your tier? What is the pricing unit, and how does overage behave? Is there a self-host or bring-your-own-model option if compliance tightens?

The one-line Product Hunt listing that opened this piece turns out to contain the whole decision. Where the reviewer runs sets what it can read, whose credentials it spends, and how the bill scales. Model quality is the feature every vendor advertises. Execution surface is the one you actually live with.