Cursor Bugbot Drops to 90 Seconds With Pre-Push Review Command

Cursor updated Bugbot on June 10 to run in roughly 90 seconds on average, down from about five minutes. The upgrade, powered by Composer 2.5, also reduces cost per run by 22 percent and improves the bug-finding rate by 10 percent. At 90 seconds, Bugbot crosses from background job to interactive pre-push check, and the new /review command makes that workflow practical inside Cursor 3.7 and above.

What exactly changed in Bugbot on June 10

The June 10 update delivers three measurable changes: speed, cost, and accuracy. Average review time dropped from roughly five minutes to roughly 90 seconds, with 90 percent of runs completing in under three minutes even on larger diffs. Cost per run fell by 22 percent. The bug-finding rate per default run improved from 0.56 to 0.62 bugs identified per review, a 10 percent gain.

All three improvements come from the same source: Cursor replaced Bugbot's underlying model with Composer 2.5, the same model powering the Cursor composer panel. Composer 2.5, which shipped on May 18, 2026, was trained on 25 times more synthetic tasks than its predecessor. Cursor's announcement notes that the speed and quality gains in Bugbot are a direct consequence of the harness improvements and training work that went into Composer 2.5 rather than separate Bugbot-specific engineering.

The resolution rate tells the longer-term story. When Bugbot launched out of beta in July 2025, 52 percent of the bugs it identified were resolved before the relevant pull request was merged. That figure now sits at around 80 percent, according to Cursor, which places it 15 percentage points ahead of the next-closest AI code review product. Over eleven months, the team ran 40 major experiments that collectively moved the needle on both quantity and quality of findings.

The self-improving feedback loop that Cursor launched in April 2026 continues running in the background. More than 110,000 repositories have enabled Bugbot learning, generating over 44,000 learned rules. These rules come from three signals: downvotes on Bugbot comments, replies from engineers explaining why a finding was not useful, and comments from human reviewers flagging issues that Bugbot missed. Bugbot processes these signals into candidate rules and evaluates them against incoming pull requests before promoting them to active status.

Why does 90 seconds change your review workflow

The speed difference is not just a convenience improvement. It changes where in the development loop you can reasonably insert a code review step.

At five minutes, Bugbot fit best as a post-push async check. You open a pull request, Bugbot runs while you context-switch to something else, and you come back to its findings when the PR is ready for human review. That timing works for a pull request workflow, where the delay is invisible against the larger review cycle. It does not work for a pre-push gate, because asking a developer to wait five minutes before every push is a context-switching cost most teams would quietly disable within a week.

At 90 seconds, the math changes. Ninety seconds is closer to the time you spend running a test suite on a small to medium change. It is a pause that is uncomfortable enough to feel intentional, short enough to complete before context fully shifts. Teams that already run linters and type checkers as pre-push hooks operate in this time range. Bugbot at 90 seconds is now comparable to a thorough lint run, and it catches a meaningfully different category of problem: logic bugs, edge cases, and error-handling gaps that static analysis cannot reach.

How does the /review command work

The /review command landed in Cursor 3.7 on June 5, 2026, and becomes practically useful now that the underlying reviews complete in 90 seconds rather than five minutes.

Typing /review in the Cursor chat panel prompts you to choose which agents to run: Bugbot, Security Review, or both. The shortcut commands /review-bugbot and /review-security skip the selection prompt and launch the chosen agent directly against your current local diff. Both are available in Cursor 3.7 and on cursor.com/agents. Cursor has noted that CLI support is coming but not yet shipped, so headless or scripted workflows will need to wait for that addition.

The deduplication logic is what makes the pre-push habit economical for teams that also run Bugbot on pull requests. If you run /review locally and then open a pull request with the same diff, Bugbot recognizes the duplication and skips the PR review. It posts a comment on the PR noting that it has already reviewed that diff. You get the early signal without paying twice for the same review pass.

Security Review runs separately from Bugbot and focuses on a different class of problem. Bugbot identifies logic bugs, edge cases, and error-handling gaps. Security Review specifically checks for vulnerability classes: injection, insecure deserialization, exposed credentials, and unsafe HTTP patterns. Running both with /review takes roughly two to three minutes total, which is still well within interactive range for a pre-push check on changes that touch authentication, payments, or user-generated content.

One constraint worth knowing: the /review command runs on your current diff as seen from Cursor's working tree. If you have staged some changes but not others, Bugbot sees the full working-tree diff, not just the staged portion. Plan your /review runs to reflect the actual state you intend to push.

What does the resolution rate tell us about Bugbot quality

Resolution rate is the most meaningful quality metric for an automated review tool. It measures how often the bugs Bugbot flags are actually addressed before the pull request merges. A tool that flags phantom issues or flags real issues that reviewers decide are not worth addressing will have a low resolution rate regardless of how many things it flags.

The 52 percent rate at launch was already reasonably good for an automated reviewer. The current 80 percent means four in five findings from Bugbot are real enough that the developer or reviewer chooses to fix them before merging. The 15-point lead over the next-closest product, if the Cursor numbers are accurate, suggests that the combination of Composer 2.5, learned rules, and sustained experimentation has produced a notably better signal-to-noise ratio than alternatives.

The self-improving rules give teams a compounding advantage over time. Teams that actively downvote unhelpful findings and leave explanatory replies are teaching Bugbot what is irrelevant in their codebase. A team that has been running Bugbot for six months with active feedback should see a more targeted set of findings than a team that just enabled it with defaults. The 110,000 repositories with learning active suggest the feedback signal Cursor is working with is substantial.

How should vibecoders use Bugbot in their daily workflow

The practical starting point is enabling Bugbot on pull requests if you have not already. The quality improvement from June 10 makes it more worthwhile even on solo projects where you are the only reviewer. At 90 seconds and a meaningfully higher resolution rate, the cost-to-signal ratio has improved enough that it earns a place in most non-trivial shipping workflows.

For teams on Cursor: add /review-bugbot to the steps you run before opening a pull request, alongside your existing lint and type-check commands. The deduplication logic means you are not paying twice when the PR also runs Bugbot. You get an earlier signal and the PR Bugbot run gets skipped automatically, keeping the PR timeline clean.

For solo vibecoders building quickly: the 90-second speed makes it practical to use /review as a final check before pushing changes that touch anything consequential. The categories Bugbot catches well are exactly the ones that tend to cause bugs in fast-moving solo projects: edge cases in error handling, missing null checks, subtle logic inversions, and insecure handling of user input. These are the bugs that seem fine in a quick read-through and surface at the worst moment in production.

Running Security Review alongside Bugbot adds one to two minutes but provides a different class of coverage. For projects that handle authentication, payments, or user-generated content, the combined /review run before any push to a production branch is a low-overhead safeguard against the vulnerability classes most likely to create serious incidents.

The full announcement from Cursor includes additional detail on the Composer 2.5 integration and the performance improvement methodology.