Complete Greptile Review (2026)

Greptile is an AI code-review product built around a different promise from a diff-only pass: it says it builds a graph of the selected repository so a pull-request comment can account for files, functions, and dependencies outside the changed lines. That promise is attractive when a small edit can affect an unshown caller, a shared contract, or a service boundary.

The graph promise needs a practical repository test. Context can make a review more relevant, yet a team still has to check whether a finding reaches a failing path and whether the product fits its provider, security, and budget requirements. This page uses Greptile's public documentation and pricing pages.

It does not claim personal daily use of Greptile.

Greptile at a Glance

checked August 8, 2026: Greptile's pricing page and public documentation describe the product below. Plans and provider coverage move, so treat this table as a dated snapshot.

Area	Current Position	Buyer Check
Review method	Repository graph plus diff	Cross-file findings
Providers	GitHub and GitLab apps	Your exact provider
Free entry	Starter, one developer	Active-developer limit
Paid price	US$30 per seat monthly	Seats each billing period
Usage meter	Credits per review	Trex review volume
Enterprise	Self-hosting and compliance	Contract details

Greptile's Codebase Context

Greptile says a connected GitHub or GitLab repository is indexed into a graph of files, functions, and dependencies. On a pull request, the product uses that graph to review the change with repository context and posts comments with suggested fixes. Its overview says typical findings arrive in about three minutes.

These product behavior details were checked on July 28, 2026.

The important evaluation case is a change with an indirect consumer. Imagine a handler changes the shape of a result, while a background job and a client library consume that result elsewhere. A diff-only reviewer may only see the handler.

A codebase-aware reviewer has the opportunity to trace the dependency. Whether it does so accurately is what your pilot should test.

Greptile also says reactions and replies teach it what a team cares about, with less unwanted feedback after two to three weeks. That is a vendor product claim, so validate the behavior on your own repository. These current learning-loop details were checked on July 28, 2026.

Give the Graph a Contract Break

Use the hub's shared pilot on one repository, then add a test that isolates Greptile's claimed advantage. Choose a pull request where a changed type, schema, or authorization helper has a known consumer outside the diff.

1. Name the changed symbol and the dependent path before the review runs.
2. Keep the known contract failure hidden from the review prompt.
3. Check whether Greptile identifies the dependent and explains the broken behavior.
4. Repeat with a compatible change that should produce no finding.
5. Record graph-specific catches separately from ordinary diff comments.

This paired test gives the graph claim a fair chance while exposing false confidence. Keep human review in place and require the comment to name the caller, contract, or state transition that connects the changed code to the effect.

Ask the security questions before connecting a repository. Enterprise buyers should request the deployment and contractual details that match their own requirements. Greptile's public pricing page lists self-hosting, SSO/SAML, custom terms, and GitHub Enterprise support under Enterprise, but availability belongs in a current vendor conversation.

These current enterprise-plan details were checked on July 28, 2026.

Train the Review Feedback Loop

Every automated reviewer needs a consistent feedback convention. For a Greptile comment, establish whether the behavior is reachable, add a test or inspection note that explains the decision, and react consistently. A confirmed defect gets fixed with reproducible evidence.

A false positive gets a concise, evidence-backed dismissal. A useful but deferred idea receives an owner instead of lingering as an unresolved review thread.

Greptile's documentation describes thumbs-up and thumbs-down reactions plus replies as inputs to its learning loop. That creates a reason to avoid casual reactions. If different reviewers signal different priorities, the tool may learn conflicting preferences.

Agree on a small taxonomy first: correctness, security, contract compatibility, test coverage, or out of scope.

Comment Result	Reviewer Action	Evidence
Confirmed defect	Fix and react	Failing path or test
False positive	Dismiss and explain	Guard or contract
Deferred concern	Create owned work	Scope decision

That record also makes renewal easier to judge. A team can see whether review comments are concentrating on high-value defects or merely producing a longer conversation. The vendor may improve its models or review engine, yet the buying decision should rest on your repository's confirmed findings and review cost.

Validate Cross-File Findings

A cross-file finding should be easier to prove than a broad review opinion. Ask Greptile's comment to point to the changed symbol, the dependent consumer, and the behavior that connects them. Then follow that named path through the repository.

If the comment cannot identify the caller, contract, or state transition involved, treat it as a question for a reviewer. It is not yet a defect ready for repair.

