# Per-seat billing turns a 60ยข code review into $4 > You are billed per developer and you consume reviews per pull request. Here is the division, plus the adjudicated pull request where our AI reviewer caught one defect out of six. - Source: https://jays.fyi/blog/how-i-removed-greptile - Author: Jay Derinbogaz - Published: 2026-08-08 - Language: en - Tags: tooling, code-review, pricing - Reading time: 10 min ---
Receipt from Greptile for $861.00, paid August 3, 2026.
One month of Greptile, August 2026. The pricing page says $30.
Do the division on your AI code review bill. Not the sticker price, the actual division: what you paid last month, divided by the number of pull requests it reviewed. I did it for our team and the number was so much worse than the number on the pricing page that I assumed I had made a mistake. I had not made a mistake. I had just been buying the product the way it was sold to me instead of the way we use it. Here is the thesis, and everything after this is evidence for it. AI code review is sold per developer and consumed per pull request. Those two numbers have nothing to do with each other, and the gap between them is where your money goes. Separately, and worse, the tool we were paying for read a diff with six real defects in it and found one. We replaced it with something we built. I am going to show you the receipts for both claims, including the parts that make us look worse. ## Six defects went in. One came out. The pull request was an autosave refactor in our platform. Ordinary, mid-sized, the kind that gets opened on a Tuesday and nobody loses sleep over. Greptile reviewed it, left two comments, and moved on. Afterwards one of our engineers went through the diff by hand and adjudicated it properly, writing down every genuine defect without looking at which tool had reported what. Six defects. Four of them P1, the kind that corrupt user data rather than annoy somebody. Autosave re-armed itself forever after normalizing values. A failed save retried in an infinite loop. Autosave clobbered what the user was actively typing in another tab. A save promise was thrown away unhandled. Leaving the page dropped everything pending. The save button rendered only when the step *couldn't* be saved. One of those six was reported. None of those six reached production, and I want to be precise about why, because the reason is the whole point. They were caught because a human read the diff. Not because the reviewer stopped them. We were paying for a safety net that caught one thing out of six, and the thing that caught the other five was an engineer reading the code line by line, which is the exact activity the product exists to reduce. ## Being confidently backwards is worse than saying nothing There was a seventh finding. It wasn't real. We were told "failed autosave has no retry." The actual defect, sitting in the same function, was the opposite: failed autosave retried *forever*. Not a missed bug. An inverted one. I have thought about that one more than the five misses combined. A miss is silence, and silence is survivable, because you already assume your reviewer is not omniscient. An inversion is worse than silence. It sends an engineer into the correct file looking for the wrong thing, and when they don't find the thing that was never there, they close the file and mark it reviewed. A false report doesn't just fail to help you. It spends your attention, and it spends it in the exact place the real bug was hiding. One real finding. One backwards finding. Six defects in the diff. ## One model means one blind spot, and you will never learn its shape My first reaction was that we had bought the wrong tool. That reaction was wrong, and getting past it took longer than I would like to admit. Every frontier model has blind spots and they are not the same blind spots. That is not a defect in any particular vendor's product, it is what these systems are. Which means that if you build your review process on exactly one model, you have built it on exactly one pattern of blindness, and you will never learn the shape of that pattern, because the only instrument that could show it to you is the instrument that is blind. Let me spell this out. The problem is not that your reviewer is bad. The problem is that your reviewer is *singular*. A second opinion was never a luxury in code review, it was the entire mechanism by which code review worked, and we quietly dropped it the moment we automated it. So we built Juror. Several frontier models review the same diff in parallel, each through its own native agent harness, each free to search your repository the way its vendor intended. Their findings collapse, so three near-duplicate reports of one defect become one finding rather than three, and what lands on the pull request is a single comment. We ran it against the same commit. | Reviewer | Found | Precision | Cost | Time | | --- | --- | --- | --- | --- | | Greptile | 1 of 6 | 50% | not disclosed | not disclosed | | Juror | **4 of 6** | **100%** | **$1.08** | 8m22s | ## Here is the part where we lose Juror missed two. Greptile caught the discarded save promise and we did not. Neither tool found the infinite retry loop. Put both reviewers together and you get five of six, which is better than either managed alone, and I am not going to bury that underneath the table above. I could have cut this section. I am keeping it because it *is* the argument. Different models catch different things. That is not an awkward caveat stapled to our pitch, it is the pitch, and a competitor's model finding something ours missed is the cleanest demonstration available that running a single reviewer is the mistake. The day that stops happening is the day I start worrying our jury has collapsed into one opinion wearing four hats. ## You are not paying for reviews. You are paying for chairs. Now the bill, which is where this stops being about one pull request. [Greptile's Pro plan](https://www.greptile.com/pricing) is **$30 per seat per month**, as of August 2026. That includes 50 credits per seat, where one credit buys a standard review and three buy a deeper one, and further credits are $1 each. Per review, that is cheap. Roughly sixty cents, if you use every credit you are given. I want to be completely fair here: on a per-unit basis that is lower than what our own tool cost on the pull request above. A small team that fully consumes its allowance should buy the seats, and I am not going to pretend otherwise. Nobody fully consumes their allowance. You are billed per *developer*. You consume reviews per *pull request*. Those two numbers stop tracking each other the moment headcount grows faster than merge rate, which is to say immediately, in every engineering organisation that has ever existed. Twenty engineers on Pro is $600 a month and a thousand credits. If that team merges 150 pull requests, a completely normal month, you have paid **$4 per review** and let 850 credits expire. The list price never moved. Your utilization did. Sixty cents became four dollars and nobody sent you an email about it. Call it the seat tax: money spent on a per-developer licence for a product consumed per-artifact. It is invisible on the pricing page, it scales with hiring instead of usage, and it is the largest line item in what you actually pay. ## I can tell you what this cost because we print the receipt Juror has no seats. It runs in your own GitHub Actions runner, calls the model APIs with your own keys, and the bill is the inference and nothing else. That review of the autosave PR, four real defects and no false positives, cost **$1.08** and took eight minutes and twenty-two seconds. I can tell you that to the cent because every Juror review ends with a table: each model, its input tokens, its cached tokens, its output tokens, its dollars. Every figure is labelled `reported` when the provider computed it, or `estimated` when we derived it from published list prices. When a harness gives us neither, it prints `unknown` and the total is marked a lower bound. We do not guess and we do not round toward ourselves. Now look again at the two cells in that table that say "not disclosed." That is not a gap in my research. The tool does not tell you what a review cost, because it does not have to. You bought a seat. The unit economics are the vendor's business, and the vendor would rather you kept doing the multiplication their way. That was the thing I actually wanted and could not buy at any price. Not a cheaper reviewer. A reviewer that tells me what it spent. ## What I am not going to do is call this a benchmark This is one pull request. Our own [benchmarking protocol](https://github.com/juror-ai/juror/blob/main/docs/benchmarking.md) says a replacement decision needs 20 to 30 adjudicated PRs spanning frontend, backend, migrations, concurrency, security-sensitive code, and both small and large diffs. We have one. It sits in the repository with a warning attached saying it must not be presented as statistically sufficient evidence that either reviewer can replace the other, and I am not going to violate our own warning inside a blog post about how carefully we report numbers. Four of six against one of six is not a benchmark result. It is one adjudicated case that made me willing to run both side by side. A different pull request, one leaning hard on repository-wide context where an indexed reviewer should do well, could plausibly invert it. If it does, that case goes in the corpus too. What is not a sample of one is the arithmetic. Thirty dollars a seat times twenty engineers is $600 whether I like it or not, and 150 reviews against a thousand credits is 15% utilization in any month you care to measure. We switched on the pricing structure, which I can defend with division, and on one promising case. Not on a performance claim we have not earned yet. ## Go measure us Don't take my word for any of this. I have a commercial interest in your conclusion and you should weight everything above accordingly. Put both reviewers in shadow mode on your own repository. Let them run a few weeks without either one blocking a merge. Then take every finding, strip the labels off so nobody knows which tool said what, and have a senior engineer adjudicate them cold against the code. Count what each one caught. Count what each one invented. We shipped the tooling for exactly this, because we needed it ourselves: ```bash npx juror-ai benchmark --file your-corpus.json ``` It reports recall, precision, duplicate rate, cost and latency for every reviewer you feed it, and it lists every miss by name. Ours included. I don't think the seat model survives contact with anyone who does the division. It survives now because the division is mildly annoying and the pricing page is arranged so you don't bother. Somebody in your organisation runs that calculation eventually. When they do, the answer will not be sixty cents. That autosave pull request merged this morning, incidentally. It took two more commits to get there, one to make navigation saves single-flight and one to make autosave converge and leave the builder alone. Good commits. Nothing on fire. Nobody will ever know they were necessary, because bugs caught before merge leave no trace and generate no incident report. That is the part of this that should bother you. The reviewer that missed five of them costs the same whether it finds six or zero, and it will never tell you which of those two months you just paid for. --- *Juror is open source and MIT licensed: [github.com/juror-ai/juror](https://github.com/juror-ai/juror). Greptile pricing cited from [greptile.com/pricing](https://www.greptile.com/pricing) as of August 2026.*