Cursor Composer 2.5: One Point Behind Opus 4.7. 3 Changes for Users Who Are Staying

[[IMG:hero]]

Yesterday I covered the three Claude Code win reports: JetBrains’ 10,000-developer survey, the CNBC outage story, and Business Insider’s piece. Different metrics, same direction.

At the end of that piece I wrote “there’s no need to ditch Cursor right now.” I laid out three decision axes and showed that sticking with Cursor is a defensible call.

Then I got the same question from multiple readers:

“If I’m staying with Cursor, what should I actually change?”

Good question. Staying isn’t the goal. Staying while changing nothing means you’ll be saying “I should have switched” six months from now. Cursor loyalists especially need to track what’s been moving on Cursor’s end.

I dug in. Cursor’s counterattack has been quiet and fast.

Three announcements in the past two weeks: Composer 2.5, Bugbot effort levels, and a pricing model overhaul. I’ve run all three in production alongside Claude Code for a week. This piece is written for readers who chose to stay.

“If you’ve decided to keep Cursor, what settings do you change next week?” I’ve tried to make those answers as concrete as possible.

What Composer 2.5’s 79.8% Actually Means

The first thing to pay attention to: Composer 2.5 launched on May 18, 2026 — just two months after Composer 2. I’ll admit I initially wrote it off as a minor point release. Running it in production changed that read.

Cursor’s published numbers:

• SWE-Bench Multilingual: 79.8% (up from Composer 2’s 73.7%)
• Terminal-Bench 2.0: 69.3%
• CursorBench v3.1: 63.2%
• Standard pricing: $0.50 input / $2.50 output (per million tokens)
• Fast tier: $3.00 input / $15.00 output

What that means: 79.8% on SWE-Bench Multilingual puts Composer 2.5 within one point of Claude Opus 4.7’s 80%+ range, as TechTimes reported on May 20, 2026. A 6-point jump from 73.7% is not a minor update.

The base model is Moonshot’s Kimi K2.5, per Winbuzzer — an open-source checkpoint. The real differentiation sits in the post-training pipeline: 25x synthetic tasks, text-feedback reinforcement learning, and action calibration.

[[IMG:1]]

My hands-on experience tracks with the benchmark numbers. Long-horizon tasks hold up better. Composer 2 would sometimes lose track on refactors beyond 500 lines. Composer 2.5 completed those same jobs end-to-end. Cross-file consistency also held on multi-file edits.

But for Cursor loyalists, accuracy isn’t the number that matters — cost is.

TechTimes ran the math: Composer 2.5 reaches 63% CursorBench accuracy for roughly $0.50 per task. Claude Opus 4.7 at xhigh settings reportedly runs around $7 for 62% accuracy. Same precision bracket, 10x+ the unit cost difference, per TechTimes’ estimate.

Full migration to Claude Code means “best accuracy, but potentially a 10x monthly bill.” Composer 2.5 is the practical alternative: you give up the accuracy ceiling in exchange for 10x cost headroom. That trade holds.

My current split: Claude Code only for large production-branch changes; Composer 2.5 for daily refactors and small feature additions. Since moving to this two-tier setup, my monthly spend has dropped to less than half of what either tool cost solo — and I can concentrate Claude Code tokens on the moments that actually warrant them.

Bugbot’s 3 Effort Levels — 0.7 vs. 0.95 Bugs/Review

Now for the feature that impressed me most.

On May 11, 2026, Cursor shipped effort levels for Bugbot — Cursor’s PR review agent that automatically reviews pull requests pushed to GitHub. Three levels: Default, High, and Custom.

From Cursor’s official changelog and Start Debugging’s analysis:

• Default: 0.7 bugs/review on average; 79%+ of issues resolved before merge; low latency
• High: 0.95 bugs/review average; 36% more than Default; additional latency and token cost
• Custom: natural-language routing; one short instruction lets Bugbot self-select Default or High per PR

[[IMG:2]]

What struck me about this design: it understands the real rhythms of PR review.

Run High on every PR for a team pushing 5+ PRs a day and review queue times balloon. Run Default on the one big release PR of the month and you’re accepting unnecessary risk. A fixed effort level doesn’t fit production pacing.