Use a small change set for the first tests. A renamed field that is consumed by a serializer, a changed error type handled in another package, or an authorization helper used by several routes can all show whether the repository graph adds useful context.

Include the existing relevant tests in the inspection. A true cross-file issue should either change a test result or expose why no test covers the affected contract.

• Trace the comment from the edited line to every named dependent.
• Check whether a type, validator, or adapter preserves compatibility.
• Confirm the affected consumer can receive the changed value at runtime.
• Add a regression test that crosses the same boundary.

Greptile's graph is context for a review, not a substitute for runtime evidence. This evaluation method gives the product a fair chance to demonstrate its specialism while holding it to the same standard as any reviewer: the concern must map to a reachable behavior with a clear consequence.

Use Configuration for Local Context

Greptile made the directory-scoped .greptile/ folder its recommended configuration format on May 12, 2026. Place the folder at the repository root or inside a directory. Settings cascade from root to leaf, while rules and file references accumulate across the matching folders.

The recommended folder supports three optional configuration files. config.json holds documented review settings and structured rules. rules.md holds plain-language instructions scoped to that directory.

files.json points Greptile at existing schemas, API specifications, or architecture documents.

.greptile/
├── config.json
├── rules.md
└── files.json

// .greptile/config.json
{
  "strictness": 2,
  "rules": [
    {
      "id": "tenant-writes",
      "rule": "Trace authenticated tenant ownership to every data write.",
      "severity": "high"
    }
  ]
}

// .greptile/rules.md
## Contract changes

Flag a changed public response shape when no contract test covers it.

// .greptile/files.json
{
  "files": [
    {
      "path": "docs/architecture.md",
      "description": "Service boundaries and ownership"
    }
  ]
}

A nested folder can override scalar settings, disable an inherited structured rule by its ID, and add local rules or context files. Keep the current .greptile/ reference open while editing these files. Greptile still supports greptile.json for backward compatibility, but .greptile/ takes precedence when both exist in one directory.

Local configuration is useful when the repository has meaningful boundaries. An API directory can ask for authorization tracing, while a payment module can ask for idempotency and error-path review. Give every rule an observable behavior and keep broad handbook material out of the review prompt.

Test the cascade before applying it to every package. Put one harmless scalar setting at the root, add a different value under a nested service, and review a change inside that service. The resulting behavior should show which directory supplied the effective setting.

1. Confirm root rules still apply to a nested path unless explicitly disabled.
2. Give every structured rule a stable ID before testing an override.
3. Change one scalar at a time so a surprising result has one likely cause.
4. Repeat the same review in a sibling path that should inherit only root context.

Treat files.json as a deliberately curated context list. A current schema or architecture decision can help Greptile explain a contract break, while an obsolete document can make a polished comment wrong. Name why each file matters and remove references when the owning document moves.

The older greptile.json format can remain during a staged migration, but it must not become a second source of truth. Add the matching .greptile/ folder, verify its precedence on a representative pull request, then schedule removal of the legacy file after the new behavior is confirmed.

Directory scope is the configuration's practical differentiator here. It lets a monorepo give one service its contracts without filling every review with unrelated context from another package. That benefit disappears when teams copy the same broad rules into every folder.

Match the Review Design to the Repository

Greptile's repository graph is likely to matter most where relationships are hard to see from a diff: shared libraries, service boundaries, event consumers, and long-lived contracts.

A compact repository with a clear test suite may still benefit from a second reviewer, but it gives the graph less hidden territory to uncover. Put the product in front of the changes where its claimed context has a chance to change the review outcome.

Build the evaluation around those cross-file repository relationships. Choose a pull request that changes an interface consumed elsewhere, then ask reviewers to compare the automated finding with the manual review notes.

If the same dependency is already visible through types, integration tests, and a careful reviewer, the tool may be redundant. If a downstream consumer was missed until the graph surfaced it, record the evidence and repeat the test on a different boundary.

This avoids a false comparison between an impressive demo and a team workflow. Adoption should follow a pattern of confirmed help on the repository's difficult code paths. Where the product adds no distinct signal, keeping the existing checks is a sensible result.

Keep the trial long enough to include several authors and change types. One reviewer may have unusually complete context in their head, while another depends on the repository's contracts being visible. The product should improve review for the team, not only for a single demonstration pull request.

Capture both successes and misses in the pilot record. A missed cross-file issue tells the team which relationship needs stronger tests or clearer configuration, even if Greptile is not retained. The trial should leave the repository's review practice better specified, measurable, and easier to maintain than it was at the start.

