Complete BugBot Review (2026)

BugBot is Cursor's pull-request reviewer for teams that want another pass over changed code before merge. It comments on potential bugs, security issues, and code-quality problems, then offers links that can send the finding into Cursor or Cursor's web agent.

The product is most interesting when a pull request is already the unit of work and the team wants a short path from a suspicious line to a reviewed repair.

The decision begins with clear workflow and spending discipline. A bot that reviews every update without a cost boundary can spend money and attention on changes that do not need it. A bot invoked after meaningful changes can become a sharp check for the code paths a human reviewer is most likely to skim.

Cursor provides both automatic and manual modes, so teams can decide which tradeoff fits their pull-request volume.

BugBot at a Glance

checked August 8, 2026: Cursor's BugBot documentation, pricing page, and May 2026 billing announcement describe the product below. Terms move, so treat this table as a dated snapshot.

Area	Current Position	Buyer Check
Review method	Pull-request diff analysis	Cross-file blind spots
Triggers	Automatic or comment	Spend under automation
Billing unit	Usage per run	Runs each month
Published rate	$1.00 to $1.50 average run	Your own run costs
Effort levels	Deeper review costs more	Risk-based policy
Rules	Repository BUGBOT.md files	Rule scope and precedence

BugBot's Pull-Request Loop

Cursor describes BugBot as a tool that analyzes pull-request diffs, leaves explanations and suggested fixes, and can run automatically on each update or from a comment trigger. The documented manual comments are cursor review, bugbot run, and cursor run. These triggers were most recently checked on July 28, 2026.

A finding should lead to a small investigation. Read the changed code and the caller or consumer it affects. Try to construct the state that would fail.

Check the existing tests for protecting behavior and missing cases. Then decide whether to fix, dismiss, or turn the observation into a repository rule. This is ordinary code review work, and BugBot only makes the possible failure easier to notice.

That distinction matters when a comment arrives with a confident explanation. A plausible comment can still miss a guard in another file or misunderstand a deliberate tradeoff. Require the same evidence you would require from a human reviewer: a reachable path, a broken invariant, or a test that demonstrates the failure.

Set Up BugBot Deliberately

Cursor's setup sequence requires Cursor administrator access and GitHub organization administrator access. In the Cursor dashboard, connect GitHub, complete the GitHub installation, then enable BugBot for selected repositories. The product documentation describes those steps and the repository-level controls.

These setup and access details were checked on July 28, 2026.

1. Choose one repository with an active pull-request habit.
2. Confirm which people and repositories BugBot can access.
3. Start in mention-only mode for a short calibration period.
4. Review results on several ordinary application changes.
5. Enable broader automatic coverage only where findings justify it.

The first run is a measurement exercise. A useful pull request changes behavior across a boundary: authentication, data ownership, an external API, a migration, or a failure path. Small content edits and lockfile refreshes can wait.

The aim is to learn what BugBot notices in code that has a credible chance of breaking.

I paused BugBot across my repositories on July 19, 2026 because of Cursor usage limits. That is specific to my workflow, not a claim that BugBot has been discontinued or that every Cursor customer hits the same limit. It is a good reminder to check the dashboard's current allowance before turning on automatic reviews across a busy organization.

Write Rules That Find Defects

BugBot reads .cursor/BUGBOT.md files for repository context. Cursor says the root file is always included, and nested files apply when the review reaches their directory. This lets a repository state one project-wide invariant while giving an API directory its own security and validation guidance.

These repository-rule details were checked on July 28, 2026.

# .cursor/BUGBOT.md

- Check every write preserves the authenticated tenant boundary.
- Do not comment on generated clients under src/generated/.
- Flag a changed public API when its contract test is absent.

# src/api/.cursor/BUGBOT.md

- Trace authorization before every database read and write.
- Check validation rejects unknown fields before persistence.

Build each instruction from a boundary, an operation, and evidence. For tenant security, the boundary is the authenticated organization, the operation is a database write, and the evidence is the authorization path. Start with failures the team has seen and paths that are intentionally generated or experimental.

Rules can create noise when they restate broad preferences, contain exceptions nobody can test, or ask the reviewer to enforce an entire style guide. Remove a rule that repeatedly yields low-value comments. Add rules for concrete defects you can explain and reproduce.

