Cursor Bugbot Reviews in 90 Seconds: The June Update

Cursor Bugbot now reviews code in about 90 seconds. On June 10, 2026, Cursor shipped an update that — by the company's own measurements — cut Bugbot's average review time from roughly five minutes to around 90 seconds, while finding 10% more bugs per run at a 22% lower cost per run. For teams already leaning on AI code review, the change moves the tool from "nice async check" to "fast enough to run before every push."

Speed is the headline, but the more interesting shift is where the review happens. The same release window introduced a /review command that runs Bugbot before you open a pull request, syncing with GitHub and GitLab so it does not double-charge you to re-review an identical diff. That reframes Bugbot from a PR-stage reviewer into a pre-push gate — the point in the workflow where catching a bug is cheapest.

This guide covers exactly what the June update ships, the Composer 2.5 model that now powers Bugbot, the cost-per-bug-caught math for a lean agency team, where each review stage fits in the pipeline, and the due-diligence caveats every figure below carries. Every number is sourced from Cursor's changelog and blog posts and is vendor-stated unless noted otherwise.

The June 10, 2026 Bugbot update — published by Cursor team members Jason Smale, Yuri Volkov, and Michael Zhao — bundles three changes that reinforce one another. Reviews got dramatically faster, each run got cheaper and slightly more thorough, and a new command lets you trigger a review before a pull request even exists.

Two smaller-but-useful capabilities round out the release. Bugbot can now be configured to review only the changes since its previous run, keeping feedback focused on the latest delta instead of re-scanning the whole changeset. And the duplicate-diff detection tied to GitHub and GitLab sync means a diff reviewed locally with /review is not re-billed when the matching PR opens.

A five-minute review is something you wait for; a 90-second review is something you run reflexively. That is the practical meaning of Cursor's vendor-stated "over 3x faster" claim. When a check costs you 90 seconds and 90% of runs finish in under three minutes, it stops being a deliberate decision and becomes part of muscle memory — the same way a fast test suite gets run far more often than a slow one.

The downstream effect is a behavior change, not just a time saving. Industry data on AI-assisted review points in the same direction: an analysis of the state of AI code review in 2026 reports that 47% of professional developers used AI-assisted code review in 2025, and that repositories using it showed roughly 32% faster merge times and 28% fewer post-merge defects versus human-only review (attributed to Stack Overflow and GitHub 2025 data respectively). The faster the tool, the more often it runs, and the earlier defects surface.

In Cursor's words, the gains are made possible by progress training Composer 2.5, which now powers Bugbot. Composer 2.5 launched on May 18, 2026 and, per Cursor, was trained on 25x more synthetic tasks than the prior Composer. We covered the launch in depth in our Composer 2.5 agent-coding launch analysis; the short version is that it is the model that now sits behind both Cursor's agent and Bugbot.

Two facts matter when you read the benchmark numbers. First, Composer 2.5 is exclusive to the Cursor IDE — it is not available through public APIs, Amazon Bedrock, Google Vertex, or OpenRouter, so you cannot wire it into your own pipeline outside Cursor. Second, its headline CursorBench score is a vendor-controlled benchmark: CursorBench is Cursor's own eval, not an independent one.

The picture is nuanced rather than triumphant, and that is the point. On Cursor's own benchmark Composer 2.5 edges ahead of Opus 4.7; on the more independent SWE-Bench Multilingual it sits just behind; and on Terminal-Bench 2.0 the two are essentially tied. What is not in dispute is the cost trajectory — a substantially cheaper model underneath is precisely what lets a more thorough review also be a cheaper one. For a fuller treatment of why vendor-controlled scores deserve a second look, see our analysis of the vendor-controlled CursorBench methodology.

Most coverage treats Bugbot as a pull-request tool. The /review command, introduced with Cursor 3.7 on June 5, 2026, reframes it as a pre-commit gate. You run it locally before pushing; it executes Bugbot and Security Review and prompts you to select an agent. The dedicated shortcuts /review-bugbot and /review-security target one or the other directly. It is available inside Cursor 3.7+ and on cursor.com/agents, with CLI support stated as coming soon — so it is not yet a CLI command you can drop into a shell script.

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

Here is the calculation most Bugbot coverage skips. Cursor states an average run costs $1.00-$1.50 depending on PR size (a 500-line PR runs around $1.20; a 5,000-line PR can exceed $4), and that default-effort runs find 0.62 bugs on average. Dividing a run cost by bugs found gives an effective cost per caught bug in the rough range of $1.60-$2.40 at default effort. The numbers below are illustrative arithmetic from those vendor-stated inputs, not a Cursor-published table — actual figures vary with PR size and effort level.

