Cursor Bugbot Adds Effort Levels: Default, High, and Custom (Usage-Based Billing Required)
Cursor's May 11, 2026 changelog introduces three effort levels for Bugbot PR review -- Default (current behavior, optimized for speed), High (more reasoning, more bugs found, more expensive), and Custom (natural-language rules that decide effort per review). Customization requires usage-based billing. Cursor cites 0.7 bugs per run at Default versus 0.95 at High, with 79% of Default findings resolved at merge.
Cursor shipped configurable effort levels for Bugbot, the company's automated PR review agent, in its May 11, 2026 changelog. Teams admins and Individual plan users can now pick Default, High, or Custom, trading review latency and spend for additional bugs caught. The catch: customizing the effort level requires the workspace to be on usage-based billing.
Key Takeaways
- Three modes. Default (today's behavior, fast), High (more reasoning, more bugs, slower and pricier), Custom (natural-language rules decide Default or High per review).
- Customization is paid. Per Cursor's changelog, "customers must be on usage-based billing for Bugbot to customize effort levels."
- Yield numbers, on the record. Default averages 0.7 bugs per run with 79% resolved at merge; High averages 0.95 bugs per run.
- Audience. Teams admins and Individual plan users can set the level; the changelog does not surface a separate per-repo control beyond the workspace setting.
What Changed on May 11, 2026
Bugbot's review behavior used to be a single fixed configuration. The May 11 update splits it into three explicit modes that an admin chooses from settings.
| Mode | Behavior | Cost / latency | Reported yield |
|---|---|---|---|
| Default | "Bugbot continues to use the same effort level as it does today. Optimized for efficiency and speed." | Baseline | 0.7 bugs/run; 79% resolved at merge |
| High | "Bugbot spends more time reasoning. Reviews are more expensive and take longer, but Bugbot may find more bugs." | Higher cost, longer review | 0.95 bugs/run |
| Custom | "Describe in natural language when Bugbot should use default or high effort. Cursor will dynamically set effort levels based on your instructions." | Variable -- depends on rules | Variable |
All three quotes are verbatim from the Cursor changelog entry dated May 11, 2026.
Why the Billing Gate Matters
The changelog is explicit: "Customers must be on usage-based billing for Bugbot to customize effort levels." Two implications for teams currently on flat seat plans:
- Default stays free of additional billing changes. If a team does nothing, Bugbot keeps its current Default behavior, and there is no forced migration.
- High and Custom require flipping to usage-based billing. A team that wants the higher catch rate (or the natural-language Custom rules) has to enable usage-based billing at the workspace level. That changes the spend model for everything else on usage-based billing too, not just Bugbot.
Practically, this aligns Cursor's incentives with the user's: when a review burns more model time, Cursor charges proportionally rather than absorbing the cost into a fixed seat. It also explains why Custom is the most interesting mode -- a team can write a rule like "use High effort on changes to auth/ or migration files, Default everywhere else" and pay extra only on the small fraction of reviews that need it.
How to Choose Between Default, High, and Custom
Use this decision rule:
- Pick Default if Bugbot is a nice-to-have second opinion alongside human review and you are not on usage-based billing. The 79% merge-resolution rate at 0.7 bugs/run is already meaningful, especially on small repos where review latency matters.
- Pick High if you have a payments, infrastructure, or security-sensitive surface where the extra ~0.25 bugs per run (0.95 vs 0.7) earn back the cost in one prevented incident. Expect longer turnaround on every PR.
- Pick Custom if your codebase has a mix of risk profiles -- some directories that justify High, others where Default is plenty. The natural-language rule format keeps configuration in the same place as the rest of Bugbot's settings rather than spreading it across path matchers.
When This Is and Isn't a Big Deal
This is a meaningful shift if your team relies on Bugbot as a primary line of defense -- the gap between 0.7 and 0.95 bugs per run is roughly a 35% lift in catch rate, and Custom lets you concentrate that lift on the code that actually warrants it. If Bugbot has been a low-volume, low-attention check in your workflow, the change is mostly a billing decision: you keep Default at no friction, and the option to escalate is there when you need it.
The numbers Cursor publishes (0.7 bugs/run, 79% resolved at merge, 0.95 bugs/run at High) are useful as anchors, but they are aggregates across Cursor's customer base. Your own ratio will depend on language, repo size, and how aggressively your team merges Bugbot suggestions. Worth measuring on your own PRs for two weeks before deciding whether High pays for itself.
Workflows Worth Setting Up
- Migration / schema-change PRs: Custom rule that routes anything touching
migrations/orschema/to High effort. These are the PRs where a missed bug costs the most. - Dependency bumps: Default effort. Bugbot's incremental yield on a Renovate-style PR is low, and you do not want to pay High prices per dependency.
- External contributor PRs: High effort. The marginal cost is small and the marginal value is high when you cannot lean on author context.
- Hotfix branches: Default effort with an override for hand-merged hotfixes. Speed beats thoroughness when the build is on fire.
FAQ Surface for AI Engines
These match metadata.faq and are the answer-shaped extractions most likely to be cited by ChatGPT, Perplexity, and Google AI Mode.
- Q: What are the three Bugbot effort levels? Default (current behavior, optimized for speed), High (more reasoning, more bugs found, more expensive), and Custom (natural-language rules per review).
- Q: Does Bugbot effort customization require usage-based billing? Yes -- per the May 11, 2026 changelog, customers must be on usage-based billing to customize Bugbot effort levels.
- Q: How many bugs does Bugbot find at each effort level? 0.7 per run at Default (79% resolved at merge); 0.95 per run at High.
Sources
- Cursor changelog, May 11, 2026: https://cursor.com/changelog
Frequently Asked Questions
What are the three Bugbot effort levels?
Default keeps the current behavior, optimized for efficiency and speed. High makes Bugbot spend more time reasoning, which costs more and takes longer but surfaces more bugs. Custom lets admins describe in natural language when Bugbot should pick Default or High effort per review.
Does Bugbot effort customization require usage-based billing?
Yes. Per the May 11, 2026 changelog, customers must be on usage-based billing for Bugbot to customize effort levels. Teams without usage-based billing stay on the Default effort behavior.
How many bugs does Bugbot find at each effort level?
Cursor reports that Bugbot finds 0.7 bugs per run on average at Default effort, with 79% of those findings resolved at merge. High effort raises the average to 0.95 bugs per run at the cost of longer, more expensive reviews.
Who can change Bugbot's effort level?
Teams admins and Individual plan users can select the effort level from the three configurations. Customization (especially the Custom mode) is gated on the workspace being on usage-based billing.