This keeps the context file useful for humans as well as the bot.

Use Manual Review to Learn the Cost

Manual review is a sensible starting point because it makes each review run an intentional decision. Comment bugbot run on a pull request after the implementation and tests are ready for inspection. Add verbose=true if troubleshooting is needed; Cursor documents verbose triggers for detailed logs and a request identifier.

These manual-trigger details were checked on July 28, 2026.

Cursor announced on May 11, 2026 that BugBot is moving from a US$40 per-seat monthly subscription to usage-based billing for Teams and Individuals. Teams bill from on-demand spend and Individuals use included usage. Cursor estimates an average run at US$1.00 to US$1.50, with cost varying by pull-request size and complexity.

That estimate is a vendor average, not a budget guarantee. Use the hub's shared pilot, then add pull-request size, effort, run cost, and rerun count to BugBot's record. Three runs on one change are three spending events.

Triage a Finding Before You Fix It

BugBot's most useful output is a finding that names a line and an expected failure. Begin from that line, then move outward.

• What input arrives there?
• Which condition permits it?
• Who consumes the result?

A comment becomes actionable when the answers expose a path that violates an existing requirement or a testable expectation.

Do not send every finding directly to an agent or turn every reply into a code change. Some comments reveal a missing test for changed behavior. Some point at a code path protected by a caller the reviewer did not see.

Some identify a future design concern that deserves an issue instead of a merge-blocking patch. The triage decision prevents a focused reviewer from creating a broad, unowned backlog.

1. Reproduce the claimed state from the pull-request diff and surrounding code.
2. Look for existing validation, feature flags, and calling constraints.
3. Write a regression test when the issue is confirmed.
4. Dismiss the comment with the protecting evidence when it is incorrect.
5. Record a deferred concern outside the pull request with a clear owner.

Use this method for a manual pilot and for automatic reviews. It improves the signal visible to the team and stops the tool from becoming a reason to change working code on the basis of a persuasive paragraph. The cost of verification remains part of the tool's cost, so include it in the adoption decision.

Treat Fix Links as a Handoff

Cursor documents Fix in Cursor links that open an issue directly in the editor and Fix in Web links that open the web agent. The handoff can save the context-switch of locating the file and copying the review comment. It does not remove the review step after a change has been proposed.

These documented fix-link details were checked on July 28, 2026.

Use the handoff in a contained loop:

1. Confirm the finding describes a reachable defect.
2. Send the finding to the chosen repair surface.
3. Inspect the proposed diff before accepting any part of it.
4. Add or adjust a test that proves the repaired behavior.
5. Request another review only when the fix changes the relevant path.

This keeps the convenience of an agent handoff without converting a review comment into an automatic code change. It also makes a rejected suggestion cheap: dismiss it with the reason and return to the pull request instead of opening an unnecessary repair task.

BugBot Pricing and Effort

Cursor's May update also introduced effort levels. The vendor says customers can choose deeper review effort or set custom logic that selects effort dynamically. It reports that high effort found 35% more bugs in its internal runs while its reported resolution rate remained 80%.

Those figures are Cursor's internal measurements, checked July 28, 2026.

Cursor's May 2026 announcement describes the billing transition. Verify the live dashboard for your current account terms.

Billing State	Published Price	Budget Effect
Old subscription	$40/seat/month	Persists until transition date
Teams usage billing	On-demand spend	Each run draws from team spend
Individuals usage billing	Included usage	Competes with other Cursor use
Average run	$1.00-$1.50 per run	Varies with PR size and effort

Use higher effort after your pilot shows that the lower setting misses a costly code path. An authentication migration deserves more inspection than a label change. Base the policy on risk and evidence, with a spend ceiling visible to the person who enables it.

Set a Spend Policy Before Auto-Review

Usage billing makes every trigger a spending decision. Write the default policy before enabling automatic review:

• Auto-review behavior changes in the application paths with the highest failure cost.
• Use manual comments for migrations, security-sensitive work, and release exceptions.
• Exclude documentation-only changes, generated artifacts, and mechanical formatting.
• Set a monthly cap that preserves budget for the team's other Cursor work.

Assign one owner to review the monthly record and authorize exceptions. That record should include runs, approximate cost, effort, confirmed findings, and recurring noise.

