CodeRabbit vs Greptile vs Bugbot vs Diamond: You Are Buying a Comment Budget

At a glance

Four tools that review a pull request and leave comments on it. As listed in August 2026.

Cursor announced its acquisition of Graphite on 19 December 2025, which is why two rows of that table share an owner — a fact that matters more than it looks, and we come back to it below.

Three billing shapes, and each one buys a different behaviour

Pricing in this category stopped being a footnote in 2026. Bugbot dropped a $40 seat for pure usage billing in June; Greptile moved in March to a seat that includes fifty reviews and then bills a dollar a review; CodeRabbit kept a seat with a review cap and added a more expensive tier that raises it; Diamond has no separate price at all because it comes with the platform. Those are not four points on one axis. They are three different answers to the question of what a review is worth.

A seat with a cap makes the cap the product. The marginal review is free until it is impossible, so the pressure is on ration and rollout — which repositories are wired up, which developers have seats — and the failure mode is a team that turns the bot off for a whole service because it ran out of headroom on a busy Thursday. Per-review billing inverts that: every pull request is a purchase, so teams start gating by branch, by size, by label, and the failure mode is a rule that quietly excludes the automated dependency bumps where the interesting regressions actually hide. Bundling hides the price entirely, which is comfortable until you notice that you have chosen a code reviewer by choosing a pull-request workflow.

What none of the three prices is the comment. Every tool bills for reviews, seats or platforms; the resource that actually gets consumed is a developer reading a paragraph and deciding whether it is right. That is the scarce input, it is unmetered, and it is why two tools at the same list price can differ by an order of magnitude in what they really cost you.

Where the seat and the meter cross

Run the list prices out and the shapes cross in a place that should change your answer. Below roughly twenty reviews per developer per month the metered tool is the cheapest thing on the page and the seats look like overpayment; above it the lines invert, and a busy team on per-run billing is paying more than either seat while getting no discount for volume. The crossing point is not exotic — a developer opening a pull request a day lands right on it — which means the arithmetic is genuinely load-bearing rather than a rounding difference, and it also means the answer flips when your team's habits change.

The second-order effect is worse than the first. Metered billing does not merely cost more at volume, it changes what gets reviewed, because somebody eventually writes the rule that excludes small pull requests or bot branches to keep the bill down. Renovate bumps and one-line configuration changes are exactly where a reviewer earns its keep, and they are the first things a cost rule deletes. If you go metered, budget for full coverage and gate on nothing — the moment you are pruning the input set to control spend, the seat was cheaper and also better.

The accuracy numbers disagree, and most of them have an author

Here is the state of the evidence, stated plainly. Greptile publishes a benchmark over fifty open-source pull requests from projects including Sentry, Cal.com and Grafana in which Greptile catches 82% of the seeded bugs against CodeRabbit's 44% — and, in the same run, produces eleven false positives against CodeRabbit's two. A separate 2026 comparison describes Greptile as the less chatty of the two, commenting only when confident. A third-party roundup puts Diamond at 0.62 comments per pull request and Bugbot at 0.91, the most selective of the field, and in the same breath scores Diamond at an 18% catch rate. An independent study by Martian ranked CodeRabbit first of ten tools.

These cannot all be describing the same thing. They are not: they differ in language mix, repository size, whether bugs were seeded or naturally occurring, whether style comments counted as findings, and what "false positive" meant to whoever tallied it. Seeded-bug benchmarks in particular reward a tool tuned to be suspicious, because the bug is definitely there; production repositories reward the opposite, because usually it is not. That single methodological difference is enough to flip the ranking of two tools without either changing.

The invariant across all of it is the shape of the trade-off, not the position of any tool on it. Every reviewer in this market sits somewhere on a curve from quiet-and-missing-things to loud-and-often-wrong, and vendors move along that curve between releases far faster than benchmarks get re-run. A number from a benchmark that ran two quarters ago describes a configuration that no longer exists. Treat the published figures as evidence that the trade-off is steep — which is genuinely useful — and not as a ranking.

Comments per pull request is the number that decides adoption

A review bot's real budget is denominated in developer-seconds, and its real failure is not a missed bug. It is the Tuesday in month three when a senior engineer stops reading the bot's comments, and then everyone else does, and then the missed bugs stop mattering because nobody was going to read the caught ones either. That collapse is driven almost entirely by the fraction of comments that turn out to be worth reading, which is why the same roundups that report catch rates also report that a large majority of AI review comments concern style rather than logic — the ratio, not the recall, is what people are reacting to.

This is the same conclusion our code-review agents playbook reaches from the build side: precision is the product, and the only production metric that means anything is the acted-upon rate. It also explains the otherwise strange fact that the two most selective tools in the field are the two owned by an editor company. When your reviewer's comments appear next to the code in the same product the developer already lives in, an ignored comment is visible in a way that an ignored GitHub thread is not, and the incentive to stay quiet is stronger.

Two practical consequences. First, cap the comment budget yourself if the tool lets you — a hard limit of three or five comments per pull request, ranked worst-first, is a better default than any confidence threshold, because it fails gracefully on the big refactor where an unbounded reviewer produces forty notes and gets closed unread. Second, measure dismissal, not detection. Every tool here can tell you how many findings it produced; almost none will tell you how many were resolved rather than dismissed, and that ratio is the entire health signal.

Two of the four have the same owner now

Cursor acquired Graphite in December 2025 and has said the products will keep running separately for a while. Take that at face value and the market still looks different than it did: at the selective end of the range, where a team that has already been burned by a noisy bot wants to shop, there are two products and one company. Bugbot and Diamond are not the same tool — one is a diff reviewer bound to an editor, the other is a reviewer bound to a stacked-pull-request workflow — but they are one roadmap and one pricing department, and the June move of Bugbot to usage billing is the kind of decision that tends to propagate.

The exposure is different in each direction. Choosing Bugbot ties your review quality to a company whose main business is an editor, which is fine while the editor is the one your team uses and awkward the year it is not. Choosing Diamond ties it to a pull-request workflow: Graphite's value proposition is stacked diffs, and adopting it to get the reviewer means adopting a branching model. Greptile is the one that most explicitly sells editor-agnosticism, which is a real property in a shop with three editors and a fleet of coding agents opening pull requests. CodeRabbit is the independent generalist with the broadest platform coverage and the longest track record of being the safe institutional answer.

None of this is a reason to avoid a tool. It is a reason to keep the integration shallow — these all attach as a GitHub app or check and detach the same way, and a category this young with this much acquisition activity is not one to build a workflow around.

When to pick which

The procedure that actually answers this is boring and takes a fortnight: run two of them in parallel on the same repository, on every pull request, with no cost gating and no tuning. Then count — for each tool — comments emitted, comments that led to a code change, and comments dismissed. The winner is the one with the higher second number and the lower third, and the arithmetic will not resemble anybody's benchmark, because it is measured on your codebase, in your language, at your team's tolerance for being told about a naming convention.

Further reading

On this wiki:

• Code review agents — the build-side argument that precision, not recall, is what a review bot is for.
• Background coding agents — where all the extra pull requests these tools now review are coming from.
• Evaluating coding agents — why a benchmark score belongs to a harness, not a model.
• Unit economics — for putting a per-review price next to a per-outcome one.

Sources:

• Cursor — Graphite is joining Cursor
• Cursor — updates to Bugbot for teams and individuals
• Greptile pricing
• Greptile's published AI code review benchmarks