In this piece
Greptile Base vs Plus vs Apex: A PR Review Budget
Evidence: Documentation reviewed on 8 October 2026. This is a researched implementation guide. The pilot below is proposed; we have not run these vendor evaluations or measured their performance.
Which Greptile tier should a team use?
Start with the consequences of a missed defect. A small authorization change can deserve more scrutiny than a large mechanical refactor. Our proposed rule is Base for bounded changes, Plus when correctness crosses module boundaries, and Apex when a missed issue could affect access, money, migrations or recovery. Validate this rule on your own pull requests before making it automatic.
Greptile's 25 September 2026 launch announcement introduced Plus and Apex alongside Base. Its example demonstrates findings at different depths on one Celestia change. That is vendor evidence of a useful capability, not an independent estimate of your team's defect recall.
What do Base, Plus and Apex cost?
The current Greptile pricing page lists Pro at USD 30 per seat per month, with 50 credits per seat and USD 1 for extra credits. Credits are consumed by reviews, so a PR with several review runs needs several entries in the budget.
| Tier | Credits per review | Proposed pilot allocation |
|---|---|---|
| Base | 1 | Bounded changes with straightforward acceptance tests |
| Plus | 3 | Cross-module behavior or uncertain call sites |
| Apex | 10 | High-impact changes needing deeper independent scrutiny |
Illustrative single-seat arithmetic: 30 Base, five Plus and two Apex reviews consume 65 credits. Against 50 included credits, the modeled bill is USD 30 + USD 15 = USD 45, before taxes or contractual adjustments. Reviewing all 37 changes at Apex would consume 370 credits and model USD 350. These are budgets, not observed charges or equal-quality alternatives.
How do monorepo settings change the budget?
The review-tier configuration documentation includes Auto, which charges the selected tier, and per-directory effort settings. A PR touching directories with different tiers uses the highest tier. The CLI runs Base without an effort flag, independently of the configured tier. T-Rex is currently incompatible with Plus, Apex and Auto.
Put these details into the evaluation manifest. Record the tier shown on each completed review, changed directories and trigger. Otherwise a comparison labeled “Base versus Apex” may actually compare different routing configurations. Do not assume a UI setting also governs a CLI pilot.
Greptile's seat billing reference assigns credits per PR author, not a pooled team balance. Completed reviews and reruns count against that author even when someone else triggers them. Model each seat separately before totaling a team bill.
How can you test whether Apex is worth it?
Use a permission-cleared sample covering ordinary changes, cross-module changes and high-impact changes. Include clean PRs and PRs with independently confirmed defects. Fix the commit, repository context and review instructions; run each tier on the same starting point. Keep the known-defect answers out of the reviewer prompt.
- Label findings blind to tier, then reproduce each reported defect.
- Count distinct actionable defects, missed known defects and false positives. Several comments about one issue are one finding.
- Record elapsed review time, charged credits and human triage minutes.
- Repeat a subset to expose run-to-run variation. Report sample size and exclusions.
- Compare additional confirmed findings with additional cost and triage time within each risk group.
Avoid calling a fixed historical sample “recall on all bugs.” You only know the defects independently established in that sample. Findings without a reproduction remain unconfirmed, even when their language is persuasive.
What should the team still review manually?
Keep business invariants, migration recovery and permission boundaries in human review and executable tests. A deeper reviewer can surface a dependency path; it cannot decide whether your refund policy or tenant contract is correct. A clean review should not silently become a production release approval.
Track review cost per accepted PR separately from the cost per confirmed additional defect. The first measures operating cost; the second helps decide where escalation earns its budget. If Apex produces more comments but no additional verified findings in a group, keep investigating before expanding its use.
Does a high file count automatically justify Apex?
No. Greptile recommends Apex for production-targeted and large PRs, but file count is only a proxy for risk. A generated rename and a three-line ownership check have different failure consequences. Use path and risk rules together, then revisit them when the pilot reveals which changes benefit.
When should you adopt the deeper tiers?
Adopt them where additional confirmed findings justify credits and review delay. Keep cheaper paths where the same acceptance evidence is sufficient. Bring your review sample, defect labels and escalation rules to discuss a review-process pilot if the unresolved work is evaluating your codebase rather than choosing a subscription label.
Related implementation guidance
Graphify Review 2026: Is a Codebase Knowledge Graph Worth It?. Canary AI QA: Test Defect Detection, Not Benchmark Scores.
Sources checked
Independence and trademarks: Wavect publishes this page and is itself a provider, so we have a commercial interest in it. We are not affiliated with, endorsed by or partnered with the other companies named here, and all third-party company names, brands and trademarks are the property of their respective owners. Statements about other providers are taken from publicly available sources, primarily their own published pages, as of the review date shown on this page, and may have changed since. Please verify them directly before you decide. This page was written to the best of our knowledge and with the intent to remain objective. If you believe anything here is inaccurate or unfair, write to us and we will correct it: [email protected]