• Check which accounts still carry the old seat subscription and when each one moves to usage billing.
• Review emergency runs beside routine spend so exceptions do not become an invisible default.
• Keep tests, static analysis, and human approval running after the BugBot cap is exhausted.

Cursor says existing customers move at their first renewal after June 8, 2026 unless they switch early. Fit the cap to the live dashboard, then revisit it after representative pull requests expose the real rerun pattern.

Translate the monthly cap into a run allowance that the team can understand before a pull request opens. Cursor's US$1.00 to US$1.50 estimate gives a planning range, but the live dashboard must settle the actual charge for each repository and effort level.

• Reserve a base number of manual runs for migrations, authentication, and data-boundary changes.
• Keep a smaller exception pool for reruns after a confirmed repair.
• Stop automatic review when the remaining allowance would consume the team's wider Cursor budget.
• Require the owner to record why an override was worth another paid pass.

Review the allowance against merged work, not review volume alone. A month with many BugBot runs and no confirmed findings may show excellent code, weak test selection, or low-signal automation. Sample the pull requests and decide which explanation the record supports.

The billing transition also creates an account-level check. Compare the old US$40 seat charge with the first full month of usage billing for the same active reviewers. Include reruns, high-effort requests, and the Cursor work displaced by the review spend.

Keep the review mode reversible while those numbers settle. Mention-only mode protects the budget when pull-request traffic spikes, and one-run-per-pull-request limits repeated charges on branches with frequent updates. Automatic review should return only where the observed signal justifies the observed spend.

If one repository consumes an unexpected share, inspect its pull-request size, update frequency, effort selection, and automatic trigger before raising the cap. The cause should be visible before the budget changes.

Audit the trigger history when a bill moves without an obvious rise in merged work. Separate automatic reviews caused by new pushes from manual requests made during triage, then identify whether repeated runs came before or after meaningful code changes.

The trigger distinction changes the remedy the team needs. Noisy automatic reruns call for a stricter repository mode, while repeated manual runs may show that findings are being handed back before repairs are complete. Neither problem is solved by raising the monthly cap.

Keep one pull request as a cost-control test case. Update it with a documentation-only commit, a small application fix, and a confirmed repair, then observe which settings trigger another charge. Recheck that case after Cursor changes BugBot's billing or effort controls.

Limits Worth Checking Before Rollout

BugBot's official setup documentation is built around GitHub organization installation. Confirm your provider, permissions, repository enablement, author settings, and billing mode before promising that every pull request receives a review. Product documentation can lag a billing change, as the current BugBot documentation still includes older flat-rate wording alongside the May transition announcement.

Keep the operating model small enough to remain accountable. A human reviewer owns the merge decision. Tests and static checks remain separate gates.

BugBot supplies a focused review pass, and its value depends on the team proving which comments led to prevented defects. For a broader configuration surface, read the CodeRabbit guide. For another codebase-context approach, read the Greptile guide.

A Focused BugBot Verdict

BugBot is the focused Cursor-native choice for a team that can meter every review run. Put it on risky application paths, keep BUGBOT.md rules tied to reachable defects, and cap automatic spend in the live billing model. Broader review coverage belongs elsewhere when BugBot's per-run economics discourage routine passes.

BugBot FAQ

Is BugBot included with Cursor?

BugBot is a Cursor product, yet its billing is moving away from a simple flat review-seat subscription. Cursor says Teams bill from on-demand spend and Individuals use included usage. Check the current Cursor dashboard for the terms attached to your account.

Can I run BugBot manually?

Yes, Cursor documents manual pull-request triggers using cursor review, bugbot run, or cursor run. Manual runs are useful while measuring signal, cost, and the effect of repository rules because the team chooses which changes receive another automated pass.

Where do BugBot rules go?

Put project guidance in .cursor/BUGBOT.md. Cursor says BugBot includes the root file and more-specific BUGBOT.md files found while traversing upward from changed files. Keep each rule short, testable, and tied to a known project risk; these details were checked on July 28, 2026.

Does BugBot review every pull request?

It can run automatically on pull-request updates, and Cursor also documents settings for mention-only runs and one run per pull request. The enabled repository and account settings decide the result, so verify them in the current dashboard before relying on coverage.

Keep Reading

• AI code review hub
• CodeRabbit guide
• Greptile guide
• CodeRabbit vs BugBot