Bugbot

By Minel Gunesoglu, founder. No repository was connected and no review was bought, so nothing here reports how this tool behaves on your code. What was read, on 5 September 2026: the pricing page in both billing views, the Bugbot documentation and its legacy-pricing page, the May 2026 announcement, Anysphere's Terms of Service, the status page, and three r/cursor threads read end to end. The benchmark figure was read on 15 August 2026 and is dated as such.

A team deciding whether to turn this on is deciding two things, and only one of them is easy to look up. Whether the reviews are any good has a third-party answer. What they will cost does not, at least not where a buyer would look for it.

On 11 May 2026 Cursor announced that Bugbot was leaving a flat seat fee behind. Its own words: "Bugbot is switching from a $40 per seat per month subscription to usage-based billing for Teams and Individual plans." The same post gives the replacement figure, and it is the only place this desk found one: "The average Bugbot run costs $1.00-$1.50, depending on PR size and complexity."

Four months later that number is still only in the blog post. The pricing page was read in both billing views on 5 September 2026 and neither carries a rate for this product. The documentation's own Pricing section says "Bugbot Teams bills from on-demand spend. See the pricing page for current rates", which sends the reader to the page that does not have them.

None of that says the product is expensive, and the people using it do not agree that it is. It does mean the cost question has to be answered by arithmetic a buyer does themselves, from a figure the vendor published once, in a place the pricing page does not link to.

What Changed in Bugbot's Billing on 11 May 2026, and What a Review Costs Now

The announcement is short and specific. Verbatim: "We are removing seat fees for Bugbot and transitioning to purely usage-based billing. For Teams, Bugbot will bill from on-demand spend; for Individuals, it will bill from included usage." Existing customers were given a runway: "For existing customers, this change will start at your next billing renewal after June 8th, 2026."

So the shape of the bill inverted. Before, a fixed amount bought a capped volume. After, volume drives the amount and nothing published caps it.

Both columns come from the vendor. The left one is transcribed from the page Cursor still hosts at /docs/bugbot/legacy-pricing, which describes the arrangement it replaced.

Where Bugbot's Per-Review Rate Is Actually Published, and Where It Is Not

The pricing page carries 2,121 characters of visible text. The words "per review", "per PR" and "per pull request" appear on none of them. What it does carry, on the paid Individual tiers, is the line "Bugbot on usage-based billing", and on Teams, "Agentic code reviews with Bugbot".

That line is identical in the Monthly and the Yearly view. The toggle was operated and the control's state read back to confirm the view had actually changed, because the first two attempts landed on a hidden duplicate of the same control and reported the same prices for a different reason. Switching to yearly moves Individual from $20 to $16 a month and Teams from $40 to $32 per user. It does not move Bugbot, because Bugbot is not what those plans are buying.

For a buyer the practical consequence is a small calculation the vendor could have shown. At the published average, a team merging 200 pull requests a month is looking at $200 to $300 of usage on top of its seats. A team merging ten is looking at $10 to $15. The same product, the same rate, and two entirely different decisions.

What the Old Bugbot Seat Price Published That the New One Does Not

The legacy page is more specific than the current one, and that is a fact about two documents rather than a judgement about the change.

It published the price: "Teams paid $40 per user per month for reviews." It published the unit that price counted: "We count a user as someone who authored PRs reviewed by Bugbot in a month." It published a control for finance: "Team admins could set maximum Bugbot seats per month to control costs." And it published a hard ceiling: "we have a pooled cap of 200 pull requests per month for every Bugbot license."

The current documentation publishes a billing model and refers to rates it does not print. Whether a given team pays more or less than before is not settled by anything published, and this page does not settle it either. The arithmetic above is there so a reader can run it against their own merge rate, which is the number that decides it.

Do You Need a Cursor Subscription to Use Bugbot? Yes, and Then Usage on Top

Bugbot does not appear in the feature list of the free Hobby tier. It appears on the paid Individual tiers and on Teams, so entry is a $20 a month plan at minimum and then usage against it. The documentation states the same exclusion for Cursor's India-only plan in plain words: "Start does not include the Other Models pool, on-demand usage, Bugbot, Auto, Automations, or the Cursor SDK. Upgrade to Pro for those."

There is a trial rather than a free tier. The product page's FAQ: "We offer a 14-day free trial for all plans."

One further rate sits underneath a Teams review and the vendor does not say whether the published average includes it. From the account-pricing documentation: "On Teams and Enterprise plans, third-party model requests include a Cursor Token Rate of $0.25 per million tokens. This rate applies on top of model API pricing". A review runs on a model. Whether that quarter-dollar is inside the $1.00 to $1.50 or beside it was not established, and it is left open here rather than guessed.

