Claude Code Review Is Generally Available: Levels and Costs

Anthropic made Claude Code Review generally available on October 15, 2026. The announcement says it is out of research preview for Claude Team and Enterprise organisations, that most reviews now finish in six to ten minutes instead of about twenty, and that admins can pick a Quick, Standard or Deep review for each repository. Reviews run on GitHub pull requests, post their findings as inline comments, and never approve or block a merge.

AI review is no longer novel. GitHub, Cursor and others already offer it, and we covered Cursor's Bugbot and Copilot's review going generally available when they shipped. What makes this release worth a close read is the billing model and the set of organisations it excludes, both of which decide whether a team can turn it on at all.

Everything below comes from Anthropic's announcement and its Claude Code documentation, read on October 19. The speed figures are Anthropic's own.

Anthropic lists three changes since the preview. Speed: most reviews finish about three times faster, in six to ten minutes rather than around twenty. Quality: findings are meant to be shorter, stating the problem, what triggers it and the fix in a few sentences. Control: admins choose a review level per repository. The announcement also says Anthropic runs Code Review on its own pull requests, which shows the team where reviews slow its own engineers down.

For Enterprise customers there is a sweetener. Eligible Claude Enterprise organisations can claim at least $10,000 in Code Review credits by January 15, 2027; terms apply. The credits expire 30 days after they are claimed, so the sensible order is to set up the repositories and a review level first, then claim, so the 30 days are spent on real pull requests rather than on configuration.

Why the speed figure matters: a review that takes twenty minutes arrives after the author has moved on, and its comments land as interruptions. A review that lands in six to ten minutes arrives while the change is still in the author's head. The failure case is treating Anthropic's typical time as a ceiling. Deep reviews, large diffs and busy periods will take longer, and nothing in the docs promises a time.

Anthropic's Code Review documentation describes four stages on Anthropic's infrastructure. Find: several agents read the diff and the surrounding code in parallel. Verify: a separate step checks the candidate findings against the code and filters out false positives. Rank: what remains is deduplicated and ordered by severity. Post: the results go onto the pull request.

Each review leaves inline comments on the lines concerned, a summary in the review body, and a check run named Claude Code Review. The check run does not conclude as a failure, and a review never approves or blocks the pull request; the merge decision stays with the team. When nothing is found, the check run reads "Code review found no issues". By default, reviews focus on correctness, meaning bugs that would break production, not formatting or missing tests.

The access model is narrow on purpose. Inside a review, access to the repository is read-only, a review does not push commits, and it works from reading the code without building or running it. Anthropic picks the Claude models reviews run on, and admins have no model choice; the review level is the only dial.

An Owner picks one level for the organisation and can override it per repository. A second setting, also per repository, decides when reviews run: once when a pull request opens, after every push, or only when someone asks. Anyone with write access can request a review by commenting @claude review on a pull request. Drafts and pull requests from forks are not reviewed automatically.

The two settings multiply, and the trigger starts at the expensive end: Anthropic's docs say a repository added from the admin page starts at After every push. A Deep review after every push on a busy repository is the most expensive configuration available. The example that works for most teams: Standard, once when a pull request opens, with authors commenting @claude review again after a large rework. The failure case is leaving the push trigger at its default, raising the level to Deep, and discovering it on the first invoice.

Anthropic's costs page says Code Review is billed on token usage through usage credits, separately from the plan's included usage, and charged to the organisation rather than to the developer who opened the pull request. There is no published price per review. Cost moves with the size of the pull request and the review level.

Anthropic suggests a way to estimate it. Set a monthly spend limit for a pilot. After several reviews, read each repository's average cost per review in the Code Review section of the Claude Code admin settings. Multiply that by the number of pull requests the repository opens in a month, and, if reviews run after every push, by the typical number of pushes per pull request. The result is your monthly figure for that repository at that level.

