Cloudflare cuts AI code review cost per run from $2.43 to $0.77

AI code review costs drop 68%: Cloudflare's item-by-item optimization from prompt caching to model selection

Author @_ryanskidmore shares: @Cloudflare's internal AI code review cost per run dropped from $2.43 to $0.77, and median review time fell from 4m9s to 1m32s, while the number of real issues found in the code quality category stayed roughly the same. About 40% of the savings came from engineering changes, and about 60% from switching models and adjusting reasoning effort. https://t.co/Cu0lhhQxVs

Why did costs double? · From March to August, cost per review rose from $1.22 to $2.32, with no major architectural changes. · A small part was due to more large changes: the share of full-review runs rose from 59% to 65%. · The main cause was switching models: starting in August, all review roles switched to Claude models, and cost per run rose from $1.38 to $2.03. After the internal standards review role Codex switched to Opus 4.7, its cost per run rose from about $0.25 to $0.88. · Cache hit rate rose from 85.7% to 97%, but tokens per review rose from 0.91M to 2.99M, more than tripling, so the total bill still went up. · Cost breakdown before optimization: cache writes accounted for 43%, cache reads 34%, and output only 23%. The money was mainly spent on context the model had already seen or was about to see repeatedly.

Engineering optimizations (contributing $0.65 of the $1.67 reduction) 1. Sharing the cache prefix across repositories, the single largest gain. Each session begins with 11k–21k tokens of tool definitions and system prompts that are identical across all repositories, but the cache hit rate for the first request of a session was only 14%–26%. The cause was that OpenCode v1 concatenated the shared prompt with environment information such as working directory and date into a single block, with only one cache breakpoint at the end of the block, so the shared portion was never cached separately. The fix was to add a marker at the end of the shared portion, split the block in two, and remove all repository-related content before the breakpoint. On the same day, they also wrote the reference index used for standards review directly into the prompt, and its number of LLM calls dropped from 15.9 to 9.6. Together these two changes reduced cost per run from $2.47 to $2.02.

2. A batch of small changes saving about $0.20 per run in total: · Removing a tool that sub-review roles could not use. 57%–76% of sessions had mistakenly called this tool. · Reading files in parallel. Previously 64% of turns called the tool only once. · Skipping review roles with nothing new to look at during re-review. About 2/3 of tasks are re-reviews. · Ending immediately after review results are emitted, instead of running another round to write a summary nobody reads. · Handling timeouts and provider failures separately. · Fixing the issue where GitLab tasks kept running after cancellation. Of the 446 sampled canceled tasks, 358 ran the review to completion.

3. Three review roles share the same prefix. The first requests of the code quality, security, and performance roles are identical; one writes the cache and the other two wait up to 20 seconds before reading, saving about 9 cents per role per run.

Model and effort adjustments (contributing $1.06) · The coordination role switched to Opus 5.5 at medium effort, with no measurable change in review conclusions compared with Opus 5. High effort was more expensive but did not noticeably increase the issues found. · Sonnet 5 and Sonnet 5.5 have the same price per token, but 5.5 uses far fewer tokens, with cost per run 47%–62% lower. The code quality role at medium effort makes only 1.7 LLM calls per run, down from 6.2. · The lower unit price contributed only about $0.20; the rest came from reduced token usage: cache reads down 82%, cache writes down 54%, and output down 67%. · The code quality role switched to high effort: cost is 61% higher (about 2 cents more per run), and severe and warning-level findings are 58% higher.

Review quality: validated with two methods · On the surface, severe findings dropped noticeably: code quality -40%, security -56%, performance -71%. · Whether the author changed code based on them: the adoption rate of severe code quality findings rose from 34% to 59% (the baseline for coincidentally changing the same line is about 15%). The number of findings that led to changes per thousand reviews was 132 versus 145 previously, within the margin of error. Across the four roles combined, it rose from 229 to 321. · Blind evaluation: models from two different providers judged 657 findings, and disagreements were sent to a third model. "Important" findings went from 0.28 per run to 0.30, with overlapping confidence intervals. Findings with overstated severity dropped from 0.46 per run to 0.14, a 70% reduction, the clearest result in the whole article. · Conclusions vary by role: code quality at high effort mainly removed noise and inflated severity. At medium effort it did miss real issues. The performance role had about 64% fewer important findings, and the security role dropped by about a quarter but not significantly; these two are next to be tested at high effort. · Reliability also improved: the share of reviews that produced no conclusion dropped from 0.79% to 0.27%, and the security role's retry rate dropped from 3.5% to 0.04%.