Keeping AI code review affordable at scale

AI code review has an awkward property: the organizations that benefit most — many engineers, many repositories, many pull requests — are the ones for whom a naive implementation costs the most. Reviewing every change with the most capable model available is simple to build and expensive to run, and most of that spend buys nothing. A one-line documentation fix does not need the same reviewer as a change to how payments are captured.

MergeHarbor treats cost as a design constraint, not an afterthought. Three ideas keep it predictable.

1. Route each task, not each customer

A review is several tasks: deciding whether deep review is needed, the review itself, verifying findings, summarizing large changes, and summarizing files for the index. They have very different requirements, and MergeHarbor chooses a model for each one, per pull request.

The decision uses signals that predict risk:

• Size and spread — lines changed, modules touched, symbols modified.
• Reach — how many callers depend on the changed code.
• Criticality — authentication, cryptography, payments, migrations, infrastructure code, release branches, and labels such as security or hotfix.
• History — whether this repository’s changes tend to contain defects.
• Policy and budget — the organization’s cost mode, allowed providers, and how much of the monthly budget remains.

Low-risk changes go to fast, inexpensive models. High-risk changes get the strongest reviewer, and a quality floor guarantees that budget pressure never pushes a critical change below it. If a less expensive reviewer reports a critical finding or low confidence, the review escalates to a stronger model before anything is posted. Verification runs one tier below the reviewer, because confirming a specific claim is easier than finding it.

Every decision is recorded with a plain-language explanation, so an administrator can see exactly why a pull request was reviewed the way it was.

2. Don’t do work that isn’t needed

The least expensive model call is the one you never make:

• Trivial changes are skipped. Documentation, lockfiles, and generated code don’t trigger a model call, unless a secret or an attempt to steer the reviewer is detected.
• Pushes are coalesced. A burst of commits produces one review after the branch settles.
• Reviews are incremental. After the first review, only the new commits are reviewed, and earlier findings carry forward.
• Results are reused. Files that haven’t changed since the last review are not reviewed again.
• Context is cached and bounded. Stable instructions are cached by the model provider, and each tier has limits on how much the agent reads.
• Background work is batched. File summaries for the index don’t need an immediate answer, so they run through providers’ batch interfaces at a lower price.

3. Measure everything

Every model call is priced and attributed to an organization, repository, and author. Administrators see cost per review, per pull request, and per active developer; the margin against what they pay; and the difference between actual cost and what the same reviews would have cost on a single top-tier model.

Budgets are enforced, not just reported. An organization can choose to be warned or to pause automatic reviews when spend approaches its monthly limit — explicit requests from engineers still run.

The result

Routing, avoided work, and measurement compound. Most pull requests in a typical codebase are small and low-risk, and they are reviewed quickly and inexpensively. The changes that can take down production or leak data get the deepest review available. And because cost is visible per organization, it can be managed like any other infrastructure spend.

That is what makes it possible to put a capable reviewer on every pull request across an entire engineering organization — at a price that makes sense.