Cursor 3 Turns the IDE Into an Agent Manager

Cursor 3 is not a cleaner chat panel. It is Cursor trying to turn the IDE into an agent manager.

The first version of this article framed Cursor 3 as the end of ten open tabs. That was too small. The larger move is structural. Cursor is pushing developers away from one prompt, one response, one edit, and toward a workspace where multiple agents take tasks, run in parallel, report back, and wait for review.

Cursor has been public about this direction. Its strategic frame is the Third Era of programming. First came manual coding. Then came AI pair programming through Tab and chat. The third phase is delegated software work, where agents pick up issues, modify code, run checks, and open changes for humans to approve.

Cursor also said agent usage has grown 15x, that usage is shifting from Tab-heavy flows toward agent-heavy flows, and that autonomous cloud agents create 35% of Cursor's internal pull requests. Those claims matter because they explain why Cursor 3 exists. This is not a side feature. It is the company moving its center of gravity from editor to agent runtime.

What Cursor 3 actually adds

The headline feature is the Agents Window. You can open it from the command palette with:

Cmd+Shift+P, then search for Agents Window.

The important detail is architectural. The Agents Window, also referred to as Glass in public discussion, was built from scratch. It is not simply another VS Code fork window with a new sidebar. Cursor is trying to create a dedicated control surface for agent work.

In practice, the Agents Window gives you a place to:

• Start multiple agents in parallel
• Assign each agent a separate coding task
• Track local, remote, and cloud work from one surface
• Review outputs without losing your main editor context
• Move between active coding and delegated coding

Cursor 3 supports agents across:

• Local machine worktrees
• SSH-connected remote environments
• Cursor cloud compute
• Self-hosted agent setups
• Connected surfaces such as web, mobile, Slack, GitHub, and Linear, where enabled

The old mental model was: open Cursor, ask chat, apply patch, review diff.

The new model is: create tasks, let agents work in separate execution contexts, inspect the result, then merge or reject.

The March stack before Cursor 3

Cursor 3 did not arrive alone. The March release sequence set it up.

The rough stack was:

1. Automations, scheduled or event-driven agent work
2. Marketplace, a distribution surface for tools and workflows
3. Composer 2, a stronger coding model layer
4. Self-hosted agents, for teams that need more control over execution
5. Cursor 3, the workspace that pulls agent work into a dedicated interface

This sequence matters because Cursor is not only shipping model access. It is building an operating model for software teams that want AI agents to touch real repositories.

If you only judge Cursor 3 as an editor update, you miss the plan. Automations give agents triggers. Marketplace gives them extensions and workflows. Composer 2 gives them a coding model. Self-hosted agents give enterprises more deployment control. Cursor 3 gives engineers a place to manage the work.

Composer 2 is a major part of the story

Composer 2 deserves its own section because it is the engine behind much of this shift.

Cursor said Composer 2 is based on Kimi K2.5 and trained further with reinforcement learning. (Cursor subsequently shipped Composer 2.5, which retained the Kimi K2.5 base with additional training; references here use the Composer 2 name as it stood at Cursor 3 launch.) Cursor also discussed gains against coding benchmarks such as Terminal-Bench and SWE-bench, though operators should care more about repo-specific review quality than benchmark names.

The useful product change is self-summarization. Long agent sessions can summarize their own work, keep context tighter, and avoid forcing the developer to reread a wall of intermediate reasoning before deciding whether the output is safe.

There was also disclosure backlash. Users objected that Cursor's messaging did not make the Kimi K2.5 base obvious enough at first glance. For buyers, this is not gossip. It is a procurement issue. If your vendor risk process tracks model providers, data paths, or model lineage, Composer 2 needs to be documented clearly in your internal tool record.

Bugbot and canvases changed after launch

Two post-launch updates are worth keeping in the record.

On April 8, Cursor updated Bugbot. The practical point was feedback-driven improvement. Bugbot can use acceptance and rejection signals to improve its bug-fixing behavior. Cursor also added MCP support for Bugbot.

On April 15, Cursor added interactive canvases. Agents can respond with richer artifacts, including visualizations, tables, diagrams, dashboards, diffs, and task lists. This matters for planning work and code review. A long text answer is often the wrong output for an architecture change. A diagram or review checklist is easier to inspect.

These updates also prove why the old dateModified was wrong. This article now tracks the April updates and the June 25 state.

Why the Agents Window matters

Cursor's original strength was speed inside the editor. Tab completions felt fast. Chat was nearby. Diffs were easier to apply than in a browser assistant.

Cursor 3 changes the unit of work.

The unit is no longer one completion. It is one delegated task.

That creates a different workflow:

• A developer keeps the main editor open for high-judgment work
• Agents take lower-risk tasks in parallel
• Each agent works in its own branch, worktree, remote session, or cloud task
• The developer reviews output, tests, and diffs
• Bad work is discarded instead of manually untangled inside the main branch

For senior engineers, this can reduce context switching. For managers, it creates a new review problem. Agent work still needs ownership, test discipline, and rollback paths. A codebase does not become safe because the patch came from a premium model.

What breaks today

The strongest criticism of Cursor 3 is not that agents are useless. It is that the new workspace is not yet a full replacement for a mature daily IDE setup.