Who Owns the Code Bugbot Suggests, and What the Indemnity Makes You Cover

Anysphere's Terms of Service carry their own stamp of 3 September 2026, two days before this reading, which makes them the freshest contract on this site.

Ownership is settled by an assignment, which is the strongest form the clause takes. Section 5.3: "You retain all of your right, title, and interest that you have in Inputs, and Anysphere hereby assigns to you all of our right, title, and interest if any in and to any Suggestions." Section 1.2 defines Suggestions as the "code, outputs, or other functions" the service returns, which is what a review comment is.

A limit belongs beside it and does not contradict it. Section 5.1 keeps the service itself with the vendor and adds "There are no implied licenses in these Terms". That is the product, not what the product hands you.

The indemnity runs one way, as it does in most of the agreements read for this site. Section 13: "you will defend and indemnify Anysphere, its affiliates and each of their respective shareholders, directors, managers, members, officers, employees, consultants, and agents". A search for the root across the full 63,425 characters of extracted text returns six matches, every one inside that section and every one pointing the same way.

Can You Get a Bugbot Refund? The Contract Says No Except Where Law Requires

Section 4.1 is one sentence and it is unambiguous: "all fees are in U.S. Dollars and are non-refundable, except as required by law."

The document does promise a refund elsewhere, and it is worth reading closely because it runs the other direction. If Anysphere ends a subscription, "we will refund you on a pro rata basis the fees you paid for the remaining portion of your Subscription Service after termination", withdrawn where the termination follows a breach. That is a refund the vendor triggers, not a window a buyer can use, and this card does not score it as one.

Under per-review billing the practical exposure is smaller than a seat fee and harder to bound. Money already spent on reviews is spent. What is not published anywhere read for this page is a spending ceiling a team admin can set, which is the control the legacy arrangement did publish.

What Bugbot Users on r/cursor Reported While the Billing Change Landed

No consumer rating of this product exists. That is not a blocked platform, it is an absent record: G2, Capterra, TrustRadius and Trustpilot were checked by name on 27 August 2026 and every listing returned is about Cursor the editor. G2's "BugBot" entry belongs to an unrelated IoT testing tool from another company.

What does exist is r/cursor, opened for this desk on 4 September 2026. Seven threads name the product; the three deepest were read end to end. Across them six accounts call it expensive in their own words and five report it catching real defects. Nobody in the sweep says it does not work.

The pricing argument is not one-sided, and the vote counts say so more clearly than the prose does. The post whose entire body reads "1.00-1.50$ per review seems absurd" carries a score of 37. The highest-scoring comment in the whole sweep sits underneath it at 28 and disagrees: "This actually makes a lot more sense than the $40 a person". A third account puts the same view in terms of who benefits, saying it is "cheaper now for the Devs that aren't doing a many PRs in a month".

The $300 Bugbot Bill, and the Cost Attribution Nobody Could Find

The most detailed account in the sweep is from 27 July 2026 and its sharpest part is not the size of the bill. Twenty engineers, two repositories, default settings: "Bugbot consumed almost $300 in just 14 days reviewing GitHub PRs across two engineering teams (20 engineers) and two repositories."

Then the part that matters more: "we also couldn't find a good way to see which PRs or reviews consumed the most credits". The same person, answering a question about whether the reviews were any good, said most comments were useful and added "there was no transparency around which PRs consumed how many tokens or which models were used".

Two people in that thread attribute the size to their own configuration, and one of them is the person who paid it. Another commenter reports their company stopping after two weeks and describes the tool in five words that carry the whole thread: "Good but expensive."

Read that beside the vendor's documents and the two halves meet. A buyer could not reconstruct the spend afterwards, and on the evidence above could not have projected it beforehand either.

Why Bugbot Finds New Issues After You Fix the First Ones, in Its Own Engineer's Words

Three accounts describe the same loop independently: a short list of findings, a fix, a push, and a different short list unrelated to the fix. One of them names why it matters now rather than before, in a thread about the billing change: "It happens often to me that it gives 3 issues, then once fixed 2 new ones". Under per-run billing each of those pushes is another charge.

A Cursor employee answered it on the thread rather than leaving it, opening with "I work on Bugbot", and the answer is unusually plain about what the technology can promise: "this is fundamentally an unsolveable problem. LLMs are probabilistic at their core so please be wary of anyone promising you deterministic results."

