On October 15, Anthropic took Code Review out of research preview and opened it to Team and Enterprise organizations. I use Claude Code every day, but I have not used this service. What follows comes from the GA announcement, the documentation and the ClaudeDevs post, not from running it.

The reviewer comments. It does not sign.

The docs are blunt: “a review never approves or blocks the pull request,” and the “Claude Code Review” check run never concludes as a failure. It ends neutral, or skipped. A required status check will not stop anything on its account.

So the question changes. It is no longer whether the AI finds the bugs. It is who decides what to do with what it found.

Anthropic says most reviews now finish about 3x faster than in preview, 6 to 10 minutes instead of roughly 20. In the March launch post it reported, about its own code, that PRs with substantive review comments went from 16% to 54%, and that 84% of PRs over 1,000 changed lines get findings, 7.5 on average. Those are Anthropic’s numbers on Anthropic’s repositories.

More findings per PR means more decisions per PR. It is the shift I wrote about in the hidden cost of AI coding: the fast part got faster, and the queue of human decisions got longer.

Decision 1: who resolves the thread

Each finding lands as an inline comment with one of three severities: Important (a bug to fix before merging), Nit, and Pre-existing. The docs say you can merge without answering a finding unless your branch protection requires conversation resolution. To dismiss one without changing code, you resolve the thread yourself. Replying is not enough.

So whoever resolves an Important thread without touching the code is signing. Decide who may do that before the first person in a hurry decides for you.

The service also builds and runs nothing. It reads the diff and the code around it. In my piece on AI code review and governance I argued that review assumes an author who can explain their choices. Code Review does not replace that conversation, and the docs warn that a review with no findings does not mean the code is error-free.

Decision 2: what you spend and when it stops

There is no flat per-review price. Billing is on token usage, through usage credits, to the organization and not to the developer who opened the PR. The March launch post said reviews “generally average $15–25.” The current docs promise no number, so I would not budget from that one.

The docs do say where spend jumps. A repository you add starts at “After every push,” the setting that runs the most reviews. A hypothetical to see the mechanics: 100 PRs a month with 4 pushes each is 400 reviews in that mode and 100 in “Once after PR creation.” Multiply by your real average.

Levels move cost too. Quick, Standard (the default) and Deep: an Owner picks one for the organization and can override it per repository. Deep for code that moves money, Quick for the rest.

Then there is the monthly spend limit. When it runs out, the service skips reviews and leaves a PR comment naming the cause. If your policy says “every PR goes through Code Review,” that cap is part of the policy. Anthropic suggests a pilot on a few repositories with a low limit, reading the average cost per repository in the admin panel. Eligible Enterprise organizations can claim at least $10,000 in credits by January 15, expiring 30 days after the claim. Use them to measure your average, not to settle the policy.

Decision 3: what can stop a merge

By default, nothing. If you want a gate, the docs show how to read the last line of the check run details with gh and jq: when the normal count (the Important findings) is above zero, you fail your own job. They also warn that a missing line means no verdict, not zero findings. A review that failed or timed out has no such line.

My call is to put the gate last. Measure first how many Important findings in your repositories turn out wrong. Anthropic reports its engineers mark less than 1% of findings incorrect, but that is their code and their team. Draft PRs and forks are not reviewed automatically either, and GitHub is the only supported host.

The policy fits in four lines per repository

Review level. When it runs. Who may resolve an Important thread. Gate or no gate. If you cannot fill those four lines for your most critical repository, the service will work anyway and nobody will know what was promised with it.

That is what we work out in the discovery phase of AI Maestro once a team already generates code with agents: who signs, on what evidence, under what spending cap.

Tell me how you merge today and we will write the four lines