Greptile Adds Plus and Apex Tiers for Deeper Code Review

Greptile now sells code review by depth, and the price tag scales with it. The Greptile Plus Apex tiers, announced on September 25, 2026, cost 3 and 10 credits per review, against 1 for the Base tier. If you run delivery for a team, you now have a new budget line and a new decision: which pull requests deserve the expensive reviewer?

What happened with Greptile Plus and Apex

Greptile's announcement describes three review tiers:

• Base (1 credit): a thorough review with full codebase context.
• Plus (3 credits): a deeper review for PRs that need extra scrutiny.
• Apex (10 credits): the most intensive review, aimed at large, complex PRs.

Per Greptile, the higher tiers give each review more time to run subagents and tasks in parallel, so it can understand the change better and catch more bugs.

The company's own benchmark counts correct P0/P1 findings (its most severe bug classes) per PR. For PRs touching 28 or more files, Base finds 1.23, Plus 1.67 and Apex 2.55. These are Greptile's numbers on its own benchmark, so treat them as a vendor claim, not an independent test.

Greptile also says all of its own large PRs now go through Apex before production.

What AI pull request review costs now

The billing docs set the base price at $30 per month per active developer, which includes 50 credits. Extra credits cost $1 each (called flex usage).

Do the arithmetic on one developer's included credits:

• 50 Base reviews, or
• about 16 Plus reviews, or
• 5 Apex reviews.

Overages are per author, not pooled across the team. One developer who ships big PRs can burn through their 50 credits while a colleague's allowance sits untouched. At flex rates, one Apex review is $10 and one Plus review is $3.

Set review depth by risk on Monday

Greptile lets you switch tiers and set rules that automatically use Plus or Apex for large PRs or changes to high-risk code, in the review settings at app.greptile.com/-/settings/review. I did not find a documented config-file syntax for this, so use the dashboard rather than guessing at keys.

A sensible starting policy, written as a team agreement:

Default:        Base   (docs, small fixes, config tweaks)
Auto-upgrade:   Plus   (PRs over your usual size, shared libraries)
Auto-upgrade:   Apex   (auth, payments, data migrations, infra, very large PRs)

The rule is yours to tune. The point is that depth follows blast radius, not whoever remembers to ask.

Watch Greptile credits per review

Two places in the dashboard matter:

• Settings, then Usage shows review counts and active developers.
• Organization Settings, then Billing, then Flex Usage Limit caps overage spend.

When projected spend reaches the cap, Greptile skips reviews that would need flex charges until the next period. Setting the limit to $0 disables flex entirely, though developers with included credits left still get reviews. Decide on purpose whether you want a skipped review or a surprise invoice.

A weekly five-minute check is enough: how many Apex runs happened, and did they land on PRs that deserved them?

Gotchas

• Auto-upgrade rules for large PRs can quietly turn a refactor week into a credit crater. Cap flex before you enable them.
• Per-author overages mean a small group of heavy committers drives the bill.
• An active developer is anyone with at least one completed review in the period, so seat counts can grow without anyone being added.
• A deeper review finds more, not everything. Keep human sign-off on the risky changes.
• The announcement does not state plan-level restrictions, so confirm your plan includes Plus and Apex before you promise them to the team.

When the deeper tiers are not worth it

If most of your PRs are small and low risk, Base already covers you, and Apex at 10 credits per review is spending for its own sake. Teams with few high-risk changes should reserve Apex for a short, named list of areas.

If you ship AI features to production, review depth is now a dial you can price: spend more where a missed bug is expensive, and cap it where it is not.