Hand Findings to a Coding Agent Carefully

Greptile's April 2026 changelog says each review comment can use Fix in your IDE to send the file, line numbers, review comment, and suggested fix to Claude Code, OpenAI Codex, Conductor, Cursor, or Devin. It also documents a separate Fix All action. These current handoff details were checked on July 28, 2026.

An agent handoff is a convenience for a confirmed finding, not proof that the proposed patch is correct. Read the complete review finding before assigning the repair. Inspect the generated diff against the confirmed failure path.

Run the relevant test suite and project checks. Then request a fresh review only if the repair changed the path that prompted the comment. This sequence keeps the human reviewer responsible for the code that merges.

The feature is especially useful when a review comment contains enough context to reproduce the concern but the reviewer does not have the source open locally.

It is less useful for a vague suggestion, a disputed architectural preference, or a finding whose underlying premise has not been verified. In those cases, investigation should happen before a coding agent receives a task.

Greptile Pricing and Credits

Greptile's pricing page lists a free Starter plan for one active developer with 50 monthly credits, and a Pro plan at US$30 per seat per month with 50 credits per seat.

The page says one standard review uses one credit, a Trex review uses three credits, and extra credits cost US$1. These prices were most recently checked on July 28, 2026.

Greptile's published plans, re-checked August 8, 2026. Confirm before any purchase.

Plan	Price	Included Credits
Starter	Free, one active developer	50 each month
Pro	US$30 per seat monthly	50 per seat
Extra credits	US$1 each	Bought as needed
Enterprise	Custom pricing	Negotiated

The same page lists a 14-day trial for Pro, unlimited repositories, custom rules, and external-app connections. It presents Enterprise as custom pricing with self-hosting and compliance options. Prices, credit rules, discounts, and plan features are volatile, so confirm them on the official page before a purchase or a budget approval.

Greptile's changelog says a free individual Starter tier launched June 29, 2026. The pricing page also says qualified non-commercial MIT or Apache open-source projects can apply for free service and eligible early-stage startups can apply for a discount. These offers were most recently checked on July 28, 2026.

Questions to Settle Before Adoption

Settle the provider, deployment, and data questions first. Greptile documents both GitHub and GitLab app installation. Its enterprise material describes self-hosting, and the public pricing page names GitHub Enterprise support.

That is enough to start a vendor conversation, not enough to assume compatibility with every source-control or compliance environment.

Settle the graph's review-quality question after provider fit. Does the graph context catch issues that your existing tests, static checks, and human review miss? Count only findings confirmed against repository evidence your team can inspect.

Treat an impressive explanation without a reachable defect as a false positive. This guardrail protects the team from adopting a tool because its review prose sounds informed.

Finally, settle the cost question from your own pull-request volume. Credits make a review run legible, yet the full cost includes reviewer attention, follow-up patches, and re-runs. The CodeRabbit guide and BugBot guide show other review workflows to test against the same rubric.

The Case for a Greptile Trial

Greptile should win or lose on cross-file evidence. Give it contract breaks that ordinary diff review misses, require every comment to identify the dependent path, and use .greptile/ to supply only the context needed for that proof. A team with mostly compact, well-tested repositories may gain little from the graph and should save the extra review lane.

Greptile FAQ

Does Greptile read the whole codebase?

Greptile says it builds a graph of the selected repository, including files, functions, and dependencies, then uses that context for pull-request review. Confirm the current data, retention, and deployment terms with Greptile before connecting a sensitive repository.

Which providers does Greptile support?

Greptile's documentation describes installing its GitHub or GitLab app and selecting repositories. Its current enterprise pricing page also lists GitHub Enterprise support. Confirm your provider and deployment requirements with the vendor before a rollout.

Can Greptile send a fix to Codex?

Yes, Greptile documents a Fix in your IDE action that can send a review finding, file paths, line numbers, and a suggested fix to Codex and several other coding agents. Inspect the resulting change and run your normal tests before merge.

Is Greptile free for open source?

Greptile's pricing page says qualified non-commercial projects with MIT or Apache licences can apply for free service. It also lists a free Starter plan for one active developer. Check the current eligibility terms before relying on either offer.

Keep Reading

• AI code review hub
• CodeRabbit guide
• BugBot guide
• Greptile vs GitHub Copilot