Review costs

What a review cost

On a pull request, the Review history table lists every review run with:

• when it ran, its status and the commit it reviewed;
• how long the first comment took and how long the review took;
• its tier (Standard, Deep or Max), the credits it used and what it cost (the cost counts toward your monthly budget);
• how many findings it posted and how many it held back;
• one plain line on why it ran at that tier, for example “Standard review: medium risk, touches payments/refund.go (a critical path).” or “Deep review, set by the organization rule “release branches”.”.

If a credit limit lowered a review’s tier, the line says so and what to do. A review is priced when it finishes, and keeps that price even if a model’s price changes later. For totals and trends, see Cost per review below.

Choose model classes

Under Settings → Review behaviour → AI models & cost you choose how MergeHarbor trades cost for quality. You choose classes of model, never individual models: MergeHarbor picks the model inside each class and keeps it current.

Class	Typically used for
Fast model	Risk checks, summaries and finding checks on routine changes
Efficient model	Routine reviews and finding checks
Strong model	Most reviews
Stronger model	High-risk changes and second looks
Strongest model	Critical changes

• Cost mode. Economy, Balanced or Max quality, each quoted at its cost for a typical review.
• Classes each stage may use. For each stage (risk check, review, finding checks, combining parts, file summaries, rule suggestions), clear the classes it must not use. Each stage keeps at least one class that is available with your providers and region; a stage limited to one class always uses it.
• Cost per class. The page shows what a typical review (8 files, 300 changed lines) costs with the review on each class, in one model call and when the model investigates with tools, before your cost caps.
• Quality floor. High- and critical-risk changes are never reviewed below this class.
• Strongest model for critical PRs. Critical-risk changes are reviewed by the strongest class reviews may use. This costs more on those pull requests; the critical-risk cost cap still applies.
• Cost caps. A per-review cap, and a separate cap for critical-risk changes.
• Residency and providers. Keep processing in the US or the EU, and allow only the providers you approve (see the subprocessors page). A class with no model in your region or from your providers is marked unavailable and is never used.
• Simulate a review. See the risk, the class each stage would use and the estimated cost for a sample pull request before you save.

The same settings are available through the API (GET and PUT /api/v1/orgs/{org}/routing, GET /api/v1/orgs/{org}/routing/classes, POST /api/v1/orgs/{org}/routing/simulate). The API takes model classes; a request that names a model is rejected.

When a model provider is down

If the provider a review step was routed to has an outage, MergeHarbor moves that step to another provider your routing settings allow, at the same model tier or one above, so the review still finishes. It never moves to a provider your organization has not allowed, and data-residency settings still apply. When this happens:

• the review summary on the pull request says so, for example “Reviewed with OpenAI because Anthropic was unavailable”;
• the run’s line in the review history says which provider stood in.

After repeated outages MergeHarbor stops trying the unavailable provider for a short time and goes straight to the fallback, then tries it again.

Cost per review over time

Billing → Usage → Cost per review shows, for the period you pick:

• the typical (median) cost of a review, and what 9 in 10 and 99 in 100 reviews cost less than;
• the median and 90th percentile by day;
• what was spent on reviews and on all work, and the cost of each kind of work (reviews, file summaries, rule suggestions, chat answers, tasks).

These amounts count toward your monthly budget.

Viewing costs requires the usage.read permission.

How costs are kept low

• Prompt caching. Each request starts with the parts that rarely change (instructions, your rules and knowledge base) and ends with the parts that do (the diff). Providers reuse the stable start across pull requests and re-reviews of a repository at a fraction of the input price.
• Less context. Generated, minified, vendored and lock files, and whitespace-only edits, are left out of the prompt. Code context is sent once, and the most useful context is kept when space is tight.
• The right model for each step. A small model checks risk and verifies findings; a stronger model is used only for risky changes and findings the small model could not settle. Pull requests that change only documentation or configuration skip the model and get an automatic summary.
• Batch processing. Work that can wait, such as file summaries for search and nightly rule suggestions, runs through the providers’ batch APIs at about half the price.
• Budgets. A monthly budget and per-review limits stop spend before it surprises you (Billing → Usage).