Read the asterisk carefully. The 0.62 default figure is from the June 10 changelog (post-Composer 2.5). The 0.95 high-effort figure comes from a different post — the May 11, 2026 effort-levels changelog — which used its own test set and reported a different default baseline (0.7 bugs per run) in that context. Those two default baselines, 0.62 and 0.7, are not the same measurement and should not be read as a before-and-after trend. We keep them in separate columns deliberately.

Even at the conservative end, the economics are not close. Treat the widely cited cost of a single production incident as a four-to five-figure number — analyst write-ups on AI review put avoided cost per prevented production incident in the $5,000-$15,000 range, and most teams recoup their investment within the first quarter. Against that, a couple of dollars per caught bug at default effort is a rounding error. The decision is no longer whether the ROI clears; it is which PRs deserve the more expensive high-effort pass.

Cursor's documentation frames pre-push review, PR-opened review, and CI-stage review as separate features. In practice they form a decision matrix: each stage catches a different class of problem and suits a different kind of change. The faster pre-push review does not replace PR-level analysis — it front-loads the cheap catches so the PR review can focus on cross-file regressions.

If you are deciding when AI code review belongs in your workflow at all, our guide to where AI code review fits into your workflow walks through the trade-offs, and the Vercel Agent tutorial covers a CI-stage AI code review setup that pairs naturally with Bugbot's earlier stages.

Bugbot's effort levels shipped earlier, on May 11, 2026, and are worth understanding in their own right — but their figures live in their own context. In that May post, Cursor reported a Default level finding 0.7 bugs per run at a 79% resolution rate, a High level at 0.95 bugs per run (about 36% more than Default, but more expensive and slower), and a Custom level that routes effort via natural-language rules. Cursor noted it uses high effort for changes to its own infrastructure and backend.

A deliberate note on the numbers. The 0.7 default-effort figure here and the 0.62 default figure from the June 10 speed update are not the same metric — they come from different posts using different test sets or measurement periods. Use 0.62 when discussing the June 10 speed update, and 0.7 only inside this May effort-levels context. Cursor’s internal measurement methodology is not fully transparent, so resist the temptation to chart them as a single trend line.

None of this is a reason to dismiss Bugbot — it is a reason to read the numbers correctly. Every speed, cost, and bug-count figure in this post is vendor-stated by Cursor. CursorBench is Cursor's own benchmark; on the more independent SWE-Bench Multilingual, Composer 2.5 sits just behind Claude Opus 4.7 rather than ahead. And on the broader point of transparency, Cursor co-founder Aman Sanger publicly acknowledged it was a miss not to disclose the Moonshot AI Kimi K2.5 base when the earlier Composer version launched. That candor is itself reassuring, but it is also a reminder to verify vendor claims against your own runs.

Developer sentiment is mixed in the honest way you would expect. Some report that Bugbot misses issues other tools catch; others say the new Composer made them a returning subscriber. The signal for a buyer is not to pick a side from forum threads but to run a short internal trial: turn on /review-bugbot across a sprint, log what it catches and misses against your actual review process, and decide from your data rather than the changelog.

Balance that against the other side of the same conversation. Whatever the headline benchmarks claim, the experience that matters is the one your team has on your repos — which is why we always recommend a short, logged trial before changing a default.

For a boutique team running Cursor across two or three active projects with tight sprint cycles, the value of sub-two-minute pre-push review is higher than waiting for CI to flag issues. The workflow we would set as the default is simple: always run /review-bugbot pre-push on feature branches as a cheap async gate; rely on GitHub Bugbot for PR-level analysis that catches cross-file regressions; and reserve high effort for the infrastructure, billing, and auth PRs where the extra cost is obviously justified.

Looking forward, the trajectory is clear: as more of a codebase is written by agents, the review stage becomes the load-bearing quality control, and the cheapest place to run it is before the push. A 90-second gate that costs a couple of dollars and reliably surfaces roughly two-thirds of a bug per run is the kind of small, compounding discipline that separates teams who ship agent-written code safely from those who clean it up in production. Pairing that gate with senior human judgment on the diffs is exactly how we run agentic web development engagements — and the same approach extends to our broader AI transformation work.

For the wider context on how Cursor, Claude Code, and Codex have shifted through the first half of the year, our H1 2026 AI coding retrospective and the Cursor 3.7 release that introduced Design Mode and voice input put this Bugbot update in its release-cycle frame.