Review tiers and credits

Every review runs at a tier. The tier decides how much work goes into the review, and how many credits it uses from your plan.

Tier	Credits	What it does
Standard	1	Reviews the change and the code around it, and investigates further when the change looks risky. Right for most pull requests.
Deep	3	Always explores the repository with tools, uses a stronger model, and double-checks every finding before posting it. Takes longer.
Max	10	Our strongest models and the longest investigation. Findings are checked on the same model, then a final pass looks for anything the first one missed. Slowest.
Auto	1–10	MergeHarbor picks Standard, Deep or Max for each pull request and says why. The review uses the credits of the tier it ran at.

Standard is included on every plan, Deep from Team and Max from Advanced. Auto picks only among the tiers your plan includes.

A higher tier investigates more; it does not comment more. Every tier posts against the same bar: notes about missing tests, naming, documentation or style are held back unless your review strictness is set to high, a small note about code that already has a serious finding goes into that finding instead of a second comment, and anything Max’s final pass adds is posted only when the check confirms it. Measured results per tier are on How MergeHarbor reviews.

Standard is the default, and it behaves the way reviews always have: one Standard review uses one credit, which is the same as one review under the old per-review allowance.

Choose a tier

• Organization: Settings → Review behaviour → Review tier.
• Repository: Repositories → a repository → Review settings for this repository → Review tier (turn on Override).
• Configuration file: tier: deep in .mergeharbor.yml, or in a folder’s .mergeharbor/config.yml to raise the tier for pull requests that change files under that folder. See Repository configuration.

The older depth setting still works. It now sets how far a Standard review looks beyond the diff (Light, Normal or Thorough) and never changes what a review costs.

How Auto chooses

Auto does not call a model to decide. It adds up points from signals it can read immediately:

• Size: more than 10 files or 300 changed lines adds a little; more than 30 files or 1,000 lines adds more.
• Risky areas: changes to authentication, payments and billing, secrets and cryptography, database migrations, or infrastructure and CI.
• Labels: a security label goes straight to Max; labels such as critical, hotfix or urgent add points.
• Target branch: a release branch adds a point. Release branches are the patterns set under change risk settings (by default release/*, release-*, releases/*, hotfix/*, production, prod and stable).
• History: serious findings MergeHarbor reported in the same files over the last 90 days.

Changes that only touch documentation or tests always run at Standard. The review summary and the pull request page in the console show the tier and the reasons, for example Auto chose Deep: touches database migrations.

Tier rules

Tier rules give matching pull requests a different tier. Each rule has a name, one or more conditions (all must hold) and a tier. Conditions can check the author, labels, target or source branch, changed paths, title, the number of files changed or the number of lines changed.

Examples:

• Target branch release/* → Max
• Label security → Max
• Files changed more than 30 → Deep
• Author renovate[bot] → Auto

Add rules in Settings → Review behaviour → Review tier, in a repository’s settings, or in the root .mergeharbor.yml:

review:
  tier: standard
  tier_rules:
    - name: Payments
      conditions:
        - { field: path, op: include, values: ["services/payments/**"] }
      tier: max
    - name: Large changes
      conditions:
        - { field: files_changed, op: gt, values: ["30"] }
      tier: deep

Rules from the organization, the repository and .mergeharbor.yml all apply. A repository’s rules add to the organization’s rules instead of replacing them.

Which tier wins

1. The configured tier, the tier from configuration files, and every matching rule are compared. The highest tier wins.
2. A configured Auto steps aside whenever another tier applies. The exception is a matching rule set to Auto: it swaps the configured tier for Auto’s choice, which then competes with the other matching rules.
3. If nothing applies, the review runs at Standard.
4. A tier requested in a comment raises the result for that review. It never lowers it.
5. Credit limits can lower the tier (see below). The summary says so when they do.

Ask for a deeper review

Comment on the pull request:

@mergeharbor review max
@mergeharbor review deep
@mergeharbor review this at max

The comment raises the tier for that one review only. If the pull request is already configured for a higher tier, MergeHarbor keeps the higher tier and explains why in the review summary. Asking for the same commit again at a higher tier uses only the difference: for example, a commit already reviewed at Standard costs 9 more credits at Max.

What uses credits

• A posted review uses its tier’s credits.
• A repeat review of a commit that was already reviewed at the same tier or higher uses no credits.
• Failed reviews, skipped reviews, reviews where only the free deterministic checks ran, and reviews answered entirely from results for identical files use no credits.
• Repositories on the open-source program are free and always run at Standard.

While a review runs, the status check shows the tier and the estimated credits. When the review is posted, a short line at the end of the summary shows the tier, the credits charged, and why that tier was chosen.

Keep credit use predictable

Billing admins set credit controls in Billing → Usage → Credits → Credit controls:

• Monthly credit limit, and what happens when it is reached: Alert only, Review at Standard only, or Pause reviews. Billing admins get an email at each alert threshold (80% and 100% by default).
• Per pull request cap: the most credits one pull request may use across all its reviews. When a review would go over the cap, it steps down to a tier that fits. When even Standard does not fit, reviews stop with a neutral status check that explains why.

The Credits tab shows credits per day by tier, and credits by tier, developer and repository. Each pull request in the console shows its tier and the credits it has used.

Progress reactions

While MergeHarbor works on a pull request it leaves a reaction on it: an eyes reaction when a review starts, thumbs up when it is posted, and a confused face if it fails. GitHub and GitLab support reactions; other code hosts show progress through the status check only. Turn reactions off in Settings → Review behaviour → Status checks → Progress reactions, or with reactions: { enabled: false } in .mergeharbor.yml.