The cap is real. An organisation-wide Code Review spend limit resets each billing period, and Code Review skips a review once the remaining budget is less than the expected cost of one review, leaving a comment on the pull request that says so. That is better behaviour than a silent stop, but it means a busy end of month can leave late pull requests unreviewed. Our comparison of AI spend controls shows how this sits next to other vendors' caps.

The availability list in the documentation is short and strict. The organisation needs a Team or Enterprise plan, and the code has to be on GitHub: github.com, GitHub Enterprise Server, or GitHub Enterprise Cloud with data residency. GitLab and Bitbucket repositories are not covered by the managed service.

Several regulated setups are excluded outright. Code Review is not available to organisations with Zero Data Retention enabled or with Anthropic's HIPAA configuration applied, and it is not covered under Anthropic's Business Associate Agreement. It is not yet available to organisations that use customer-managed encryption keys. Teams that reach Claude through Amazon Bedrock, Google Cloud or Microsoft Foundry still need a Claude organisation on one of the qualifying plans to use it.

The example that catches people: a health-tech company on Claude Enterprise with the HIPAA configuration, which assumed review would come with the plan. It does not, and the alternative is running Claude in its own CI, covered in section 08. The failure case is discovering this after a procurement decision; check the data retention settings before promising the feature to an engineering team.

A useful argument for running AI review early comes from a project whose account names no review tool. On October 9, PostgreSQL core team member Peter Eisentraut wrote that about 8 to 10 significant features had been reverted from PostgreSQL 19 after its beta began. He named several likely causes: code that was not good enough, coincidence, a stretch of reduced beta testing while senior developers worked on security fixes, system complexity, and no way to commit a feature as experimental. One cause was AI-assisted review.

His point was not that the findings were wrong. Some reverted features had significant architectural defects that would have been hard to fix quickly during beta. Alongside them sat a long tail of small edge cases, each needing about a three-line fix on average, that in earlier years would have surfaced much later and been fixed bit by bit over the following five years. Found all at once, late in a release cycle, the fixed overhead of handling each one ran the clock out. He wrote that the effective quality bar had been raised after the features were written and committed, and that the situation was, for the most part and as far as he can tell, not due to "vibe coding", since the code was written before that was possible.

The release candidate announcement on October 15 gives November 19 as the planned date for general availability, after a second release candidate on November 12 that takes in the fixes from that day's update release. So the honest summary is narrower than the headlines: by a core developer's account, AI review was one factor in the reverts, and the release announcement ties the date to the update release, not to AI review.

The lesson transfers directly. A finding on a pull request costs the author minutes, because the code is fresh and nothing depends on it yet. The same finding at release time costs a revert. Whatever tool a team uses, the cheap place to meet AI review is before merge, and the budget should include the human time to act on what it finds. Our post on AI finding bugs in curl shows what AI bug-finding looks like on another long-lived open-source project.

Teams change what Code Review looks for with guidance files in the repository: a REVIEW.md for review-specific rules, and the same CLAUDE.md files Claude Code already reads. A payments team might tell it to treat any change to rounding or currency handling as high severity; a front-end team might tell it to ignore generated files.

One detail in the docs is a security decision worth knowing. Code Review reads REVIEW.md from the base or default branch and never from the pull request's own changes. A pull request cannot weaken its own review by editing the instructions in the same change. The failure case this prevents is real: without it, a contributor could add "ignore changes under /auth" to the guidance file in the same pull request that touches /auth.

Keep the guidance short. Every rule competes with the review's own judgement, and a long file of preferences turns a correctness review back into a style review, which is the noise the levels were meant to remove.

Anthropic's docs list five ways to have Claude review code, and the managed service is only one of them. For teams excluded above, or on smaller plans, the others cover most of the ground.

The CI route is the one the docs leave open for GitLab teams, and the one to evaluate for organisations with Zero Data Retention, because the code goes through the API under the organisation's own terms. It costs engineering time to set up and maintain, which is what the managed service saves. If you want help designing a review pipeline that fits your plan and your compliance settings, that is part of our web development work.