Cost Per Code Review: What Automated Review Actually Costs

Automated code review is one of the easiest LLM features to justify on paper. A pull request is a few thousand tokens, review costs pennies, and an engineer's time costs considerably more. The arithmetic looks settled before anyone runs it.

Then it runs on real repositories and the per-review figure is several times the estimate. The gap is entirely in things the naive calculation omits.

The naive calculation

Take a pull request with a 400-line diff, roughly 6,000 tokens. Add a system prompt describing your conventions, say 2,000 tokens. The model writes 1,500 tokens of comments.

On DeepSeek V4 Pro at around $0.44 per million input and $0.87 per million output, that is about $0.0035 input and $0.0013 output. Under half a cent per review. On Kimi K3 at $3 and $15, about $0.05.

Either figure is trivially affordable against engineer time, which is why the feature gets built. The estimate is not wrong; it is incomplete.

What the estimate leaves out

Context beyond the diff. A diff alone is not reviewable. Understanding whether a change is correct usually requires the surrounding function, the callers, the tests, and sometimes the interface being implemented. A useful review pulls in five to ten times the diff's own token count, which moves the per-review figure by the same multiple.

Re-reviews. A pull request is not reviewed once. It is reviewed, changed, reviewed again — three or four times is normal on a non-trivial change. If each re-review re-reads the full context, multiply accordingly.

The tail of large diffs. Diff size is heavily skewed. Most pull requests are small and a few are enormous, and the enormous ones dominate total spend. A calculation based on the median understates the mean substantially. Always compute against your actual distribution, not a typical case.

Reasoning tokens. If the model reasons before answering, you pay for tokens that never appear in the output. On a review task with real analysis this can exceed the visible comment length several times over.

The realistic figure

Putting those together: a 6,000-token diff with 40,000 tokens of surrounding context, reviewed three times, is roughly 138,000 input tokens and perhaps 6,000 output across the life of the pull request.

On DeepSeek V4 Pro that is about $0.066. On Kimi K3, about $0.50. Still cheap against engineer time, but ten to fifteen times the naive estimate — and that multiple is what turns a rounding error into a line item at a thousand pull requests a month.

Caching is the main lever

Review workloads are unusually cacheable, and most implementations fail to exploit it.

The system prompt and convention guide are identical on every review. On re-reviews, most of the surrounding context is unchanged too. Structuring the prompt so all of that sits in a stable prefix, with only the diff varying at the end, moves the majority of input to the cached rate.

At Kimi K3's $0.30 cached against $3 standard, that is close to an order of magnitude on the dominant cost component. Prompt caching savings math covers the arrangement, and the common mistake of putting a timestamp or a pull request identifier above the stable content.

False positives cost more than tokens

The expensive failure mode is not spend. It is a reviewer that comments on everything.

A review bot producing fifteen comments per pull request, of which two matter, trains the team to skim and dismiss. Once that happens, the real findings are missed too, and you are paying for a system that has made review worse while appearing to work.

The fix is precision over recall: instruct the model to report only high-confidence, material issues and to stay silent otherwise. A bot that comments on one in four pull requests and is right when it does is worth far more than one that always has something to say. Code review automation covers the design.

Measuring it properly

Track cost per pull request rather than cost per review call, because a pull request is the unit the business cares about and it spans several calls.

Then track the distribution, not the mean, and look specifically at the top decile. Large diffs and heavily-iterated pull requests will be most of your bill, and both have contained fixes — a size ceiling above which the bot reviews only structure rather than every line, and incremental re-review that reads only what changed.

Finally, track comment acceptance rate. Cost per useful comment is the figure that tells you whether the feature is worth running at all, and it is the one nobody instruments. AI cost per pull request covers the wider accounting.