Cursor Bugbot Effort Levels: Low, Default, High, and Smart (Usage-Based Billing Required)

Cursor Bugbot, the company's automated PR review agent, offers four effort levels as of October 9, 2026: Low, Default, High, and Smart (Cursor Bugbot docs). Cursor introduced effort control in its May 11, 2026 changelog with three modes, Default, High, and Custom, trading review latency and spend for additional bugs caught. Effort control requires the workspace to be on usage-based billing -- and on the same day, Cursor announced that usage-based billing is where every Teams and Individual Bugbot customer was headed anyway.

Key Takeaways

• Four levels today. Low (cheaper, quality close to Default), Default (efficiency and speed), High (more reasoning, more bugs, slower and pricier), and Smart (natural-language rules pick Low, Default, or High per review).
• Three at launch. The May 11 release shipped Default, High, and Custom; Custom's natural-language rules chose between Default and High only.
• Effort control is gated on usage-based billing. Cursor's docs: effort levels are "available only for usage-based Bugbot plans."
• The gate was not optional. The same-day blog post moved every Teams and Individual Bugbot customer to usage-based billing at their first renewal after June 8, 2026, removing the $40 per seat per month fee.
• What a review costs. Cursor put the average Bugbot run at $1.00 to $1.50, depending on PR size and complexity.
• Yield numbers, on the record. At launch Cursor reported 0.7 bugs per run at Default with over 79% resolved at merge, and 0.95 per run at High -- a 35% lift by Cursor's own framing, with the resolution rate holding at 80%.
• Where to set it. Settings in Bugbot Automations for the workspace, or per repository in .cursor/config/bugbot.yaml.

Effort Levels Today

Cursor's Bugbot docs, read October 9, 2026, describe four levels:

Smart does the job Custom did at launch, with Low added as a third option it can route to. We found no Cursor yield figures for Low or Smart.

What Launched on May 11, 2026

Bugbot's review behavior used to be a single fixed configuration. The May 11 update split it into three explicit modes; Low and Smart came later.

All three quotes are verbatim from the Cursor changelog entry dated May 11, 2026.

The Billing Change Behind the Gate

The changelog gives the requirement in one line and links out for the rest. The rest is the more consequential half of the announcement. Cursor's blog post the same day:

Bugbot is switching from a $40 per seat per month subscription to usage-based billing for Teams and Individual plans. For existing customers, this change will start at your next billing renewal after June 8th, 2026.

Four specifics worth having:

1. The seat fee is gone. Cursor described the move as "removing seat fees for Bugbot and transitioning to purely usage-based billing."
2. What a run costs. "The average Bugbot run costs $1.00-$1.50, depending on PR size and complexity."
3. The cutover date is per-customer, not global. It lands at your first renewal after June 8, 2026. Cursor's help page gives the worked examples: a cycle starting May 1, 2026 does not change on June 1, it changes on July 1; an annual subscription bought in May 2026 changes at its May 2027 renewal.
4. Teams and Individual bill differently. For Teams, Bugbot reviews are charged from on-demand usage. For Individual plans, Bugbot bills from included usage first, then from on-demand usage if you have enabled it. If on-demand usage is disabled, Bugbot pauses until the next billing cycle resets your limits.

Customers who wanted the effort controls before their renewal could switch early from the Cursor dashboard, with pro-rated credits applied for pre-paid seat fees.

The transition is complete in the documentation: Cursor's Bugbot reference opens its pricing section with "Bugbot uses usage-based billing" and routes anyone still on the old plan to a separate legacy pricing page.

Why the Billing Gate Matters

The practical reading changed once the migration was in view. Effort levels are not a paid add-on you can decline by staying on a flat seat plan, because the flat seat plan was withdrawn. They are a feature of the billing model everyone landed on.

What the gate does still determine is when you get the controls: at your renewal, or earlier if you switch by hand. And it changes what an expensive review costs you directly rather than through a seat count. On usage-based billing a High-effort review draws more spend from the same pool as everything else, so Smart (Custom at launch) is the level that matters most in practice -- a team can write a rule like "use High effort on changes to auth/ or migration files, Default everywhere else" and pay the premium only on the small fraction of reviews that warrant it.

The weekly AI Catchup

Get the week's AI coding news, distilled.

One email each week: the tools, releases, and workflows that matter for Claude Code, Codex, Cursor, and the agent stack.

Subscribe

How to Choose an Effort Level

Use this decision rule:

