From $2.43 to $0.77 per review: Cloudflare has cut the cost of each run of its AI code reviewer by 68%, and the median review now takes 1m 32s instead of 4m 9s. The headline number matters less than where the money was going: almost all of it paid for context the model had already seen.
How a review doubled in cost without an architecture change
In April an average review cost $1.19; by the end of August it was about $2.46. The design hadn't moved: a coordinator hands work to specialist reviewers (code quality, security, performance, documentation, internal standards) based on the risk tier of the change. Everything around it had:
- Models: in August every reviewer moved to Anthropic models because they did better in Cloudflare's evals, and the cost per job went from $1.38 to $2.03. The internal standards reviewer ended up on Claude Opus 4.7 and went from $0.25 to $0.88 per review, more than the coordinator itself.
- Context: tokens per review tripled, from 0.91 to 2.99 million. The cache hit rate rose from 85.7% to 97%, but 97% of three times the tokens is still far more expensive.
- Bigger changes: 65% of reviews now landed in the most expensive tier, up from 59% in March.
Before the optimization work, spend broke down as 43% cache writes, 34% cache reads and only 23% output tokens. Three quarters of the bill was resending the conversation. The code quality reviewer made 16.6 model calls per review, each one carrying the full history: 72k tokens written to cache and 1.08 million read back.
The bug: the first request almost never hit the cache
Anthropic's prompt cache stores prefixes: the start of the conversation up to a cache breakpoint. Writes cost 1.25 times the input price, reads 0.1 times, and an entry expires after five minutes unless something reads it.
Every session began with the same tools and the same agent prompt, 11k to 21k tokens identical across all repositories. Yet the first request found a cached prefix only 14% to 26% of the time. The culprit was OpenCode v1: it built a single system block with the prompt followed by an environment section holding the working directory and the date, and put the only breakpoint at the end. The shared part was never cached on its own, so a review in one repository could never reuse what another had written.
The fix, shipped on September 16, 2026, was a marker at the end of every agent prompt and a hook that splits the block in two at that marker. The first half now ends on bytes every job shares and gets its own breakpoint. Keeping it that way meant removing anything repository-specific in front of it: the list of available skills and any tool description that could vary between jobs.
The same day, the internal standards reviewer's reference index moved into its prompt; it used to burn its first three turns reading those files. Calls per run dropped from 15.9 to 9.6 and cost from $1.12 to $0.72. Together, these two changes took a review from $2.47 to $2.02.
Fewer calls, same findings
Next came a batch of small changes that together removed about $0.20 per review:
- Sub-reviewers could see the tool that posts the final comment; in 57% to 76% of sessions they tried to call it, got rejected by the server and spent another call recovering. Removing it also dropped 2.9k tokens of tool definitions per request.
- Reading every file in parallel in the first response instead of one per turn (64% of turns made exactly one tool call).
- Skipping reviewers with nothing new to look at on re-reviews, which are two thirds of all jobs.
- Dropping the extra turn that wrote a summary nobody read: about $0.07 per job.
- Actually cancelling cancelled jobs: GitLab's Kubernetes executor doesn't signal the script on cancellation, and 358 of 446 cancelled jobs kept running until the review was done.
The subtlest change was making the code quality, security and performance reviewers send an identical first request (tools, shared rules and the full merge request) and append their own instructions afterwards. A cache entry can't be read until the response that wrote it starts streaming, so two of them wait up to 20 seconds for the first. It costs a little latency and saves about nine cents per reviewer.
Even so, code changes account for $0.65 of the $1.67 saved; the other $1.06 came from models and effort levels. Opus 5.5 at medium effort showed no measurable difference from Opus 5, and its lower per-token price explains only about $0.20 of the drop: the rest is sending and generating fewer tokens. Sonnet 5.5 costs the same per token as Sonnet 5, yet in a 50/50 split it came out 47% to 62% cheaper per run because it uses far fewer tokens.
What carries over
The main lesson is to measure what actually reaches the provider. Cloudflare didn't find the problem in the invoice; it found it by logging token usage and a hash of the first system block of every session. If your agent puts the date, the branch or the tool list in front of the shared prompt, you pay a cache write on every start. Ordering context from most stable to most variable costs nothing and pays off more than anything else.
The second is that cheaper doesn't have to mean worse, but you have to prove it. On Sonnet 5.5 at high effort, the code quality reviewer posts 40% fewer critical and warning findings, yet authors act on 59% of them (up from 34%) and important findings per review went from 0.28 to 0.30. What disappeared was noise: findings with inflated severity fell by 70%. The performance reviewer at medium effort, on the other hand, did lose real findings, about 64% fewer important issues. High effort costs 61% more per run and yields 58% more serious findings, and for code quality it's worth it.
What doesn't transfer
The reviewer is an internal tool built on OpenCode, and the prompt-splitting hook relies on its plugin system. Several comparisons are before-and-after each release with no control group, and the "now" window in the quality analysis is a single day with 35 to 66 findings per group. Treat the proportions as guidance; the exact figures belong to Cloudflare's workload.
Sources
- Cutting our inference bill by 68% by being obsessive about optimization, Cloudflare Blog, October 19, 2026.