Custom is the clever part. No slider, no YAML config — one plain-text instruction. Bugbot treats it as a routing prompt and self-selects the level per PR.

The Custom instruction I’m running:

If the PR title starts with "fix:" or "refactor:", use Default.
If the title contains "feat:", "BREAKING:", or "migrate:",
or if the changed file count exceeds 10, use High. Otherwise, Default.

That means Bugbot runs deep reviews on new features and breaking changes, and returns fast results on minor fixes. Pairs well with Conventional Commits-style message conventions.

Key point for Cursor loyalists: Bugbot handles the PR review layer entirely inside Cursor. No need to build your own SDK integration against Claude Code’s API. Claude Code is a strong local development tool, but automated GitHub PR review isn’t a built-in offering today. Bugbot remains a native Cursor advantage here.

One week in, the quietest win was reviewer load distribution. Bugbot catches low-hanging bugs before teammates even open the PR. Only the issues that needed High-level depth reach human review. Reviewers spend their time on the PRs that actually need thinking.

Switching to Usage-Based Pricing — The Invoice After $40/Seat Disappears

Third change: the pricing overhaul. In May 2026, Cursor announced that Bugbot billing is shifting from per-seat monthly fixed pricing to usage-based.

Previously, Bugbot cost $40 per team member per month — $400/month for a 10-person team, even if only four of them were submitting PRs. The “charge only active users” frustration had been building for a while.

The new model: $1.00–$1.50 per Bugbot review, depending on PR size and complexity. A hard pivot toward “if you don’t use it, you don’t pay,” as StartupHub.ai reported.

[[IMG:3]]

Timing matters here. Per Cursor’s official explanation, existing subscribers see the new pricing applied starting at their first renewal on or after June 8, 2026. Annual contracts purchased in May 2026 stay at $40/seat through May 2027.

That’s an unusually considerate rollout for a SaaS pricing change. The usual playbook is “everyone switches next month.” Cursor honored the contract period.

That said, don’t misread the generosity.

A 10-person team pushing 50 PRs/month: new model is roughly $50–$75/month, a steep drop from $400. A 20-person team with 200 reviews/month: around $200–$300, still down from $800.

Almost every team’s bill goes down in this model. The move Cursor loyalists might miss: take the savings and redirect them into Composer 2.5 Fast tier.

Bugbot savings → Composer 2.5 Fast ($3.00/$15.00) for heavy computation → complete setup: standard Composer 2.5 for lightweight work, Fast for complex design decisions, Bugbot Custom for PR routing. Same budget envelope, expanded capability.

My team is currently mid-way through the internal pitch for this reallocation. The framing that moved through executive review wasn’t “cost savings” — it was “same budget, more capability.” From my time in Customer Success, cost-reduction proposals move slowly through finance. “Same wallet, more value” goes through much faster. That’s a negotiation tactic worth remembering.

How to Coexist with Claude Code

That’s three shifts on Cursor’s side. The next question for loyalists: “With Claude Code in the picture, which tool owns which phase?”

I think about it across two axes: cost sensitivity and PR volume.

[[IMG:4]]

• Low cost sensitivity + low PR volume (solo dev, side project): Standard Composer 2.5 + Default Bugbot. Monthly spend stays in the $10–30 range.
• Low cost sensitivity + high PR volume (early-stage startup, speed-first): Composer 2.5 Fast + High Bugbot. Lower latency plus deeper review coverage.
• High cost sensitivity + low PR volume (enterprise contractor, strict governance): Standard Composer 2.5 only. Manual PR review; human re-verification of Bugbot output.
• High cost sensitivity + high PR volume (mid-size team, production workload): Bugbot Custom for conditional routing; Composer 2.5 toggled between standard and Fast per feature type.

Slot your team into this matrix and you’ll know where to set Cursor in under a minute. Claude Code works alongside any quadrant — but without a clear answer to “what does Cursor own,” you end up paying twice for the same workload.