• Pick Low if Bugbot runs on a high volume of routine PRs and cost matters more than the last few findings. Cursor says its quality is close to Default, and that Low reviews are cheaper but take longer.
• Pick Default if Bugbot is a second opinion alongside human review and you want a fast, inexpensive review. At launch Cursor put Default at 0.7 bugs per run with over 79% resolved at merge.
• Pick High if you have a payments, infrastructure, or security-sensitive surface where the extra ~0.25 bugs per run (0.95 versus 0.7) earns back the cost in one prevented incident. Expect longer turnaround and more spend on every PR.
• Pick Smart if your codebase has a mix of risk profiles -- some directories that justify High, others where Default is plenty. This is the mode that makes the usage-based model work in your favour rather than against it, because you buy the deeper review only where it pays.

Where to Set the Effort Level

As of October 9, 2026, there are two places:

• Bugbot Automations. Effort is set from Settings in Bugbot Automations, which is also where team rules, analytics, and the incremental-review toggle live. The May changelog pointed at the Bugbot dashboard; the control has since moved here.
• A repository config file. Bugbot reads .cursor/config/bugbot.yaml from the PR's base branch. Under review, effort takes low, default, high, or smart, and smartPrompt holds the natural-language instructions for Smart. The file must be committed, applies only to that repo, and a PR cannot change how Bugbot reviews itself (Cursor Bugbot docs).

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. Cursor's own framing of the gap between Default and High is a 35% lift in bugs found, with the resolution rate holding constant at 80%, and Smart lets you concentrate that lift on the code that warrants it. If Bugbot has been a low-volume check in your workflow, the change is mostly a billing one, and it happened on Cursor's schedule rather than yours.

The numbers Cursor published are aggregates across its customer base, not a benchmark of your repository. Your own ratio will depend on language, repo size, and how aggressively your team merges Bugbot suggestions.

Treat the 0.7 and 0.95 figures as a May 2026 snapshot rather than current performance. Cursor's June 10, 2026 changelog reports that Bugbot "finds 10% more bugs per review on average" at 0.62, up from 0.56, after Composer 2.5 took over the review, along with reviews running about 3x faster and costing roughly 22% less per run. Cursor has not published a refreshed High-effort figure alongside it. We covered that update in Cursor Bugbot gets faster and cheaper.

Workflows Worth Setting Up

• Migration / schema-change PRs: Smart rule that routes anything touching migrations/ or schema/ to High effort. These are the PRs where a missed bug costs the most.
• Dependency bumps: Low or 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. Speed beats thoroughness when the build is on fire.

Corrections and Updates

• October 9, 2026: This page listed three effort levels (Default, High, Custom) set only at the workspace level; Cursor's docs now list Low, Default, High, and Smart, and a repo can set effort in .cursor/config/bugbot.yaml.
• August 29, 2026 (update): Cursor's docs now say effort levels are "available only for usage-based Bugbot plans," seat-based pricing moved to a legacy page, and the effort control moved to Settings in Bugbot Automations.
• August 29, 2026 (correction): This page called the usage-based billing requirement an opt-in gate and said "there is no forced migration"; Cursor's May 11, 2026 blog post moved all Teams and Individual plans to usage-based billing at the first renewal after June 8, 2026.

Sources

• Cursor changelog, "Bugbot Effort Levels" (May 11, 2026), re-verified 2026-08-29: https://cursor.com/changelog/05-11-26
• Cursor blog, "Updates to Bugbot for Teams and Individuals" (May 11, 2026), read 2026-08-29: https://cursor.com/blog/may-2026-bugbot-changes
• Cursor help, "Bugbot usage-based billing", read 2026-08-29: https://cursor.com/help/account-and-billing/bugbot-usage-based-billing
• Cursor docs, "Bugbot" (Effort Levels, Repository config file, and Pricing sections), read 2026-10-09: https://cursor.com/docs/bugbot
• Cursor docs, "Legacy Bugbot pricing", read 2026-08-29: https://cursor.com/docs/bugbot/legacy-pricing
• Cursor changelog, "Bugbot is now over 3x faster, 22% cheaper, and finds 10% more bugs" (June 10, 2026), read 2026-08-29: https://cursor.com/changelog/bugbot-updates-june-2026

Provenance note, re-verified 2026-08-05: this page previously cited the changelog index (cursor.com/changelog), which lists only the most recent entries, so the May 11 entry had scrolled off it and the citation no longer resolved to the claims made here. The version-anchored URL above was checked that run and again on 2026-08-29, and confirms the load-bearing claims word for word: the three configurations, "Customers must be on usage-based billing for Bugbot to customize effort levels", "With default effort, Bugbot finds 0.7 bugs per run, on average. Over 79% of these bugs are resolved by users at merge time", and "With high effort, Bugbot finds 0.95 bugs per run, on average."