Setting a Maximum Review Cost per Agent Branch: A Policy Guide

Do not invent the number. Measure it. Pull the last twenty merged agent branches, and for each one record reviewer minutes (from assignment to merge decision, minus idle time waiting on the author) and review token spend from your provider's usage records. Take the median of each, not the mean, because a single 900-line monster will drag a mean so far up that the cap becomes meaningless.

A worked baseline looks like this:

Notice the changed-lines figure. The research on review effectiveness is fairly consistent that defect discovery starts falling off well before a reviewer reaches a thousand lines; one summary of code inspection studies puts the useful ceiling at roughly 400 lines per review pass, with the rate of defect detection dropping above that per this summary of the studies. That gives you a second, cheaper trigger for splitting a branch that has nothing to do with money.

Set the starting cap at the median plus a margin. A simple rule that holds up in practice: cap minutes at 1.5 times the median, cap tokens at 1.5 times the median token figure, and adopt whichever limit trips first. With the numbers above, that is 51 reviewer minutes and 270,000 review tokens per branch.

Cost attribution for tokens needs the same care as minute tracking. Provider dashboards aggregate by API key or project, which tells you nothing about which branch spent the money. If you route model calls through a gateway, tag every request with branch metadata at the edge so spend can be rolled up per branch, the approach described in this write-up on LLM cost attribution. If you call providers directly, request IDs returned on each call can be logged alongside the branch ref and reconciled later.

One cap for every branch is wrong in both directions. A change to a pricing calculation deserves more review than a README edit, and agents that touch authentication should not be reviewed against the same budget as agents that rename variables. Multiply the baseline cap by a tier factor.

Two rules keep the tiers honest. The tier is assigned when the branch is opened, by whoever triggers the agent, and changing it later requires a written reason in the branch description. And the factor multiplies the cap, never the spend: an agent that generated 40,000 changed lines does not get a bigger budget because it declared itself high risk.

The tier also decides who can waive the cap. Low tier branches can be waived by any reviewer. Standard and high tier need the reviewing team's lead. Critical tier has no automated waiver at all, which is the point of having a critical tier.

Metering is where most policies die, because teams track the wrong thing. Reviewer minutes measured as "time the review tab was open" overcounts idle time and punishes reviewers who think before commenting. Measure from the moment a reviewer is assigned or starts an automated review to the moment the merge decision is recorded, then subtract time the branch spent waiting on the author. If your tracker cannot do that subtraction automatically, sample it weekly and accept the noise.

Tokens are easier to meter and easier to misattribute. A useful pattern is a small record per branch, updated by a hook whenever a review run finishes:

{
  "branch": "agent/refactor-orders-api",
  "first_commit": "2026-10-02T09:14:00Z",
  "risk_tier": "standard",
  "cap_minutes": 51,
  "cap_tokens": 270000,
  "spent_minutes": 38,
  "spent_tokens": 214500,
  "decisions": ["split-warning-issued", "cap-raised-to-540000"]
}

The decisions array matters more than the numbers. Any cap raise, split decision or escalation writes an entry. When someone asks six weeks later why a branch got double its budget, the answer is in the record.

One practical lever before you set stricter caps: run deterministic checks first. Static analysis, formatting and lint checks cost far less than model tokens and catch the mechanical issues that otherwise consume both review time and tokens. The argument for putting deterministic tooling ahead of model-based review, and the token savings it produces, is made in this analysis of AI code review costs. Pre-commit hooks are a cheap way to enforce part of this before a branch is even pushed; pre-commit runs configured hooks on every commit and can flag whitespace, missing end-of-file newlines and debug statements, which the standard hook set covers directly. A hook that fixes trailing whitespace sounds trivial until you compare the token cost of a model reading a diff full of noise.

For teams wiring review into CI, there are now several patterns for running an automated reviewer on every push, and published cost figures vary widely enough that you should not budget from a single vendor's number. GitLab advertises a flat rate per agentic review on its platform as described in this announcement, while other write-ups estimate roughly ten to fifty cents per pull request for a lighter model-based review per this CI walkthrough. If you need a single API for text, image and embedding models across providers, with USD pricing you can attribute per branch, Quanta Inference is the practical route: https://quantaintelligence.ai/inference.

Here is the rule. Apply it every time a branch crosses a threshold, and never let a reviewer apply it from memory.

