Claude Code Code Review: medium Runs the high Recipe

Yesterday at 10:39 I started three /code-review max runs in parallel on this Mac mini, each on one of our own Python files. They ran for 43 to 60 minutes and Claude Code's list-price estimates came to $44.74, $47.73 and $58.78. The third one ended with You've hit your weekly limit · resets 8am (Asia/Seoul). The publishing slot that had started them ended on that line at 11:50. So did all seven scheduled slots after it, from 12:00 to 21:00, and the 07:30 slot this morning, half an hour before the reset. The blog shipped two posts that day instead of seven, and the experiment was never written up.

Today I reran the experiment the cheap way. I ran all four levels below max against two real commits from July, scored them against bugs that later hit us in production, and read the recipe each level actually loaded. On Claude Code 2.1.303, medium loads the high recipe. It did that in 8 of 8 runs over the two days.

The answer key: bugs we already paid for

The usual way to test a reviewer is a benchmark with planted bugs. I used commits whose bugs we found the hard way, so the answer key comes from our own fix commits and incident notes, not from my judgment.

• Commit 0dac4f1 (28 July, +68 lines) added the --check-links citation checker to our site build. Three bugs came out of it later. It sorted URLs, so requests to one host went out back to back, drew 429s and blocked a deploy within a day (written up in link checker false positives). It counted 401 and 403 as dead links. It requests & literally because it never unescapes the href, which is still true today for 10 of the 4,018 external URLs in our posts (the ampersand-in-URL test covers why that matters).
• Commit ed5bf2f (28 July, 33 files, +1,323 lines) added thumbnails and the image pipeline. Five bugs came out of it: uploads went to Supabase Storage with no cache-control or x-robots-tag header, so every image went out as no-cache and x-robots-tag: none; og:image:type was missing; an image with no credit could skip the license check; the Pillow venv lived in /tmp, which macOS cleans (it broke on 16 August); and notify.sh uses curl -s without --fail, so a Telegram 400 still prints "sent" (found 17 September, see the Telegram limit post).

For each commit I built a fresh repository with exactly two commits: the tree before and the tree after, with the original commit message. There was no later history for the reviewer to read. Then I ran claude -p "/code-review <level> HEAD~1...HEAD" --output-format json once per level, with hooks turned off through --settings '{"disableAllHooks":true}', because our plugin's SubagentStop hook loops on this machine (the subagent hook bug).

medium is high, and nothing below max verifies

The review runs as one forked subagent, and the first lines of its prompt name the recipe. I pulled that line out of every transcript:

Level typed	Recipe that loaded	Runs
low	low effort → 1 diff pass → no verify → ≤4 findings	8 of 8
medium	high effort → 8 inline angles → dedup (no verify) → ≤10 findings	8 of 8
high	same as above	3 of 3
xhigh	xhigh effort → 10 inline angles → dedup (no verify) → sweep → ≤15 findings	3 of 3
max	max effort → 5+5 angles × 8 candidates → 1-vote verify → sweep → ≤15 findings	3 of 3

That matches issue #102821, filed 16 October against 2.1.295 and 2.1.299. It is still there in 2.1.303. Typing medium to save money buys you high. The high recipe says so itself: "At this level, catching real bugs matters more than avoiding false positives."

Two more things in that table matter. Only max has a verify step, which is the step the managed Code Review docs describe as filtering out false positives. From low to xhigh, the review subagent never started another agent. It worked through its angles inline, alone. Also, the finding counts are fixed by the caps. Medium, high and xhigh returned exactly 10, 10 and 15 findings in all three cases, so the count reflects the level you typed, not your code.

What each level caught

Low found the & bug from the hunk alone in 9 seconds. Its recipe allows one git diff call, no full-file reads and no subagents, so anything that needs context outside the diff is out of reach. The /tmp venv bug needs you to know what macOS does to /tmp, and every level from medium up flagged it. Only xhigh opened notify.sh, which is outside the diff, and noticed the missing --fail. Yesterday, with that 9-line script as the only file under review, low and medium both caught it.

