Purchasing Guides / Pull Request Review

Pull Request Review

A purchasing guide to buying a workflow that reads each pull request with the surrounding code, checks it against your team's review rules and leaves specific comments before your reviewers look.

Yearly running cost

Assuming 4,800 pull requests a year

By hand: $90K / year; 1,200 hours of work
Subscription: $3.6K+ / year
This workflow: $634 / year; Machine usage only; setup, hosting and review are extra.

What should the review do?

Read each pull request with the code around it, check it against your team's review rules and leave specific comments before a person reviews it.

Review and commentRule-based comments on every pull request$1,080 – 3,120 setupAdd merge checks and ticketsA required check for serious rules, findings tracked$1,728 – 5,160 setup

Your reviewers approve and merge. It never approves, merges or pushes code.

What is included

Read the change and related code, check it against your review rules and post inline comments with severity and the rule used, plus a short summary.

Start with your written review rules, the repositories in scope and a set of past pull requests where reviewers found real problems. The merge-check option adds a required check for your most serious rules and links findings to your issue tracker.

How reliable should the review comments be?

More comments are not better. Choose how many comments must be worth acting on, how many known problems it should find and how reliably it flags your written rules.

StandardUseful comments on rule breaks and likely bugs, with uncertain points asked as questions.Comments accepted: ≥70%Known problems found: ≥60%IncludedStrictA second check on each comment and more tests on past pull requests.Comments accepted: ≥80%Known problems found: ≥70%Setup +$288 – 840My own targetsAgree your own acceptance requirements with the provider.Quote separately

How these standards are measured

Test on held-out past pull requests with known problems and on clean pull requests that should get few comments. Measure how many comments developers accept separately from how many known problems are found. A comment without a file, line and reason counts as a failure.

Targets for your selected standard
What is checked	Target
Comments acceptedComments that reviewers mark as valid and worth acting on, divided by all comments posted on the test pull requests.	≥70%
Known problems foundLabelled problems from past pull requests that receive a correct comment, divided by all labelled problems. Problems found only by a vague comment do not count.	≥60%
Rule breaks flaggedLabelled breaks of your written rules that are flagged with the right rule, divided by all labelled rule breaks.	≥95%
Comments with location and reasonEvery comment must give the file, line and the rule or reason behind it.	≥100%

Review comments are suggestions for a person to weigh, not a pass or fail on the code. Your reviewers still read the change and decide whether to merge.

How quickly should comments appear?

Choose how soon after a pull request is opened or updated the review comments appear. Human review time is separate.

Within 10 minutesIncludedWithin 5 minutesSetup +$144 – 480Within 2 minutesSetup +$288 – 840

Timing details

Time from the pull request event to posted comments, including fetching the change and related code, model calls, queueing and retries. Very large changes may need agreed limits. Confirm repository size and hardware with your provider.

The target applies to at least 95% of agreed test runs, with 4 in progress at a time.

How much do you want to spend per pull request?

Choose the machine budget for reading the change, the related code and your rules. Tighter budgets may read less surrounding code.

Up to $0.50IncludedUp to $0.25Setup +$72 – 360Up to $0.15Setup +$216 – 600

Cost details

Includes model calls, retries and a shared hosting allocation. Code host plans, CI minutes, your developers' time and the calling agent are separate. Each new push to a pull request is another run.

Reference machine cost: $0.18 – 0.28 per pull request at 400 pull requests a month. The selected cap is a target to test, not a replacement for this estimate.

Where do you want it to run?

Run it in your cloud or on your own server. Choose whether code changes may go to an approved AI service.

Run it onAI model access

Data and access details

Runs in a cloud account you control, with access controls and logs.

Only the change, the related code and your rules go to the selected external model, with secret files excluded. Agree access and retention first.

Give the review app read access to code and permission to comment only. Exclude secret files and vendored code from what the model reads. Private model only keeps source code on your hardware; the workflow still connects to your own code host.

How do you want to use it?

Use comments in your pull requests, your current AI agent or a review dashboard. You can choose more than one.

Comments in my pull requestsReview comments and a short summary appear on each pull request in your code host.IncludedMy existing AI agentLet your coding agent request a review before opening a pull request and read the findings.Setup +$72 – 240A review dashboardSee findings across repositories, which comments developers accepted and which rules fire most.Setup +$144 – 480

Anything else your provider should know?

Optional. Your choices are included automatically.

Pull requests per monthYour setup budget (USD)

Your repositories, languages or review rules

Common questions

Do I need this if a hosted AI review tool already works for us?

Not necessarily. If a hosted review service is allowed to read your code and follows your rules well enough, subscribe to it. Buy a workflow when code must stay in your environment, you need a private model or your rules need checks a service does not offer.

Will it replace human code review?

No. It leaves comments before a person reviews. Your reviewers still read the change, weigh the comments and approve the merge.

How do we stop it from leaving noisy comments?

Set an accepted-comment target, tell it to ask instead of guess when unsure, and review which rules produce dismissed comments. Rules that a linter can check should move to the linter.

Can I run it without sending code to an external AI service?

Yes. Choose a private model and supply your own hardware. Measure comment quality and running cost during the pilot.