The Re-Review Tax

Abstract.

AI code review went from novelty to default in about two years: Stack Overflow's Developer Survey found 47% of professional developers had used AI-assisted code review in the past year, up from 22% in 2024 and 11% in 2023, and GitHub's Octoverse 2025 counted 1.3 million repositories running at least one AI code review integration, a 4x jump from roughly 300,000 in late 2024. That adoption curve created a new, mostly invisible line item: an LLM call on every pull request, and on most tools, on every push to that pull request. A four-commit PR does not get reviewed once. It gets reviewed up to four times, and by default, most of those passes resend the same diff and the same repo context they just billed for on the previous push. This post covers what that redundant pass actually costs at scale, why the leading tools are quietly moving to incremental re-review to fix it, and how the same severity-tiered routing that already governs a cost-aware LLM gateway maps cleanly onto "which finding needs which model" inside a review bot.

All dollar figures beyond the cited adoption and pricing data are illustrative, built from a stated cost model, not measured production traces from any specific vendor.

The pattern nobody priced.

A pull request review is not one LLM call. It is one call per meaningful push, because a reviewer, human or automated, has to see the latest code before it can comment on it. The naive way to build that is stateless: on every push, resend the diff, resend the touched files, resend enough of the repo (imports, related tests, style config) for the model to have real context, and generate a fresh set of comments.

That design has a specific, avoidable waste built into it. A PR that gets pushed to four times over its review cycle, once initially and three more times addressing feedback, does not need four independent full reviews. It needs one full review and three checks: did the new commit fix what was flagged, and did it introduce anything new in the diff since the last pass. Re-running the full pipeline on every push bills for repo context that has not changed at all, on top of the small slice of diff that has.

The leading tools have started fixing exactly this. Rewind's Diff Vader runs in verifier mode by default on a re-push: instead of re-scanning the whole diff, it checks whether prior findings are now resolved, which the team describes as roughly ten times cheaper than a full re-review, and which avoids review loops where every push surfaces a fresh, unrelated set of comments. Cloudflare's internal review pipeline does the same thing structurally: an incremental re-review that is aware of its own previous findings, rather than a stateless restart. The pattern is the same one this blog has covered on the token-generation side, where retrying blind on the cheap tier bills full price for zero new information: a re-review that does not know what changed pays full price to relearn what it already knew.

Methodology.

This is an illustrative cost model, not a benchmark run against any specific vendor's production traffic. The point is the shape of the tradeoff, not the exact dollar figure your team would see.

Three configurations follow from these inputs: a naive bot that re-runs a full pass on every push, an incremental-aware bot that only re-scans what changed, and an incremental bot that also routes each candidate finding to a model tier sized for its severity, on top of a cached repo/file context.

What the re-review tax costs at 1,600 PRs a month.

Adoption did not plateau after the first wave of tools; it compounded. Every one of those 1.3 million repos is now generating LLM calls on a schedule set by push frequency, not by a human reviewer's calendar, which is exactly why the per-push cost of review deserves the same scrutiny that per-request routing already gets everywhere else in a stack.

Two-thirds of the naive bill disappears just from not re-sending unchanged context on every push, the same mechanical fix Diff Vader and Cloudflare's pipeline both landed on independently. The remaining gap between $880 and $384 is not about scanning less, it is about matching the model to the finding: most of what a review bot flags does not need a frontier model to catch it, and the passes that do need one are a small, identifiable share of the traffic.

Not every comment needs the same model.

A code review bot's output is a mix of severities, and treating all of them as one undifferentiated LLM call is the same mistake as sending every request to the same model regardless of difficulty.

The 70/25/5 split is representative, not a measured average across tools, but the shape holds across most review workloads: the bulk of what gets flagged is mechanical, and the findings that actually justify a frontier model's price are a minority. A bot that runs every finding through the same expensive model is paying premium prices for the 70% that a small model would have caught identically.

Implementation framework.

Step 1: Make re-review commit-aware, not PR-aware. Diff the new commits against the last reviewed SHA, not the PR's base branch. If nothing changed outside what was already reviewed, don't re-run the pipeline at all, just re-check whether prior findings still apply.

