--- title: "Greptile Base vs Plus vs Apex: A PR Review Budget" canonical: https://wavect.io/blog/greptile-base-plus-apex-review-budget/ language: en description: "Choose Greptile review depth by change risk. Compare credits, monorepo rules and a pilot that measures verified findings and human triage time." image: "https://wavect.io/img/blog/headers/header_greptile-base-plus-apex-review-budget.png" --- [**Back**](/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/team/kevin-riedl/) [Kevin Riedl](/team/kevin-riedl/) https://linkedin.com/in/wsdt 4 min read · 8 October 2026 Last reviewed October 8, 2026 [**Next**](/blog/graphify-review-codebase-knowledge-graph/) # Greptile Base vs Plus vs Apex: A PR Review Budget TL;DR Use Base for bounded changes, pilot Plus for cross-module behavior, and consider Apex for high-impact changes. Budget completed reviews, including reruns. Greptile's credit prices do not establish which tier catches enough additional defects on your codebase. **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](https://www.greptile.com/blog/introducing-plus-and-apex) 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](https://www.greptile.com/pricing) 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](https://www.greptile.com/docs/code-review/review-tiers) 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](https://www.greptile.com/docs/code-review-bot/billing-seats) 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. 1. Label findings blind to tier, then reproduce each reported defect. 2. Count distinct actionable defects, missed known defects and false positives. Several comments about one issue are one finding. 3. Record elapsed review time, charged credits and human triage minutes. 4. Repeat a subset to expose run-to-run variation. Report sample size and exclusions. 5. 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](/contact/) if the unresolved work is evaluating your codebase rather than choosing a subscription label. [Download the proposed pilot protocol (JSON). It contains acceptance cases and empty result fields, not measured vendor results.](/downloads/greptile-base-plus-apex-review-budget-pilot.json) ## Related implementation guidance [Graphify Review 2026: Is a Codebase Knowledge Graph Worth It?](/blog/graphify-review-codebase-knowledge-graph/). [Canary AI QA: Test Defect Detection, Not Benchmark Scores](/blog/canary-ai-qa-defect-detection/). ## Sources checked - [Greptile: Plus & Apex](https://www.greptile.com/blog/introducing-plus-and-apex) - [Greptile Pro](https://www.greptile.com/pricing) - [Greptile: Base, Plus, Apex & Auto](https://www.greptile.com/docs/code-review/review-tiers) - [Greptile: Billing & Seats](https://www.greptile.com/docs/code-review-bot/billing-seats) **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: [office@wavect.io](mailto:office@wavect.io) QA and production readiness ## Continue through this cluster Testing, audits, maintenance and hardening practices for reliable production software. [Start with the cornerstone**QA for AI-Generated Code**](/blog/qa-for-ai-generated-code/) - [Arga Labs vs Archal: Stateful Agent Integration Tests](/blog/arga-vs-archal-agent-integration-testing/) - [Canary AI QA: Test Defect Detection, Not Benchmark Scores](/blog/canary-ai-qa-defect-detection/) - [Cua for Desktop QA: A Browser-to-Native Test Protocol](/blog/cua-desktop-qa-browser-native-workflow/) - [Browser Use vs Playwright: Verify Authenticated Actions After Timeouts](/blog/browser-use-vs-playwright-authenticated-workflow/) - [ChatGPT Dots + GitHub: From Bug Report to Reviewed PR](/blog/chatgpt-dots-github-bug-triage/) [**Back**](/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/team/kevin-riedl/) [Kevin Riedl](/team/kevin-riedl/) https://linkedin.com/in/wsdt 4 min read · 8 October 2026 Last reviewed October 8, 2026 [**Next**](/blog/graphify-review-codebase-knowledge-graph/) ## Structured Data ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ], "employee": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "founder": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "legalRepresentative": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "name": "Wavect GmbH", "subjectOf": { "@id": "https://wavect.io/verified-claims.json#dataset", "@type": "Dataset", "creator": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.", "inLanguage": "en", "isAccessibleForFree": true, "license": "https://creativecommons.org/licenses/by/4.0/", "name": "Wavect verified publication claims", "url": "https://wavect.io/verified-claims.json" }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/#website", "@type": "WebSite", "inLanguage": [ "en", "de", "es", "zh" ], "name": "Wavect", "potentialAction": { "@type": "SearchAction", "query-input": "required name=search_term_string", "target": { "@type": "EntryPoint", "urlTemplate": "https://wavect.io/search/?q={search_term_string}" } }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/blog/greptile-base-plus-apex-review-budget/#webpage", "@type": "WebPage", "dateModified": "2026-10-08", "inLanguage": "en", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "lastReviewed": "2026-10-08", "url": "https://wavect.io/blog/greptile-base-plus-apex-review-budget/" } ] } ``` ```json { "@context": "https://schema.org", "@type": "BlogPosting", "abstract": "Use Base for bounded changes, pilot Plus for cross-module behavior, and consider Apex for high-impact changes. Budget completed reviews, including reruns. Greptile's credit prices do not establish which tier catches enough additional defects on your codebase.", "articleBody": " Blog overview/Delivery and QA/QA and production readiness Greptile Base vs Plus vs Apex: A PR Review Budget TL;DR Use Base for bounded changes, pilot Plus for cross-module behavior, and consider Apex for high-impact changes. Budget completed reviews, including reruns. Greptile's credit prices do not establish which tier catches enough additional defects on your codebase. 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. TierCredits per reviewProposed pilot allocation Base1Bounded changes with straightforward acceptance testsPlus3Cross-module behavior or uncertain call sitesApex10High-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", "articleSection": "Engineering", "author": { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/" }, "citation": [ { "@type": "WebPage", "name": "25 September 2026 launch announcement", "url": "https://www.greptile.com/blog/introducing-plus-and-apex" }, { "@type": "WebPage", "name": "current Greptile pricing page", "url": "https://www.greptile.com/pricing" }, { "@type": "WebPage", "name": "review-tier configuration documentation", "url": "https://www.greptile.com/docs/code-review/review-tiers" }, { "@type": "WebPage", "name": "seat billing reference", "url": "https://www.greptile.com/docs/code-review-bot/billing-seats" } ], "dateModified": "2026-10-08", "datePublished": "2026-10-08", "description": "Use Base for bounded changes, pilot Plus for cross-module behavior, and consider Apex for high-impact changes. Budget completed reviews, including reruns. Greptile's credit prices do not establish which tier catches enough additional defects on your codebase.", "headline": "Greptile Base vs Plus vs Apex: A PR Review Budget", "image": "https://wavect.io/img/blog/headers/header_greptile-base-plus-apex-review-budget.svg", "inLanguage": "en", "keywords": "Engineering, AI agents", "mainEntityOfPage": { "@id": "https://wavect.io/blog/greptile-base-plus-apex-review-budget/", "@type": "WebPage" }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/blog/greptile-base-plus-apex-review-budget/", "wordCount": 1200 } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://wavect.io/", "name": "Home", "position": 1 }, { "@type": "ListItem", "item": "https://wavect.io/blog/overview/", "name": "Blog overview", "position": 2 }, { "@type": "ListItem", "item": "https://wavect.io/blog/topics/delivery-qa/", "name": "Delivery and QA", "position": 3 }, { "@type": "ListItem", "item": "https://wavect.io/blog/clusters/qa-production/", "name": "QA and production readiness", "position": 4 }, { "@type": "ListItem", "item": "https://wavect.io/blog/greptile-base-plus-apex-review-budget/", "name": "Greptile Base vs Plus vs Apex: A PR Review Budget", "position": 5 } ] } ```