PR Lens vs Greptile

Greptile and PR Lens start from the same unusual decision and end up in completely different places. Both index the whole repository instead of reading the diff on its own. Greptile spends that index on finding defects; its docs say it builds a graph of your entire repository to understand how changes affect the whole system, then posts findings in about three minutes as pull request comments with suggested fixes. PR Lens spends the same index on drawing the change against the system around it. As of September 2026 Greptile's pricing page lists Pro at $30 per seat per month with 50 credits included and $1 per credit after that, where one credit is one standard review.

If you are shopping for a bug finder, buy a bug finder. This post is about why the two tools are not substitutes even though the marketing pages look similar.

What Greptile does well

Whole-repository context is the thing, and Greptile was early to it. A reviewer that only sees the diff can tell you that this function has no null check. A reviewer that has read the rest of the codebase can tell you that a function doing exactly this already exists three directories over, which is a class of finding that matters a lot on agent-written code. The January 2026 study GitHub cited, "More Code, Less Reuse", found that agent code carries more redundancy and technical debt per change while reviewers feel better about approving it. Duplicate-utility findings are aimed squarely at that.

Greptile's docs also describe a learning system: after two or three weeks of feedback it stops commenting on the things your team does not care about. Anyone who has muted a linter knows why that feature exists.

As of September 2026 its pricing is a free Starter plan with 50 credits a month for one active developer, Pro at $30 per seat per month with 50 credits per seat and $1 per additional credit, and custom Enterprise pricing. A deeper "trex" review costs three credits. Qualified non-commercial projects under MIT or Apache licences are free, which is a decent offer for maintainers.

One thing to model before you commit: on a repository where coding agents open pull requests and push to them several times a day, review count is not the same as pull request count. Work out your monthly reviews, not your monthly PRs.

What whole-repository context buys a diagram

Greptile reads the whole codebase to find what is wrong. PR Lens reads it to draw what is there.

Concretely, whole-repository context is what lets PR Lens leave the untouched parts of the system on the page. A change touches five components; the diagram shows those five in colour and the twelve around them in grey, with the calls between them. Green is new, amber is changed, red is gone, and removed components are struck through. Without an index of the repository you can only draw what the diff mentions, and a diagram of only what the diff mentions is a prettier diff.

That is also what makes the render at the top of this page possible: six lanes, thirty-seven components, one monorepo-wide refactor. The hosted App keeps a baseline of the repository and tracks it across commits, so each pull request is drawn against the system rather than against itself.

The second thing the index buys is drill-down. The comment nests details sections, each with its own diagram scoped to one part of the change: the whole blast radius on top, then the new path on its own, then what was retired.

I wrote up what "blast radius" means and why the untouched neighbours are load-bearing in Blast radius diagrams.

When each tool is useful

They are used at different points, which is the practical reason to run both.

Greptile is useful after you have decided the change is roughly right and you want to know whether it is correct. Its findings are anchored to lines, ranked, and actionable. You read them, you accept or dismiss each one, and you move on.

PR Lens is useful before that, in the thirty seconds where you have opened the pull request and not yet decided how much attention it deserves. LinearB's 2026 benchmarks, across 8.1 million pull requests from more than 4,800 organisations, found AI-generated pull requests waiting 4.6 times longer for a reviewer to pick them up, over 16 hours against about 200 minutes, and then finishing faster than human pull requests once review starts. The cost is in the picking up. Something that answers "what is this" in one glance is aimed at exactly that gap.

There is a compound effect when both are running. A Greptile finding on a line inside a newly created worker that sits on the only path between a queue and an external email provider is a different priority from the same finding in a test fixture, and the diagram is what tells you which one you are looking at. This is most obvious in a codebase you do not know well, which I wrote about in How to review a pull request you didn't write.

Where the mechanics differ

Greptile's output is text produced by a model. PR Lens splits that in two so the model never draws anything. It writes a strongly typed JSON graph document with lenses, lanes and nodes, each node carrying an id, label, kind, delta and lane. A schema validates it. A renderer with zero dependencies beyond that schema turns it into SVG, measuring text from an embedded table rather than a browser, and emitting SMIL animation with no JavaScript so it plays inside a GitHub comment.

The rendered SVGs go to content-hashed keys, because GitHub's image proxy caches a URL forever and a stable filename would mean a stale diagram after the next push.

What PR Lens will not do

It will not find your bug. There is no severity ranking, no suggested fix, no chat, no learning loop that tunes findings to your team's taste. If PR Lens is the only automation on your pull requests, nothing is checking correctness, and a bug finder is the more urgent purchase.

It is MIT licensed, free for open source, and runs four ways: the GitHub App on repositories you pick, a GitHub Action with your own key, a CLI, or an agent skill that reasons with whatever model your coding agent already has open. That last route has no key to configure at all.

If the finder slot is what you are shopping for and Greptile is one of two or three names on your list, PR Lens vs Cursor Bugbot covers the other one people put beside it, and AI code review tools in 2026, grouped by what they actually do sorts the whole category by job with September 2026 prices.