Claude Code Review bills every push by default. Set three dials before you add a repo

Add a repository to Claude Code Review and it starts on “After every push”. That’s the setting that runs the most reviews, and the cost docs say so in as many words. A pull request with seven pushes gets seven reviews, each billed to the organisation.

There’s no flat price per review to multiply by. Spend is the cost of one review times the number of reviews, and both halves have a dial. A third dial, the monthly cap, limits the damage when the first two are wrong. Together they decide whether Code Review is a line item nobody notices or a surprise on the invoice.

Everything below applies to the managed service for Team and Enterprise plans. The local /code-review command in a Claude Code session is a different thing and isn’t billed this way.

What one review costs

Reviews are billed on token usage through usage credits, separately from the plan’s included usage. They’re charged to the organisation, not to whoever opened or requested the review. According to the docs, the cost of each review scales with four things: the review level, the size of the change, the complexity of the surrounding code, and how many candidate issues need verification.

Only one of those is a setting. The review level is Quick, Standard or Deep. Standard is the default, Quick is “the fastest level, at the lowest cost”, and Deep “takes the longest and costs the most”. An Owner picks one level for the organisation and can override it per repository: click Edit on the repository’s row and choose a level, where the first option, Default, follows the organisation.

The other three are properties of your pull requests. A 2,000-line diff into a tangled module costs more than a 40-line fix in a tidy one, at any level. That’s an argument for the small, reviewable diffs you wanted anyway.

How many reviews run

Each repository has a Review runs setting with three options:

The admin table shows these as Once per PR, Every push and Manual. Drafts and pull requests from forks are skipped by automatic reviews whichever you choose.

Every push has a real upside. The docs describe it as catching new issues as the pull request evolves, and it auto-resolves threads when a flagged issue gets fixed. A later automatic review also focuses on what changed since the previous one and posts fewer nits and pre-existing findings, so pushes after the first review shouldn’t cost as much as the first. The docs don’t give a ratio, so don’t assume one.

The pattern an agent produces is the awkward part. A coding agent iterating on a branch pushes in small steps, and a branch that took a human two pushes can take an agent eight. Under After every push that’s eight reviews of a change one person will read once.

A recommendation (opinion, not documented guidance): for repositories where agents open most of the pull requests, start at Once after PR creation and keep After every push for the few repositories where late-arriving bugs are expensive.

The comment commands change the count

Developers don’t need an Owner to change how many reviews a pull request gets. The pull request docs list the commands, and anyone with write, maintain or admin access can use them:

off and pause work as aliases for stop. Capitalisation doesn’t matter.

Two details matter for cost. First, @claude review always in a Manual or Once-per-PR repository opts that pull request into After every push behaviour, so cost accrues per push from then on. It’s the right tool for a high-risk change and a bad habit as a reflex. Second, the meaning of plain @claude review changed. The docs note that before a July 2026 update it subscribed the pull request to future pushes. A team that wrote the old behaviour into its contributor guide is now describing a different command.

The commands are picky. Each must be a new top-level comment with the whole command on one line at the start. If always or stop is misspelled or on a later line, Claude reads the comment as plain @claude review and runs a single review. That’s a wasted review rather than a wrong one, but it’s still billed.

The stop command has a gap. In a repository set to After every push you can’t end reviews with a comment, because pushes start reviews with or without a subscription. The docs’ workaround is converting the pull request to a draft, which skips automatic reviews. Marking it ready again starts one. Per the changelog, @claude review stop arrived in Claude Code 2.1.307, so older docs and blog posts won’t mention it.

Estimate before you roll out

The docs recommend a pilot instead of a formula, which is the right call because the average moves with your pull request sizes. The steps:

1. Set a monthly spend limit for the pilot.
2. Add a few representative repositories with Review runs on Once after PR creation or Manual.
3. After several reviews, read each repository’s Average cost column in the Repositories table, under Admin settings > Claude Code.
4. Multiply by the pull requests the repository opens per month. For After every push, multiply again by the typical pushes per pull request.

The first multiplier is easy to get. This command counts the pull requests opened in a window (not run here, and it needs gh signed in):

gh pr list --state all --search "created:>=2026-09-22" --limit 1000 --json number --jq length

The second multiplier is harder, since git history records commits rather than pushes. Treat commits per pull request as an upper bound. With made-up numbers, purely to show the arithmetic: if the average were X, 120 pull requests a month at Once-per-PR would cost 120 times X, and the same repository at an average of six pushes each would be as much as 720 times X. The gap between those two lines is the whole argument for choosing the run mode deliberately.

Analytics at claude.ai/analytics/code-review show PRs reviewed, month-to-date cost and a per-repository breakdown. The breakdown is estimated at list price, before discounts or credits, so the invoice is the figure that counts.

Put a cap under it

The monthly limit lives at claude.ai/admin-settings/usage, set for the Claude Code Review service, and it applies to the whole organisation. Code Review also skips reviews when the organisation’s overall limit or its usage credit balance runs out, or when what’s left is less than the expected cost of one review.

Skipped reviews aren’t silent. Claude posts a comment starting “⚠️ Code review skipped” whose wording names the cause: the Code Review monthly cap, no extra usage available, or a balance too low for another review. Once an admin restores budget, comment @claude review on the pull request to get the review that was skipped.

That last point is a trap for gated workflows. If a team has a merge process that waits for the review to appear, an exhausted budget on the 25th of the month stalls every open pull request at once. The check run for a skipped review can read “Code review declined”, and it never concludes as a failure, so a required-check rule won’t catch it. A cap is only safe if somebody owns the alert for hitting it. For the CI side of gating on review results, see the REVIEW.md and merge gate piece .

One more switch is worth knowing. Covering a whole GitHub organisation from a single row sets every repository in it to the chosen option, including ones you had set individually, and the docs warn it can raise spend significantly. It refuses to work unless a monthly spend limit exists. An organisation row also has no review level of its own, so levels stay per repository.

Setup for this week

Open Admin settings > Claude Code and sort the Repositories table by Review runs. Any repository showing Every push that you didn’t choose deliberately is the default talking. Move the agent-heavy ones to Once per PR, set a monthly limit if none exists, and add one line to the contributor guide: @claude review for one review, @claude review always only for changes that earn it.