Nothing in that exchange reaches the score. A vendor's statement about its own product is a statement, and this site does not score one. It is quoted because a buyer weighing a per-review bill should know the behaviour is acknowledged rather than disputed.

How Bugbot's 75.5 Is Built, and the Row That Runs Against Its Rank

Computed 5 September 2026. Two of the four rows below are labelled for a different question from the one their axis usually asks, and the label on each says which.

Bugbot's Precision Score Is the Highest on the Board, Its Recall Is Not

The capability row reads the Martian code-review benchmark as it stood on 15 August 2026: eleven reviewers scored on real open-source pull requests, judged by whether their suggestions led to actual code changes. On that reading the row places second of eleven at 60.3% F1, from a sample of 279 pull requests inside a 4,299-PR window.

The rank is not the interesting number. The two columns behind it are. Precision reads 75.6%, the highest of the eleven; recall reads 50.1%, which is mid-field. A reviewer with that shape says less and is right more often when it does say something, and misses more of what a thorough one would catch.

Which is what the users described without seeing the board. The team that had run a competing reviewer in this same category contrasted the two on verbosity rather than on accuracy, and the account calling the output high-signal is describing a precision figure it never read. Two independent kinds of evidence, one shape.

Reading this row needs one caution the board itself supplies. The ranking moves with a slider that trades precision against recall, so 60.3% means nothing without the setting it was read at, which was the balanced default.

That the row belongs to this product rather than to the editor took three steps to establish, because the board labels it "Cursor" and the word "Bugbot" appears on it nowhere. The board's own configuration tracks GitHub bot accounts rather than product names and lists exactly one Cursor-owned account. Its methodology document, 57,228 characters, mentions neither name. The account itself closes it: GitHub returns 867,810 pull requests carrying a comment from that account, and the comment body is branded Bugbot in its own heading.

Why No Star Rating for Bugbot Exists, and What Fills That Row Instead

The usability row does not report what users say, because no platform carries a rating of this product to report. What it reads instead is the set of promises the vendor has put in writing about reaching the service and staying on it, which is the nearest thing to a buyer's experience that traces to a document.

Four positions, all published. Regional limits are disclosed and delegated: certain models are unavailable in certain regions and the documentation links each model provider's own list rather than printing one. One hard usage number exists and it is per team rather than per tier, from the Bugbot API reference: "All endpoints are rate-limited to 60 requests per minute per team." Support is named and differentiated by tier. And the status page publishes ninety days of uptime per component with a dated incident history, including the component this product runs under, which read "Review Agents Operational 90 days ago 99.67 % uptime Today" on 5 September 2026.

That last figure is the vendor's own and is not scored as a measurement of the product. What the row scores is that a status page with history is published at all.

Bugbot Alternatives Among the Cards Scored Here

All four F1 figures come from one reading of one board on 15 August 2026, which is the only way the row means anything. A later capture of the same board shows every position moved, so a table mixing two readings would be comparing two boards rather than four tools.

The precision and recall columns are where the real choice sits. Bugbot and Greptile cluster at the high-precision end and CodeRabbit at the high-recall end, and the community records for the two ends read exactly as the columns predict: this tool is described as high-signal, and the noise complaint in this category belongs to the card with the highest recall and the lowest precision.

Cost is where the four stop being comparable. Three publish a seat or credit price a buyer can multiply. This one publishes an average per review and a billing model, and what a month costs depends on how many pull requests a team merges.

What a Team Should Check Before Turning Bugbot On

Whether these reviews are useful on your particular codebase is not something this page knows, and no page does.

The bill is different: it can be worked out in advance from one number you already have. Take your merged pull requests per month, multiply by the vendor's own $1.00 to $1.50, and decide against that rather than against the seat price the plan shows. Then read the two settings the community thread found before the vendor's documentation surfaced them: running on manual invocation rather than on every push, and reviewing incremental changes rather than the whole diff each time. Both were named by people who had already paid a bill they could not attribute.

One thing this evidence does not support is treating the benchmark rank as the reason to buy. Second of eleven at the balanced setting is a real result, and the precision column behind it is the more useful fact: a reviewer that flags less and is right more often suits a team drowning in comments, and suits a team worried about what gets missed rather less.

Dates on this page are not decoration. Everything except the benchmark was read on 5 September 2026 and saved; the benchmark belongs to 15 August 2026 and carries that date wherever it appears, because the board it comes from resets and a figure without its reading date cannot be checked against anything. Nothing is earned if you buy this product: Anysphere runs no programme this site is in, and there is no affiliate link on any page here, which about counts at build time rather than asserting. The methodology page sets out what gets measured and what this site will not claim.