Three details make the rule work. Splitting means freezing the current branch at its current state, merging or discarding the reviewable portion, and moving the unfinished work to a new branch with its own fresh cap; it does not mean raising the cap. Rejecting means the branch is closed rather than left open to burn reviewer attention; the agent's work is preserved as a draft for reference. Escalating is the only path to more money, and it requires a human who is willing to sign off on that branch's remaining spend in writing. That is the whole point: the cap is the default, and a human decision is the exception.

Thresholds should not be uniform across tiers, either. For critical-tier branches, drop the split trigger to 60 percent, because waiting until 80 percent on auth code means a reviewer has already spent more concentration than the branch deserves.

The 80 percent split trigger also has a review-quality justification independent of cost. Reviewer attention drops after roughly 60 to 90 minutes of continuous inspection, and defect discovery falls with it, which is the second finding behind the 400-line guideline above in the same study summary. Splitting at 80 percent of a cap derived from 34 median minutes keeps most reviews inside that window instead of pushing reviewers past their useful limit.

An agent opens a branch called agent/refactor-orders-api from a task assigned to the standard tier. The derived caps are 51 reviewer minutes and 270,000 review tokens.

Over the first two review passes, the automated reviewer runs three times and consumes 96,000 tokens, which is 36 percent of the token cap. The human reviewer logs 14 minutes, 27 percent of the minute cap. The first pass surfaces only trivial style comments, which is a signal in itself: the diff is large but the substance is thin.

The branch then changes materially. The agent pushes another eleven commits, the diff grows from 240 to 610 changed lines, and the next review pass consumes 88,000 tokens and 21 reviewer minutes. Cumulative spend is now 184,000 tokens, 68 percent of cap, and 35 minutes, 69 percent of cap. The branch has crossed the 60 percent flag threshold and is approaching the split trigger.

At this point the threshold logic fires. The branch is at 68 percent tokens and 69 percent minutes, still under the 80 percent split line, so review continues but the reviewer is told to stop reading the diff in full. Instead the reviewer checks whether the remaining work can be reviewed as a separate branch. It can: the 610-line diff contains one refactor that changes behavior (roughly 180 lines) and a larger pure-movement refactor (roughly 430 lines) that preserves behavior and is safe to review on its own.

That distinction is the insight most cost policies miss. Splitting is cheap when part of the diff is behavior-preserving, because that part can be verified with existing tests rather than line-by-line review. The behavior-changing portion goes forward; the movement portion is merged separately under a fresh, smaller cap. The reviewer's remaining 16 minutes are spent only on the lines that can change runtime behavior.

Now run the alternative. Suppose the reviewer had instead plowed through the full 610 lines. Based on the measured baseline of 34 median minutes per 260 lines, a 610-line branch is plausibly a two-and-a-half-hour review, well past the 51-minute cap. The second and third review passes would have pushed token spend past 270,000 before a merge decision, triggering a rejection of work that was mostly correct. The cap did not just save money; it pushed the reviewer toward splitting, which produced a better-shaped review.

A final variant: if the behavior-changing portion had been in the auth path rather than orders, the branch would have been high tier with double caps, and the 610-line diff at 69 percent of an unchanged cap would have been at only 35 percent of its allowance. Same diff, different tier, different decision. That is why the tier is set at branch creation, before anyone has seen the diff.

Caps that appear overnight get ignored within a week. Roll them out in three passes.

First, measure for two weeks with no enforcement: record minutes and tokens per branch, publish the distribution to the team, and let people argue with the numbers before the numbers become rules. Second, enforce only the split trigger at 80 percent, which nobody objects to once they have seen the numbers, while leaving rejection as advisory. Third, turn on rejection and escalation once the team has seen a handful of escalations resolved on the record and the process feels boring rather than punitive.

Keep one escape valve. A single rolling exemption, such as one uncapped branch per reviewer per week, absorbs the genuine edge cases without inviting abuse. The alternative is a policy so rigid that people quietly review branches in a different tool to avoid the meter, which defeats the whole exercise.

Finally, review the caps themselves quarterly against fresh data. If the median minute count is creeping up, agents are producing larger branches, and the fix is upstream in how tasks are assigned, not a bigger cap. The cap is an alarm, and an alarm that never fires is telling you something too.