Step 2: Separate "check if this is resolved" from "review from scratch." A resolution check only needs the specific hunk a prior finding pointed at plus the new commit, not the full file and repo context a first pass needs.

Step 3: Route findings by severity, not by PR. A single review pass can and should call more than one model tier: a cheap model drafts candidate issues, and only the subset flagged as logic-level or security-relevant escalates to a stronger model for confirmation.

Step 4: Cache what does not change between pushes. Style guides, lint config, and the parts of the repo map that are stable across a PR's lifetime are exactly the kind of static prefix prompt caching is built for; resending them fresh on every push is paying the cache-miss price for content that never moved.

def review_push(pr, prior_review, cheap_model, mid_model, premium_model, verifier):
    """Only re-scan what changed since the last reviewed commit; route each
    candidate finding by severity instead of running the whole diff through
    one model."""
    new_hunks = pr.diff_since(prior_review.commit_sha)
    if not new_hunks:
        return prior_review.reconfirm_open_findings()  # verifier mode, no full rescan

    findings = []
    for hunk in new_hunks:
        draft = cheap_model.flag_issues(hunk)
        for issue in draft.issues:
            if issue.severity == "style":
                findings.append(issue)
            elif issue.severity == "logic":
                findings.append(mid_model.confirm(hunk, issue))
            else:  # security or architecture
                confirmed = premium_model.confirm(hunk, issue)
                findings.append(verifier.check(confirmed))

    return prior_review.merge(findings, resolved=prior_review.check_resolved(new_hunks))

Step 5: Instrument cost per PR, not just per review call. A dashboard that shows cost per individual API call hides the multiplier from repeated pushes. Cost per PR, including every re-review it triggered, is the number that tracks what a heavily-iterated PR actually costs versus one that merged clean on the first pass.

What this doesn't solve.

Incremental, hunk-scoped review can miss issues that only become visible with full-file or cross-file context, a variable renamed in one hunk that breaks an assumption three files away won't show up in a diff-only pass. Tools that ship incremental re-review generally still run a full pass at PR open and often before merge, for exactly this reason; incremental mode is for the iteration in between, not a full replacement for a whole-file read. The severity split used here is also a simplification: a real classifier needs calibration against your own codebase's false-positive rate, and a cheap model that under-flags security-relevant patterns is a worse outcome than one that costs slightly more.

Conclusion.

The interesting thing about the re-review tax is that it is not a new failure mode. It is the same one this blog has tracked in agent loops and retry logic, applied to a category that grew fast enough that almost nobody priced it before shipping it: a stateless pass that re-sends everything it already saw, on a schedule it doesn't control, billed at whatever the single model behind it costs regardless of what it's actually looking at.

If you're running an in-house review bot on top of an LLM API, which plenty of teams do to keep diffs and findings inside their own infrastructure, the fix doesn't require building a new routing layer from scratch. Point its OpenAI-compatible calls at Nadir with model=auto, and the cheap-model-first, verifier-escalated pattern in the code above runs on every request without a separate classifier to maintain, while cached, unchanged context (style guides, repo maps, system prompts) stops getting billed twice. The 1.3 million repos already running an AI reviewer are proof the category isn't going away. Whether the bill scales with how much actually changed, or with how many times someone pushed, is still a design choice.

Data and charts beyond the cited adoption figures are illustrative, built from a stated cost model, not measured production traces. Sources: [Stack Overflow, "2025 Developer Survey"](https://survey.stackoverflow.co/2025/). [GitHub, "Octoverse 2025"](https://github.blog/news-insights/octoverse/). [Rewind, "Review is the bottleneck now: How we let AI approve pull requests (safely)"](https://rewind.com/blog/ai-approve-pull-requests-safely/). [Cloudflare Blog, "Orchestrating AI Code Review at scale"](https://blog.cloudflare.com/ai-code-review/). [Sourcegraph, "AI Code Review in 2026: How It Works and How to Adopt It"](https://sourcegraph.com/blog/ai-code-review).