Cursor forum users have reported several blockers:

• No VS Code extensions in Agents Window. If your flow depends on extensions for language tooling, database work, Kubernetes, testing, or internal tools, this hurts.
• WSL and Dev Containers gaps. Teams that develop inside WSL or containerized environments cannot treat Agents Window as a drop-in replacement yet.
• Diff and review friction. Agent output is only useful if review is fast. If the diff flow breaks your muscle memory, adoption stalls.
• Weak search. Agent work creates more branches of context. Search quality becomes more important, not less.
• No custom themes. This sounds cosmetic until you ask developers to live in a new surface all day.
• Browser and session gaps. Some tasks need authenticated browser state, local sessions, or app-specific context that an agent window may not carry cleanly.

This is the difference between launch demo and daily adoption. An agent manager can be powerful and still fail a normal Tuesday if it cannot match the developer's existing environment.

Cursor 3 vs Claude Code, Codex, Copilot, and Windsurf

The market has split by interface.

Tool	Strongest fit	Where it loses
Cursor 3	IDE-first agent management and interactive coding	New Agents Window still lacks parts of mature IDE workflow
Claude Code	Terminal and scripted agent work	Less visual IDE control
GitHub Copilot	Inline completions and familiar editor integration	Weaker fit for parallel delegated tasks
Codex	Cloud-based long-running coding tasks	Less tied to local editor state
Windsurf	Multi-file coding flows and agent-style assistance	Cursor is pushing harder into dedicated agent management

Most serious teams will not standardize on one tool immediately. The practical split is simple:

• Use Cursor when the developer is actively steering code
• Use a terminal agent when the task belongs in scripts, CI, or shell-heavy work
• Use cloud agents for longer jobs that do not need constant local context
• Keep Copilot-style completion if the team values low-friction inline suggestions

Cursor 3's bet is that the IDE remains the best place to supervise this work. Claude Code and Codex pressure that bet from the terminal and cloud.

Pricing note for India

The older version of this article listed exact rupee conversions, completion counts, and plan assumptions. I am removing those claims.

Cursor pricing, included usage, education plans, and cloud agent limits can change. Indian buyers should budget from Cursor's billing page and the contract terms shown at purchase time, not from old INR conversions in launch coverage.

For individual Indian developers, the real question is not whether a plan converts cleanly into rupees. The question is whether Cursor saves enough reviewable engineering time to justify a paid seat.

For teams in India, the buying checklist should be:

• Does Privacy Mode cover your policy needs?
• Which model providers may process code?
• Are cloud agents allowed for private repositories?
• Are self-hosted agents required?
• Can agents access SSH, internal package registries, issue trackers, and CI logs under your security rules?
• Who owns review when an agent opens a change?
• Does your code review template require tests, screenshots, migration notes, and rollback steps for agent-authored patches?

Do not make a vendor decision from a productivity demo. Make it from a controlled trial on one real repository.

Privacy and procurement

The old FAQ said Privacy Mode keeps code out of any third-party log. That sentence was too strong without exact contract language.

The safer reading is this: Cursor's Privacy Mode and team controls are the starting point for procurement, not the end of it. If your company handles regulated data, private customer code, or strict client IP, read the current Cursor security and privacy terms before approving agent workflows.

Ask these questions in writing:

• Is code used for model training?
• Which subprocessors may receive code or prompts?
• Are prompts, diffs, terminal output, and logs retained?
• Do cloud agents store repository snapshots?
• Can admins disable specific model providers?
• Can teams restrict agents to local or self-hosted execution?
• Are audit logs available for agent actions?

The risk is not only source code leakage. Terminal output can contain secrets. Logs can contain customer data. Diffs can expose internal architecture. Agent traces can reveal more than the final patch.

How to try Cursor 3 now

Install or update Cursor from Cursor's site.

To open the Agents Window:

Cmd+Shift+P, then run Agents Window.

Start with one low-risk task. Good first tests:

• Add missing unit tests around a small function
• Update a narrow dependency with a clear changelog
• Refactor one file with existing tests
• Draft a migration plan without applying code
• Ask an agent to inspect a bug and propose a patch, then reject the patch if the reasoning is weak

Avoid first tests that touch authentication, billing, data deletion, permissions, migrations, or customer-facing behavior. Agent tools should earn trust on boring work before they touch dangerous paths.

Operator verdict

Cursor 3 is an important release because it makes the IDE compete as an agent control plane.

The upside is clear. Parallel agents can reduce context switching and move low-risk coding tasks out of the developer's main thread. Composer 2, Bugbot, canvases, Automations, Marketplace, and self-hosted agents make Cursor look less like a better editor and more like a software work system.

The weakness is also clear. Agents Window is still early as a daily environment. Missing extensions, WSL and Dev Container gaps, review friction, search limits, theme limits, and session issues can block adoption for serious developers.

Use Cursor 3 if you want to test agent-managed development inside the editor. Do not treat it as a finished replacement for your full workflow yet.

See our Cursor playbook entry for the operator breakdown.

---

Sources: Cursor Blog and Changelog, Cursor Forum, SiliconANGLE, The New Stack, public coverage through June 25, 2026.