Fortune’s March piece “Cursor’s crossroads” flagged the base-model dependency risk, which hasn’t fully resolved. Cursor’s Moonshot-based Composer 2.5 reduces Anthropic dependency, but enterprise deals are still leaning toward Claude Code.

My message to Cursor loyalists: staying isn’t a bet, it’s a segmentation decision. Cursor still holds distinct value in two areas: PR automation and cost-efficient coding. If you have meaningful volume in both, keeping Cursor is a rational call.

If most of your work is local development, PRs are reviewed manually by teammates, and you prioritize accuracy over cost — that’s a case for consolidating on Claude Code. Simpler toolchain, less overhead.

Two axes. One converging answer. The only thing that matters is an honest read of your own team — not an aspirational one.

3 Changes Cursor Loyalists Should Make This Week

Here’s what I’ve covered, translated into actions you can take within 7 days.

[[IMG:5]]

Change 1: Run Composer 2.5 for one week on an existing branch

If “testing a new model in production” sounds risky — that’s exactly why you should do it. Critical point: test it on an existing branch, not a new project. The real signal is how well Composer 2.5 understands your existing repo context.

I ran it for a week on an internal tool — a 300+ file TypeScript + Python project. Three new feature additions and five bug fixes. Composer 2 had failed on two of those bug fixes previously. Composer 2.5 passed 7 of 8.

One gotcha to know upfront: Composer 2.5 reads the full repo on the first session, so the initial token bill looks high. Some people see that and conclude “2.5 is expensive.” Costs drop noticeably by session two. Measure by weekly average, not first-session spend.

One week of testing costs well under $10. Going in with “if it doesn’t work, I’ll go back to Claude Code” as a fallback is fine.

Change 2: Start Bugbot on Default, record bugs/review for 7 days

If you haven’t run Bugbot yet: start on Default. Not High, not Custom — Default first. That’s the rule.

Track three numbers over 7 days: PRs opened, Bugbot bug catches, and pre-merge resolutions. In my experience you’ll land somewhere around 0.5–0.8 bugs/review — close to Cursor’s stated 0.7.

If your numbers track, flip to High in week two and see if you approach 1.0. If the delta justifies the added cost and latency, you have your answer. If not, Default is your steady state.

Change 3: Check your billing model today — takes 5 minutes

Open Cursor’s billing settings. Confirm your contract type (monthly or annual) and your next renewal date.

If renewal falls after June 8, 2026, usage-based pricing kicks in at that renewal. Pull your Bugbot usage count for the past 90 days, then run the math: if each run cost $1.25, what’s the total?

My team’s estimate came out 18% below current spend. I’m now building the pitch deck to redirect that delta into Composer 2.5 Fast capacity. The framing isn’t “we’re saving money” — it’s “we’re getting more for the same amount.” That’s the version that moves through executive review.

Wrap-Up

Yesterday was about whether to stay with Cursor or switch. Today is for the readers who chose to stay.

Key points:

• Composer 2.5: 79.8% on SWE-Bench Multilingual, one point behind Claude Opus 4.7, at roughly 1/10 the cost
• Bugbot: 3 effort levels added (Default 0.7 / High 0.95 / Custom natural-language routing)
• Pricing: seat-based fixed → usage-based, effective at first renewal on or after June 8, 2026
• This week’s 3 moves: run Composer 2.5 on an existing branch for 7 days, start Bugbot on Default and measure, run the billing model estimate

I’m not dropping Cursor. Claude Code’s accuracy ceiling is genuinely higher. But Cursor defended its distinct value in two specific areas: PR review automation and cost-efficient coding. This isn’t a binary “switch or stay” question — it’s a portfolio problem of “what do I assign to which tool.” That framing makes the operational call much simpler.

Cursor’s quiet counterattack is happening right now. For loyalists, this is the window to tune settings and pull ahead. Open Cursor’s settings for 5 minutes next week. Revisit effort level and model selection. Both your monthly bill and your code review quality can shift from just those two changes.

Hit a wall? Let me know. I’m still searching for the optimal Custom routing instruction myself. And from my Customer Success days — “same budget, more value” is always the pitch that gets approved first. Try it before you go with “cost reduction.”

---