Cursor: Composer 2.5 and the new Auto-Review run mode

Redaktion · · 6 Min. Lesezeit

In May 2026 Cursor shipped two updates that, taken together, make the tool’s direction clear. On May 18 came Composer 2.5, Cursor’s in-house coding model, with noticeably better behaviour on long-running tasks. Eleven days later, on May 29, the Auto-Review run mode followed — an execution mode in which the agent works longer without asking and only stops for ambiguous actions. Both point the same way: Cursor wants agents to run more autonomously without giving up control entirely. For teams weighing Cursor against Claude Code, that shifts the basis for the decision.

What applied before

Cursor 3 set the frame on April 2, 2026 with the “Agents Window”: a dedicated surface for running multiple AI agents in parallel — locally, in Git worktrees, over SSH and in the cloud. The idea behind it is that developers orchestrate agents rather than write every line themselves. Cursor 3 also introduced Composer 2 as Cursor’s in-house frontier coding model.

When it came to executing tool calls, the rule was essentially: anything not explicitly on the allowlist needed a manual approval. That slowed down long agent sessions — every shell command, every MCP call, every fetch could trigger a confirmation prompt. Safe, but tedious. And while Composer 2 was usable, it lagged behind the large closed-source models on long, multi-step tasks.

What applies now

1. Composer 2.5 closes in on the frontier models — at a fraction of the price. Cursor reports 79.8% on SWE-Bench Multilingual for Composer 2.5, less than a point behind Claude Opus 4.7 (80.5%), and on CursorBench v3.1 it even edges ahead at 63.2% versus Opus 4.7 at default settings. These benchmark figures come from the vendor and are not independently verified. What matters in practice is less the score than the price ratio: on the standard tier Composer 2.5 costs $0.50 / $2.50 per million tokens (input/output), the Fast variant (default) $3.00 / $15.00 per million tokens. That puts the model roughly ten times below Opus 4.7 on input cost. For long agent runs, where token consumption is the real cost driver, that changes the maths.

2. Auto-Review lets the agent run longer without asking. The new mode (Cursor 3.6) checks every tool call in a fixed order: if it is on the terminal or MCP allowlist, it runs immediately. If it can be sandboxed, it runs in the sandbox with network and filesystem restrictions. Everything else goes to a classifier subagent that decides whether to allow the call, try a different approach, or ask for your approval. This applies to Shell, MCP and Fetch tool calls. The mode is configured under Settings › Cursor Settings › Agents › Run Mode.

3. Teams get more room and a Premium seat. Cursor raises the usage limits on Teams plans and introduces a new Premium seat that, per the vendor, provides five times the included usage of the Standard seat at three times the cost. Spend controls improve too: the dashboard shows how close a user is to their limit, split between “Auto + Composer” and third-party APIs; admins can set dollar-based thresholds and receive alerts via Slack or email. Per Cursor, Standard seats run $32 per seat/month on annual plans ($40 monthly), Premium seats $96 ($120 monthly); the changes take effect immediately for new customers and from billing cycles starting July 1, 2026 for existing ones.

Why it matters

The common thread across both releases is: fewer approval prompts, more autonomy. That is the economically logical answer to the Agents Window promise — if you want to run several agents in parallel, you cannot confirm every shell command by hand. But that is exactly where the risk sits. An agent that works longer without asking can also run longer in the wrong direction before anyone intervenes.

Cursor counters this with sandbox and allowlist as technical guardrails — and is unusually candid about their limits. In its own documentation Cursor describes the classifier as non-deterministic and explicitly as “best-effort convenience, not a security boundary”. The warning is blunt: do not point Auto-Review at production credentials, mutating MCP servers, or any environment where a wrong call has irreversible consequences. That honesty is welcome — but it also pushes responsibility back onto teams. Anyone running the mode in production has to draw their own allowlist and sandbox boundaries cleanly.

Compared with Claude Code, a line becomes visible: both worlds are moving toward more autonomous agents, but solve the control question differently. Cursor leans hard on its own UI with a parallel Agents Window and a cheap in-house model; Claude Code stays CLI-centric with fine-grained permission hooks. For tool choice, that means it is less about “which model is three benchmark points better” and more about the interaction model and how much autonomy a team can responsibly take on.

What you can do now

If you want to test Auto-Review: Enable the mode first in an isolated project with no access to production systems. Review your terminal and MCP allowlist line by line before letting the agent run on its own for longer — the classifier is convenience, not a security guarantee.

If the cost of long agent runs is hurting: Compare Composer 2.5 on the standard tier against your current model. For long, token-heavy tasks the price-performance ratio is the real lever, not the benchmark score.

If you work in a team: Before July 1, 2026, look at which seats fit your usage. The Premium seat only pays off for genuine heavy agent users; for occasional use, Standard remains the calmer choice. Set up dollar-based spend alerts before the first bill surprises you.

Entdecke mehr

Themenuebersicht