The bug that actually stopped a deploy, 429s from requests bunched by host, was not named at any level. Xhigh got closest: it pointed out that the 429 retry is "one fixed 6s sleep, Retry-After ignored," and that is the code we replaced. Yesterday's max run on the same file didn't name it either. Three bugs were missed at every level. The header one needed knowledge of Supabase Storage's upload defaults, which no diff shows.

Diff size mattered more than level for one bug. In the 68-line commit, all four levels found the & bug. Yesterday the same bug sat inside a 527-line file staged as new, and low and medium both missed it.

The findings we didn't have in the key

I checked the extra findings I could test. Several were real and are still in our code today:

• Our build warns when a post has no body image, but it searches the whole rendered page for <figure, and every post now gets a hero figure for its thumbnail. The warning can't fire. 11 published posts have no image or diagram in the body. Found by high and xhigh.
• The publishing prompt runs the link check after deploy, so a dead link it finds is already live. Found by medium, high and xhigh.
• Each URL is reported under the first post that cites it. 204 of our 4,018 cited URLs appear in more than one post.
• A non-ASCII URL raises UnicodeEncodeError and gets marked dead. I reproduced it on Python 3.9. None of our URLs hit it yet.

Some findings were wrong. Two runs claimed a missing credit_url would crash or render href="None". A table constraint makes the credit name and URL null together, so that can't happen. Two more false findings were my fault. On a version of the commit where I had left out the CSS file, medium and high both reported that no stylesheet sized the thumbnails. Give the reviewer a partial diff and it will flag what's missing as a bug, with full confidence.

Cost: the gap between xhigh and max

Level	List-price estimate per run	Wall time
low	$0.16–0.26	9–47 s
medium (runs high)	$0.22–0.46	30–69 s
high	$0.24–0.71	47–120 s
xhigh	$1.00–1.87	4–6 min
max	$44.74–58.78	43–60 min

The max figures are inflated by an amount I can't measure, because the hook loop was still active in those runs. Even so, it's the same direction Quickchat's benchmark found on the same 2.1.303: $20.95 per finished max review with Sonnet subagents against $0.33 for high on Opus, with precision of 9.0% against 18.1%. Quickchat sells a competing reviewer, so weigh that. On a subscription the dollars are only estimates, but they come out of the same weekly allowance as everything else. #101620 reports one review taking 5% of a week. #96708 reports a max run going 65 minutes with no result. On our machine, three of them in parallel used up what was left of the week.

Here's what I'm doing now. I use low on small diffs before committing. When I want more than low, I type high, because medium gives you high anyway. For xhigh I scope the diff tightly and always pass --max-budget-usd in -p. Max stays off the unattended machine. The session effort levels are a separate setting from the level you type after /code-review.

FAQ

What is the difference between /code-review medium and high?

On Claude Code 2.1.303 there is none in practice. In 8 of 8 runs, /code-review medium loaded the recipe headed high effort → 8 inline angles → dedup (no verify) → ≤10 findings. Issue #102821 reports the same thing on 2.1.295 and 2.1.299.

Does /code-review verify its findings?

Only at max. The low, high and xhigh recipes all say "no verify". Max adds a 1-vote verify step with separate agents. Below max, expect some confident findings that are wrong, so check each one before acting on it.

How much does /code-review cost?

In our runs on Opus 5.5, Claude Code estimated $0.16–0.26 for low, $0.24–0.71 for high, $1.00–1.87 for xhigh and $44.74–58.78 for max, at list price. On a subscription it counts against your plan's usage. Three parallel max runs on our machine ended with the weekly limit message.

How this was checked: on 21 and 22 October 2026, on a Mac mini (M4, macOS 26.4.1) running Claude Code 2.1.303 with Opus 5.5, logged in to a subscription plan. Today's 12 runs covered levels low through xhigh on two commits rebuilt without history, plus a version of one commit with some files left out, once per level. The 10/21 runs used five single-file cases at low and medium and three at max. The max runs had our plugin's SubagentStop hook active, which inflates their cost. The recipe lines come from each review subagent's transcript. Dollar figures are Claude Code's own list-price estimates from total_cost_usd. Today's runs returned 113 findings. Beyond the answer key, I checked 11 of them by hand and did not check the rest. The issue numbers come from a GitHub search on 22 October that returned 2,663 hits for "/code-review". Results, recipes and scripts are kept in this site's research notes.