We ran Claude Code's /code-review at all five effort levels on 12 planted bugs

The 30-second version

On 15 October Anthropic made Code Review, its pull-request review service for Team and Enterprise plans, generally available, and the same day it described how the Claude Code team reviews its own changes; that post reached 487 points on Hacker News. On any plan, the same kind of review is a command: /code-review, which runs in your own session at the effort level you type.

We built a small Python package, added a 222-line change with 12 planted bugs and four decoys (lines that look odd but are correct), and ran /code-review at all five effort levels on Opus 5.5 in Claude Code 2.1.310. Then we reviewed the same change with the 12 bugs fixed.

• From medium up, every run named all 12 bugs. Low listed four findings in each of three runs, covering five, four and four of the bugs.
• The level sets the size of the list. The review’s instructions cap it at 4 findings at low, 10 at medium and high, and 15 at xhigh and max. At medium and high, one or two bugs usually ended up in a note outside the list or inside another finding. With --max-findings all, one medium run listed all 12 for $0.15.
• It also sets how the review searches and what it costs. At the API list prices Claude Code reports: $0.06–$0.07 and about 10 seconds at low, $0.13–$0.14 and 30 seconds at medium, $0.14–$0.17 and 37 seconds at high, $0.32–$0.36 and 97 seconds at xhigh. Max split the work across 30 agents and took 24 minutes and $18.73 to list the same 12 bugs, about 120 times the cost of high.
• With the bugs fixed, every level still listed findings: 1 at low, 10 at medium, 8 at high, 15 at xhigh, 15 at max. By our reading, one to four per level were real problems we hadn’t planted, plus a Python 3.9 incompatibility at xhigh and max; most of the rest were suggestions. Two findings gave a wrong example value.
• No run treated a decoy as a bug for the inputs its signature allows. Two levels noted that one decoy breaks for inputs its type hint rules out, and four suggested rewriting another as a cleanup.

Verdict: for a change like ours, run /code-review at the default medium with --max-findings all: about 30 seconds and 15 cents at list prices for all 12 bugs. Use xhigh when you want the reviewer to check findings by running code; ours did, though its plan doesn’t require it. Max listed the same 12 bugs after 24 minutes and $18.73; treat it as a slow, verified second opinion for risky changes, not as a better first pass.

What /code-review is

/code-review (alias /review) is a skill built into Claude Code. It reviews your branch’s changes for correctness bugs, runs as a subagent with its own context, and reports findings in your conversation. In a non-interactive -p run it waits and returns the findings in the response. --fix applies the findings; --comment posts them on a pull request.

The effort level is the first argument. Anthropic’s documentation describes low as reporting the findings the review is most confident in, “so you see fewer false positives,” and medium through max as broadening coverage. If you type no level, the review reuses the last one you typed in an interactive session (a level passed in a -p run isn’t remembered), and if you have never typed one, it uses the session’s effort, which on Opus 5.5 defaults to medium.

It is one of three review products with similar names:

Until 15 October the Code Review documentation said each review “averages $15-25 in cost”. That sentence is in the Internet Archive’s copy from 18:47 UTC that day and gone from the copy at 00:38 UTC on 16 October. The current costs page says Code Review “has no flat per-review price.”

How we tested

The package has a money module, a product type and a cart, with one test. The change under review adds discounts, pagination, shipping estimates, loyalty points, sales reports and a retry helper: 222 added lines in eight files, including eight new tests that cover only easy cases. All nine tests in the repository pass on both versions. We planted 12 bugs, the kind a human reviewer is expected to catch:

