PR Lens vs Cursor Bugbot

Bugbot finds bugs. PR Lens draws the change. Cursor's own documentation describes Bugbot as a tool that "reviews pull requests and identifies bugs, security issues, and code quality problems", and its May 2026 pricing post puts an average run at $1.00 to $1.50. PR Lens produces no findings, no severities and no suggested fixes. It turns the pull request into animated architecture and data-flow diagrams and posts them as one comment. Bugbot reads the diff for what is wrong with it; PR Lens draws the system the diff landed in.

If you are picking one, pick by which question is hurting you.

What Bugbot does

Bugbot connects through the Cursor GitHub App, and Cursor's docs also list GitLab, Bitbucket and Azure DevOps. Once it is enabled on a repository it "analyzes PR diffs and leaves comments with explanations and fix suggestions", running automatically on each pull request update or on demand when someone comments bugbot run or cursor review.

A few operational details from the docs, all as of September 2026:

• Incremental review is on by default, so Bugbot looks at what changed since its last review rather than the whole diff on every push. You can turn that off.
• Context comes from .cursor/BUGBOT.md. Bugbot always includes the one at the repository root and picks up others while walking upward from the changed files. Cursor rules in .cursor/rules/*.mdc do not apply to Bugbot runs, which surprised me the first time.
• The status check defaults to a neutral conclusion, so requiring it does not block a merge on findings.
• Autofix spawns a Cloud Agent to fix what the review found and pushes it to a branch, capped at three attempts per pull request when it commits to an existing branch.
• You can also run it before you push, with the /review-bugbot or /review skills inside the editor.

Cursor publishes numbers on it too. The changelog dated 10 June 2026 says the average review time is now about 90 seconds, down from about 5 minutes, that Bugbot finds 10% more bugs per review on average at 0.62 up from 0.56, and that a run costs about 22% less. The May 2026 post describes effort levels, where default effort means "80% of bugs identified are resolved by merge time" and high effort "finds 35% more bugs while resolution rate stays constant at 80%".

I take those as vendor numbers, measured by the vendor. They are still more than most tools in this category publish, and 0.62 bugs per review is a refreshingly unglamorous figure to put on a changelog.

What PR Lens does

PR Lens reads the diff and the system around it, then writes a typed JSON graph document: lanes, nodes, edges, and what the change did to each one. A renderer with no dependencies beyond its own schema turns that document into SVG. The model never draws.

Two lenses come out of one document. Architecture is the blast radius: the components the pull request touches, drawn against the ones it did not, with the calls between them. Data flow is the ordered pipeline of the change as an animated sequence, one dot crossing one arrow at a time. Colour carries the delta: green new, amber changed, red gone, with retired components struck through.

It posts as exactly one comment on the pull request, rewritten in place on every push, with nested details sections that narrow the diagram to the new path or to what was retired. Each comment links to a canvas where the diagrams are full size and where pressing play walks the change one step at a time.

Diff scope and system scope

The difference that matters is scope, and it says nothing about which tool is better at its job.

Bugbot analyses the diff. That is the right scope for its job: a bug lives on a line, and to judge a line you need the line and enough around it to know what it does. Incremental review narrows the scope further, to the lines that arrived since the last pass.

PR Lens deliberately draws things the diff never mentions: the queue the new function writes into, the worker the change retired, and the email API on the far side that neither of them touched. Those components carry no diff lines at all, and they are exactly what you need to answer "what is this change doing to my system".

Both scopes are correct. They are answers to different questions, which is why the two comments do not compete for the same space in a pull request.

What Bugbot is good at

Speed and restraint. Ninety seconds from push to findings is fast enough that the review lands while you are still in the pull request, and a tool that reports 0.62 findings per review is not carpet-bombing you. Cursor's landing page claims "more than half of the bugs that we find are ultimately fixed by engineers", which if you have watched a noisy reviewer get muted by a team is the number that actually matters.

The context file is well designed. A root .cursor/BUGBOT.md plus per-directory files, inherited upward from whatever changed, means the rules that apply to the payments directory can live in the payments directory. That is closer to how teams actually hold review knowledge than one long file at the root.

Autofix is a reasonable bet too. If the finding is real and small, the round trip through a human is the expensive part.

What Bugbot costs, as of September 2026

Cursor changed this recently, so any round-up you read from earlier in the year is out of date. The blog post dated 11 May 2026 says Bugbot "is switching from a $40 per seat per month subscription to usage-based billing for Teams and Individual plans" and that Cursor is "removing seat fees for Bugbot", effective at each customer's first billing renewal after 8 June 2026. The same post says the average run costs $1.00 to $1.50 depending on pull request size and complexity.

On individual plans, Bugbot consumes included usage first and then bills additional reviews to on-demand spend. Cursor's docs mention that some Teams and Individual plans include monthly Bugbot usage but do not put a number on it anywhere I could find, so I am not going to invent one. The Cursor pricing page lists Hobby free, Pro at $20, Pro+ at $60, Ultra at $200 and Teams Standard at $40 per user per month, with a Teams Premium tier above it, and Bugbot appears as a feature on those plans rather than as its own line. Verify all of it before you budget, because it moved once already this year.

PR Lens is MIT licensed and free for open source. The hosted GitHub App runs on Gemini and never asks for a key of yours. If you would rather keep the model call inside your own CI, the GitHub Action takes your key and speaks Gemini, OpenAI, or any endpoint answering /chat/completions. There is also a CLI and an agent skill, which lets whatever coding agent you already run draw the change without any key at all. The full set of routes is in what is PR Lens, and the free options across the whole category are in free and open source AI code review tools.

Running both on one pull request

They do not fight. Bugbot writes inline comments on diff lines and a neutral status check. PR Lens writes one top-level comment, identified by a hidden HTML marker so it only ever updates its own, redrawn on each push, with an older analysis discarded if it finishes late.

The reading order I would suggest: diagram first, findings second. A comment saying a query is unscoped means more once you have seen which worker reaches that store. Reading it the other way around means holding a list of line numbers in your head while you work out what the change was for.

Which one to turn on first

Turn on the finder if agent-written code is landing with bugs your team is not catching. That is the problem Bugbot is built for, and it is fast at it.

Turn on the drawing if pull requests sit unread. LinearB's 2026 benchmarks, across 8.1 million pull requests in more than 4,800 organisations, found AI-generated pull requests wait 4.6 times longer for someone to pick them up, over 16 hours against about 200 minutes, and that once review starts they finish faster than human ones. The delay is in the deciding to start. A findings list does not touch that, because you have to open the pull request and engage before a finding means anything.

I run both, and the split makes sense to me on the same page: one tool tells me the change might be wrong, the other tells me what the change is. The wider version of that taxonomy is in AI code review tools grouped by what they actually do, and if the pull requests you are reviewing come out of Cursor's background agents, how to review Cursor background agent pull requests covers what those tend to contain.