A cost model for automated pull-request review, with practical controls for triggers, context, model routing, reruns, large diffs, and BYOK provider spend.
The cost of AI code review is easy to underestimate because the visible unit is a pull request while the underlying work may include several model calls. A specialist panel can analyze correctness, security, and architecture in parallel, then run an aggregation step. Each call may receive the patch, repository policy, and retrieved context. A force-push can repeat some of that work. The right cost question is therefore not simply how many pull requests you open, but what work each review performs.
Build a basic ledger before tuning. For every run, record the trigger, head SHA, changed files, diff size, selected reviewers, selected models, input and output usage where available, status, and whether the run superseded an earlier one. If the product uses credits or review runs instead of direct token billing, record those too. A unit you can inspect is a unit you can budget.
Trigger policy is the first cost control. Skip drafts until they become ready, debounce rapid synchronize events, and make repeated work idempotent for the same head commit. Allow path rules for generated files, vendored code, snapshots, and lockfiles. Teams with long-lived experimental branches may prefer a manual trigger. These controls reduce both model spend and low-value comments, so they rarely require a quality tradeoff.
Measure models on representative pull requests and role-specific output. A model that is excellent at broad explanation may not be the best structured finding generator. A lower-cost model that reliably returns schema-valid, evidence-backed results can own aggregation or simple checks. Reserve more expensive reasoning for changes where cross-file behavior or security analysis warrants it. The routing policy should be versioned so changes in spend or quality can be traced.
Context is another budget. Sending more files can improve a finding when those files define a changed interface or trust boundary. Sending unrelated directories generally adds tokens and distraction. Retrieve symbols, callers, tests, configuration, and repository instructions selectively. Summaries of stable project context can be cached, but invalidate them when the source or policy changes. Do not cache a review verdict across different diffs.
Large generated migrations, dependency lockfile changes, and repository-wide formatting can be orders of magnitude larger than routine work. Define what happens before one appears: skip excluded paths, split review by package, sample only when the limitation is explicit, or require a manual run. A silent truncated review is dangerous because it looks complete. A clearly labeled partial review preserves both cost control and maintainer understanding.
Provider spend is only part of total cost. Maintainer time spent rejecting weak comments can exceed the model bill. Track accepted and dismissed findings alongside run usage, then look for expensive reviewer roles or repositories that produce little action. Raise a confidence threshold, narrow the prompt, change a model, or disable a low-value role. The goal is not minimum tokens. It is a predictable review process where the combined model and human cost is justified by the problems found.
Review the budget on a regular cadence and after any model, prompt, or trigger change. Compare routine, large, and incremental runs separately; one average hides the pull requests most likely to surprise you. Share the unit and the controls with repository owners. Cost control works best as visible engineering policy, not as a hidden limit that suddenly prevents a review at the end of a billing period.
PR Quorum turns specialist reviewer output into one clean GitHub review, with noise controls and predictable usage caps.