How to Set Greptile Tier Rules for Large or High-Risk PRs

Apex reviews cost 10 credits each, ten times a Base review, so pointing every pull request at Apex drains your credit balance fast. Greptile tier rules fix that by spending credits only where a missed bug is expensive. By the end you will have Auto as the default, Apex rules for production, large and high-risk PRs, one pinned directory, and a way to ask for a deeper review on a single PR.

What a Greptile review costs in credits

Greptile's review tiers are Base (1 credit, full codebase context), Plus (3 credits, extra scrutiny) and Apex (10 credits, the most intensive, built for large, complex PRs). Auto picks a tier per PR from its size, risk and complexity, and you pay for the tier that ran.

Greptile's launch post shows why to be picky. On PRs with 28 or more changed files, Apex found 2.55 correct P0/P1 issues per PR against 1.23 for Base. On PRs with 10 files or fewer, it was 0.67 against 0.42. Those are Greptile's own numbers, but the gap is widest on big PRs.

At 100 PRs a month, all Base is 100 credits and all Apex is 1,000. With 8 PRs on Apex and 92 on Base, you spend 172, before Auto escalates any of the rest.

Step 1: Set the default review tier to Auto

In the dashboard, open Settings → Code Review → Greptile Review Configuration and set the default tier to Auto. Most PRs then get Base, and only those that need it get Plus or Apex.

Don't set the default to Apex "to be safe": Step 7 shows why that locks every PR in.

Step 2: Add Greptile tier rules for production-branch PRs

On the same screen, add a filter rule and set its Review tier. The first rule covers PRs that merge into production:

| Filter | Condition | Value | Review tier | |---|---|---|---| | Target branch | includes | main (or production) | Apex |

A rule overrides Auto for the PRs it matches. Auto still handles everything else.

Step 3: Send large PRs to a Greptile Apex review

The second rule is about size:

| Filter | Condition | Value | Review tier | |---|---|---|---| | Files changed | More than | 30 | Apex |

Thirty files is Greptile's suggested starting point. Lower it if your PRs are usually small, raise it if Apex fires too often.

Step 4: Route high-risk changes by label or file path

A rule can filter on label, target branch, file path or files changed. Greptile's own example is a label rule:

| Filter | Condition | Value | Review tier | |---|---|---|---| | Label | includes | security | Apex |

Add one more rule with the File path condition for your riskiest code, such as auth, payments or database migrations, and check the pattern format in the dashboard.

Step 5: Pin a tier per directory with the Greptile effort config

The effort key in .greptile/config.json accepts base, plus, apex or auto. Unset means the dashboard setting applies. For a monorepo, put a config inside the directory that deserves more scrutiny, for example packages/db/.greptile/config.json:

{
  "effort": "apex"
}

Now any PR that touches packages/db gets at least Apex. A greptile.json with the same key also works and overrides the dashboard setting for that repository.

Step 6: Ask for a deeper review on one PR

Sometimes a small PR deserves a hard look. Comment on it:

@greptileai review this at apex

Variations such as @greptileai effort: plus work too, and the CLI takes --plus and --apex flags. A request can raise the tier for that review only. It cannot lower it.

Step 7: Check precedence when a PR gets an unexpected tier

Greptile uses the highest of: the dashboard setting, the repository config, any directory config the PR touches, a matching tier rule, and a request in the trigger comment. Nothing can lower a higher setting, and Auto counts as no tier, so any explicit tier beats it.

With the setup above:

• A 5-file PR into main that touches packages/db: Apex, 10 credits.
• A 3-file PR into a feature branch with no label and a @greptileai effort: plus comment: Plus, 3 credits.

Gotchas

• T-Rex is not compatible with Plus, Apex or Auto yet, and Greptile says support is coming soon. If you use T-Rex, don't switch tiers.
• config.json only carries effort. The tier rules in Steps 2 to 4 are dashboard settings.

For anyone shipping AI-assisted code to production, tier rules put the expensive review where the blast radius is large and keep the rest cheap.