Greptile

Greptile's pitch is simple: it reads the whole repository, then reviews the pull request with that context, so it catches the change that breaks a caller three directories away, the bug a diff-only reviewer cannot see. That is the trait that decides it, and on a large codebase it is the one that matters.

The daily cost is that a whole-repo reviewer has opinions about code you did not touch, so expect to tune it for a week. Pick it for a large codebase where context is the problem. Pick CodeRabbit if you need more hosts, or review free public repos, and diff context is enough.

The benchmark is the risk. An 82% bug catch rate sounds like a benchmark; it is a small vendor-selected sample, scored by the party being measured, with no precision figure, so you cannot tell how much noise comes with the catches. A reviewer that flags everything also catches 82%.

The consequence: run it on a month of your own merged PRs before believing the number, and count the comments you dismissed. A third-party evaluation with a false-positive rate would change this verdict. What it does right: indexing the entire repository before reviewing is the correct way to review.

The architecture is defensible: index the full repository, review each pull request against that index, so the reviewer sees callers and contracts the diff omits. The measurement is not. Fifty bugs across five repositories, chosen by the vendor, with no false-positive rate reported, cannot support a percentage with two significant figures.

The consequence is that the design and the number should be judged separately, and only the first survives scrutiny. A held-out set of bugs the vendor did not choose would settle it. The observation: the design would survive a model change; the number would not survive a second sample.

Two things I like. The index is data and switching cost at once: the longer it runs on your repo, the more it knows and the harder you leave, which is the one moat a review bot can build. The tariff, a seat plus per-credit overage, means revenue grows with activity without a repricing conversation.

The risk is that the index is a cost as well as an asset, and indexing every customer's repository is compute the vendor pays before the seat does. Likely acquirer: GitLab, which it already integrates and which needs a reviewer of its own. Position: fine at seat scale, watch the credit price.

The demo knows the rest of the repository, which is what reviewers actually lack. Procurement: Pro is $30 per seat with 50 credits, extra credits at $1 each, so sixty seats is $1,800 a month plus an overage that scales with pull-request volume, and pull-request volume is the one number that goes up when the tool works.

Fit is narrow: a GitHub or GitLab app, no CLI, so it lives in the review step and nowhere else. Onboarding is an app install. Approved with conditions: a thirty-day credit burn measurement and an Enterprise quote with the self-hosting terms in writing.

There is almost nothing here to bend. It runs in Greptile's cloud, and the base-URL settings that would point it at models I host myself ship only with the Enterprise self-host, so the open-source version of me never touches it. The single handle is the hosted MCP server, which feeds review context into my own editor agent as a tool.

That handle is worth something: my agent can ask what the reviewer knows about a file without leaving my terminal. The whole-repo indexing idea is right and I would love an open implementation to run on my own box. This is not one, and a fork is not possible.