The four decoys are correct as written: a ceiling division on whole grams, -(-total_weight_g // BOX_CAPACITY_G); int(amount) for loyalty points, where the docstring says cents are dropped by policy; a range(len(revenues) - 1) loop that pairs each day with the next; and a retry loop that catches only TransientError, as its docstring says.

Twelve answer-key tests, kept outside the repository the reviewer could see, fail on the change and pass on a second version with all 12 bugs fixed (226 added lines). That fixed version is not free of problems, as the results show; it is free of the 12 we planted.

Our main runs used Claude Code 2.1.310 on Opus 5.5, the default model on our Max plan:

claude -p "/code-review medium main...HEAD" --output-format json \
  --setting-sources project,local \
  --allowedTools "Bash(git:*),Bash(python3:*),Read,Grep,Glob,Agent"

Each of the 19 main runs started in a fresh git worktree, with auto memory off (CLAUDE_CODE_DISABLE_AUTO_MEMORY=1) to keep one run’s notes from reaching the next. We didn’t grant the Edit or Write tools; the reviewer could read files, run git and run Python 3.14.7, which could still write files, and git showed no changes after any run. On the buggy change we ran low, medium and high three times each, xhigh twice and max once, plus medium and high once each with --max-findings all; on the fixed change, each level once. Costs are the total_cost_usd Claude Code reports, which uses API list prices; times are its duration_ms.

To sort findings on the fixed change, we used one rule. A real problem gives a wrong result or a crash for an input that the function’s signature and docstring allow, and we reproduced it. A suggestion needs an input that a code comment rules out (a coupon percentage above 100, against the field’s “0-100” comment) or that a store would treat as invalid (a negative weight), or is a design, naming, cleanup or test-coverage point. A Python 3.9 issue is counted on its own, because it matters only if the project supports 3.9. An incorrect example is a concrete result in a finding that the code doesn’t produce.

Results on the change with 12 bugs

“Named anywhere” counts bugs mentioned in the reply outside the list too. One finding sometimes covered two bugs; one medium run put the page count and the short slice in one item, which is why a 10-item list can hold 11 bugs.

The caps come from the review’s instructions. The subagent’s prompt spells out a plan per level. At low it reads low effort → 1 diff pass → no verify → ≤4 findings. At xhigh it is 10 inline angles → dedup (no verify) → sweep → ≤15 findings, and at max 5+5 angles × 8 candidates → 1-vote verify → sweep → ≤15 findings. The medium runs received exactly the plan the high runs did, a line labeled high effort with eight review angles and a cap of 10. Every medium and high run named all 12 bugs and filled its 10 slots. Five of the six said so in the reply (“cut by the 10-item cap”) and named the bugs that didn’t fit, usually one or both report bugs, in a note outside the list; the sixth put two bugs into each of two findings and fit all 12. At low, one run of three named all 12, listing four and the other eight in a short paragraph; the other two named only what they listed.

--max-findings all lifted the cap for about a cent more. One run each: medium listed all 12 bugs for $0.15 and high for $0.16, against $0.13–$0.14 and $0.14–$0.17 without the flag. Between them they also added a missing range check on the coupon percentage, a second place where the float bug leaks out, a remark that the cart and the shipping code use different weight units, cleanups, and a note that the tests cover only easy cases.

Only xhigh and max checked findings by running code. On the buggy change, none of the low, medium or high runs executed any code. Xhigh wrote and ran small Python checks for its correctness findings; one of the two runs said two lower-ranked findings were not run. Max’s agents reproduced each planted bug in Python.

The extra items on the buggy change. Apart from the 12, runs listed a real problem we hadn’t planted (the cart also changes a tags list the caller passes in), the date | None annotation that needs Python 3.10, test-coverage notes and suggestions. Max listed the ceiling-division decoy, for Decimal input, as one of two findings that “need inputs no current caller passes.” One item, in the high run with the cap lifted, said a negative coupon percentage raises the price through Cart.total; it doesn’t, because Cart.total takes the larger of the coupon and the volume discount, so only a direct call to apply_percent does that.

The same change with the bugs fixed

We reproduced each of these on the fixed code:

• with_retries(fn, retries=0) returns None without ever calling fn (all five levels).
• paginate([], 7) returns page 7 of 0 instead of raising “page out of range” (medium and up).
• Passing a datetime as today, which the date type hint allows, makes Cart.total raise TypeError when a coupon is applied (xhigh, max).
• The date | None annotation needs Python 3.10, so the cart module doesn’t import under the Python 3.9.6 that /usr/bin/python3 runs on our Mac, from Apple’s developer tools (xhigh, max). This matters only if the project has to run on 3.9.
• Orders whose placed_on is a datetime get one report row per timestamp, and mixing date and datetime values makes daily_rows raise TypeError (max).

The suggestions described the code accurately: coupon percentages above 100 aren’t rejected, negative weights can give zero or negative shipping, retries counts attempts rather than retries, coupon dates use the server’s time zone, two loops could be one. The two incorrect examples were the same box-count claim in the medium and high runs: that a Decimal weight of 12.5 gives one box, when the code returns zero; the high run also put the resulting shipping at $4.50, when it is $0.00.

On the decoys: xhigh and max said the ceiling division gives the wrong box count for Decimal or float weights, inputs its int type hint rules out, and medium, high, xhigh and max suggested rewriting the pairwise loop as a cleanup. The reviewers also labeled more items as bugs than we did: high called four of its eight items correctness bugs, and max called 17 of the 20 items it kept bugs.

The review’s instructions may help explain the long lists, though we didn’t test the review without them. For medium and high they say “Target at least 5 findings,” and for xhigh at least 7, followed by “do not invent to hit the floor.” They tell the finders to pass on half-believed candidates, because “finders that silently drop half-believed candidates are the dominant cause of misses.” And below max the plan has no separate verification step, although our xhigh runs ran checks anyway. On our fixed change, only low came back nearly empty.

What max does differently

Max is the only level where several agents did the work. On the buggy change the main agent sent the change to nine finder agents, each with a named angle: a line-by-line scan, an audit of removed behavior, a cross-file tracer, Python pitfalls, wrapper correctness, and reuse, simplification, efficiency and root-cause angles. It then started one verifier for each of the 19 distinct candidates they returned and finished with a sweep for gaps: 1 coordinating agent, 9 finders, 19 verifiers and 1 sweep, 30 agents in all, every one on Opus 5.5.

It listed 15 findings: the 12 planted bugs, each reproduced against the code; the Python 3.10 annotation, which it could only reason about; and two that it said “need inputs no current caller passes,” the ceiling-division decoy with Decimal weights and an unchecked coupon percentage. Its verifiers returned “15 confirmed, 3 plausible, 1 refuted.” The refuted candidate was the time-zone remark, judged “a normal design choice”; its verifier also noted that the coupon end-date bug got in the way of the example. Everything else that survived went into a note under the 15-item cap.

On the fixed change max ran 21 agents: 1 coordinator, 9 finders, 9 verifiers that each took one area of the code, 1 sweep and 1 verifier for the sweep’s two additions. Its verifiers checked 30 candidates and threw out 10; it kept 20 and listed 15, after 38 minutes and $22.64. That list held four real problems we hadn’t planted and the Python 3.9 issue, more than any other level. It kept the time-zone remark as plausible this time, on code where the coupon bug was gone, so two runs on different code don’t tell you how repeatable max’s verification is.

An earlier pass without Python

Before the main runs we ran low, medium, high, xhigh and max once each on the buggy change with only git and file reads allowed. Conditions also differed in other ways: python3 on that PATH was 3.9.6, four runs shared one worktree, and the low run was a smoke test with auto memory still on. Medium and high named all 12 bugs, as in the main runs. Xhigh listed all 12, tried to run the tests and was refused, and cost $0.43. Max took 34 minutes and $21.59, listed the same 12 bugs and said nothing had been executed.

How to use it

• For a normal change, run the default with the cap lifted: /code-review medium --max-findings all. On our change that listed all 12 bugs in about 30 seconds for $0.15 at list prices. In an interactive session the cap you type is remembered until you pass --max-findings default; in a -p run it isn’t.
• Use low as a quick check, not a full review. It lists at most four findings, the ones it is most confident in. In our runs that was four or five of 12 bugs.
• Use xhigh when you want findings checked by running code, and allow your test command (for us, python3). Our xhigh runs checked most of their findings, not all; its plan has no verification step, so that isn’t guaranteed.
• Keep max for changes where missing a bug would cost more than half an hour and about $20 of usage. On our change it listed the same 12 bugs as medium; what it added was a reproduction or a stated reason for each finding, and one candidate thrown out.
• Read the failure scenario, not just the summary. Every finding came with one. On the fixed change, they made it quick to tell a real edge case from a suggestion, and to spot the incorrect box count.
• The review follows CLAUDE.md and ignores REVIEW.md. REVIEW.md configures the managed Code Review service on GitHub. Put project review rules in CLAUDE.md for the local command.

What we didn’t test

• Real pull requests. One synthetic 222-line Python change with ordinary bugs. A larger change, another language, or bugs that need knowledge of a whole system may behave differently. Quickchat ran local /code-review at high on Sonnet 5.5, and at max with every review subagent forced onto Sonnet 5.5, on 20 hard pull requests from Martian’s Code Review Bench and reported 21 and 23 of 27 serious bugs matched. Its max runs had a $30 and 90-minute limit; the 19 that finished averaged $20.95 and 56 minutes, against $0.11 and 40 seconds at high. Five max reviews returned a closing note instead of findings, so Quickchat scored the last findings report recovered from their transcripts, and the one that timed out counted as zero.
• Other models. Everything ran on Opus 5.5.
• Repeat runs. Three runs at low, medium and high on the buggy change, two at xhigh, one at max, and one per level on the fixed change. That is too few to tell random variation from a real difference between levels.
• Interactive sessions. We used -p, which runs the review in the foreground; an interactive session runs it in the background.
• The managed Code Review service and ultrareview, which run in the cloud and bill usage credits.

Companion reading

• Claude Code’s /doctor prompt-audit, tested on nine planted problems — the same planted-problem method, applied to instruction files.
• Claude model tiers and effort levels — what each effort level changes outside code review.
• What agent traffic actually costs after Opus 5.5 — how list-price costs like the ones above are built.
• Claude Code usage limits — how included usage and usage credits work on Pro and Max.

Sources

1. Anthropic — Code Review is now generally available, 15 October 2026: Team and Enterprise, Quick/Standard/Deep levels, “Most reviews now finish about 3x faster (~20 minutes down to 6-10 minutes).”
2. Anthropic — How the Claude Code team does code review, Addy Osmani, Morgan Westlee Lunt and Qing Wang, 15 October 2026; Hacker News discussion, 487 points and 480 comments when checked on 25 October 2026.
3. Anthropic — Review locally with /code-review: effort levels, --max-findings, -p behavior, CLAUDE.md and REVIEW.md. Retrieved 25 October 2026.
4. Anthropic — Code Review costs and usage, “no flat per-review price,” retrieved 25 October 2026; and Code Review, whose copies in the Internet Archive up to 18:47 UTC on 15 October 2026 read “Each review averages $15-25 in cost.”
5. Anthropic — Find bugs with ultrareview, “Pricing and free runs.” Retrieved 25 October 2026.
6. Anthropic — Model configuration, “Adjust effort level”: Opus 5.5 defaults to medium; max “may show diminishing returns and is prone to overthinking.” Retrieved 25 October 2026.
7. Quickchat — What Claude Code’s multi-agent code review costs and finds, 21 October 2026.
8. Hacker News — Ask HN: How to deal with shipping AI-written code you don’t understand?, 19 October 2026; 619 points and 759 comments when checked on 25 October 2026.

Our own measurements, on one macOS machine on 25 October 2026, Pacific time: Claude Code 2.1.310, Opus 5.5, 19 main /code-review runs through claude -p with JSON output, each in a fresh git worktree, plus the 5 earlier runs described above; the review instructions, tool calls and agents from the session transcripts; the answer-key tests run with Python 3.14.7; and every problem we counted as real, and every example value, on the fixed version run by hand.

FAQ

What does /code-review do in Claude Code? It reviews the changes on your branch for correctness bugs and reports what it found in your conversation; depending on model and effort level it also suggests reuse, simplification and efficiency cleanups. It runs as a subagent in your own session, so it works on any plan and counts toward your plan’s usage or API billing. /review is an alias. With --fix it also applies the findings, and with --comment it posts them on a pull request. It is separate from Code Review, the managed GitHub service for Team and Enterprise plans, and from /code-review ultra, which runs in the cloud.

Which effort level should I use for /code-review? On our 222-line test change with 12 planted bugs, every run from medium up named all 12. Low listed at most four findings and covered four or five of the bugs. Medium, the default on Opus 5.5, cost $0.13 to $0.14 and about 30 seconds at API list prices, and in one run with --max-findings all it listed all 12. Xhigh listed all 12 within its 15-item list and wrote its own Python checks for most findings, for $0.32 to $0.36 and about 97 seconds. Max split the work across 30 agents, took 24 minutes and cost $18.73 at list prices, and listed the same 12. We ran each level only a few times, on one change.

Why does /code-review show only 10 findings? In Claude Code 2.1.310 the review’s instructions cap the list: at most 4 findings at low, 10 at medium and high, and 15 at xhigh and max. Bugs that don’t fit can end up in a note outside the list or folded into another finding. Pass --max-findings all, or a number, to change the cap; it requires Claude Code 2.1.288 or later. In one medium run with --max-findings all, the review listed all 12 of our planted bugs for $0.15.

What did /code-review report after the planted bugs were fixed? Findings at every level, on our change with all 12 planted bugs fixed: 1 at low, 10 at medium, 8 at high, 15 at xhigh and 15 at max. By our reading, one to four per level were real problems we hadn’t planted, which we reproduced, and xhigh and max also flagged a Python 3.9 incompatibility that matters only if you support 3.9. The rest were mostly suggestions: inputs the code’s comments or a store would treat as invalid, design, cleanup and test-coverage points. Two findings gave a wrong example value. The review instructions ask medium and high for at least 5 findings and xhigh for at least 7, while telling the reviewer not to invent any to reach that number.

How much does /code-review cost? On our 222-line change with Opus 5.5, at the API list prices Claude Code reports: $0.06 to $0.07 at low, $0.13 to $0.14 at medium, $0.14 to $0.17 at high, $0.32 to $0.36 at xhigh and $18.73 at max. On a Pro or Max plan, runs within your allowance use included usage. The managed Code Review service bills usage credits separately from plan usage and no longer quotes a per-review price; its documentation said reviews averaged $15 to $25 until 15 October 2026. Ultrareview includes three free runs per Pro or Max account, which don’t refresh, then typically costs $5 to $25 in usage credits.

What is the difference between /code-review, Code Review and ultrareview? /code-review is a command that runs in your own Claude Code session at the effort level you choose, on any plan. Code Review is a managed service for Team and Enterprise organizations that reviews GitHub pull requests through a GitHub App, at Quick, Standard or Deep levels, billed through usage credits; it became generally available on 15 October 2026. Ultrareview, started with /code-review ultra, runs a fleet of reviewer agents in a cloud sandbox; Anthropic’s documentation says each finding is independently reproduced and verified and a review typically takes 15 to 25 minutes.