If you’ve used Bugbot, you know the pattern: you open a PR, you wait, you go make a coffee, you come back, you read the comments. The review worked, but the wait was real — about five minutes per run. On June 10th Cursor released an update that practically kills the wait, and the why behind it is more interesting than the numbers themselves.
The headline: Bugbot’s average review time dropped from ~5 minutes to ~90 seconds. Plus it finds around 10% more bugs per review (0.62 vs 0.56 on average), and costs ~22% less per run. These are Cursor’s own numbers — self-reported by the vendor, without independent validation — so read them as direction, not gospel. But the direction is steep.
What actually changed
The gains come from Composer 2.5, Cursor’s own model, which now powers Bugbot. That’s the part to pause on — we’ll come back to it.
On a practical level, there’s a new way to use it. Now you can run a review before you push, straight from your agent:
/review— asks you which agents to run (Bugbot, Security Review, or both)/review-bugbot— runs Bugbot directly/review-security— runs the Security Review agent directly
And the detail that saves you from wasted work: /review syncs with Bugbot on GitHub and GitLab. If you run it locally and then open a PR with the same diff, Bugbot recognizes it, skips the re-review, and leaves a comment letting you know it already reviewed that diff. You don’t pay twice, you don’t read the same comments twice.
There’s also a new config to review only what’s new since the last review, so feedback stays focused on your latest changes instead of re-litigating the entire branch.
All of this is in Cursor 3.7+ and at cursor.com/agents. CLI support is on the way but hasn’t arrived yet.
Why pre-push changes the math
Here’s the workflow shift. The old default was: write code → push → open PR → wait for review → fix → push again. Bugbot lived in the PR, which meant the review was a checkpoint after you’d already declared the work “ready enough to share.”
Run /review before the push and the review moves upstream, into the same loop where you’re still actively editing. You catch the silly stuff before it’s public, before your colleague’s notification fires, before the diff is something you have to defend. The sync behavior with the PR means moving it earlier doesn’t cost you anything — you’re not adding a step, you’re relocating one.
A 90-second review is what makes this viable. At five minutes, running the review on every pre-push is friction you’ll skip when deadlines hit. At 90 seconds it’s roughly the cost of re-reading your own diff, which you should be doing anyway.
Where it doesn’t fit
If your team already has a mature, low-volume human review pipeline — small diffs, quick turnaround, reviewers who know the codebase by heart — an automatic pass at pre-push adds more noise than signal. And if your organization blocks proprietary models by data policy, keep in mind that Bugbot respects model block lists, but the headline performance comes specifically from Composer 2.5; block it and the numbers change. This is a tool for teams shipping high volumes of PRs where the bottleneck is reviewer attention, not for the two-person shop reviewing code in real time.
The part for CTOs reading this
Step back from the feature and look at the play. Cursor didn’t make Bugbot 3x faster by tuning prompts against another vendor’s frontier model. They got there by training their own model — Composer 2.5 — and pointing it at a specific, bounded job: code review.
That’s the trend to follow. The first wave of AI dev tools was a thin layer on top of a borrowed frontier model; differentiation was in the UX. What Cursor is signaling here is the next phase: vendors training vertical models tuned for a single task — review, in this case — where they control the cost curve, latency, and quality ceiling instead of renting all three from a frontier lab.
For anyone evaluating tooling spend, that’s the question to start asking every vendor: what I’m paying for, is it a wrapper, or do you own the model underneath the feature I actually use? Because the vendor who owns the model is the one who can deliver a 22% cost cut and 3x speedup in a single changelog entry — and keep doing it.