By Cursor shipped four meaningful releases in five weeks. Parallel agents in 3.0. The /multitask async command in 3.2. An always-on Security Review in beta. Context usage breakdowns in 3.3. Taken individually, each is a changelog entry. Taken together, they describe a company systematically turning its IDE into an agent execution runtime — and handing developers considerably more rope.
What /multitask Actually Does
Prior to Cursor 3.2 (April 24), running multiple agent tasks meant a queue. You waited. /multitask changes that: type the command in any agent session and Cursor dispatches async subagents in parallel instead of serializing the work. It also breaks larger tasks into smaller chunks automatically, farming them out to a fleet simultaneously.
The isolation mechanism is Git worktrees — each agent gets its own checkout of the repository at a distinct filesystem path. Agents write, build, and run tests without stepping on each other’s files. Cursor manages worktree creation and cleanup. The Agents Window sidebar shows every active session, local or cloud, across all open repos. The cap is eight parallel agents.
One developer in the community called it the first time agentic coding “actually feels like agentic coding.” The framing is apt. The dominant cost in sequential agent use was waiting for each task to finish before the next could start. /multitask attacks exactly that bottleneck — compressing what would have been 100 minutes of serial work into 20 minutes of wall-clock time when five independent tasks each take 20 minutes.
The Cost Problem Nobody Is Talking About
Here is the part that does not make the feature announcement posts. Ninety percent of Cursor’s token consumption is input tokens from context that gets re-read on every step — not the code it generates. By the fifteenth command in a session, a single request can ship more than 200,000 input tokens as the accumulated conversation history reloads for each internal API call.
Parallel agents multiply this. Three agents running simultaneously is not three times the useful work — it is also three times the context overhead. Users have reported bills of $2,000 in two days. One user logged 21 million cache-read tokens on a single call containing about 4,000 user input tokens. Cursor does not publish concrete usage limits for any plan, which makes the billing surprises particularly sharp.
This is not an argument against parallel agents. It is an argument for understanding what you are paying for before you spin up eight of them.
Context Usage Breakdown: Cursor’s Diagnostic Response
Cursor 3.3 (May 6) added context usage breakdowns — click the context ring on any agent session and get a breakdown of where the tokens are going: rules, skills, MCPs, subagents. This is Cursor’s direct response to billing complaints, and it is a genuinely useful tool for parallel agent workflows.
In practice, the breakdown surfaces issues that are invisible until you look: a .cursorrules file that has grown to 8,000 tokens, an MCP integration pulling large schemas on every invocation, a subagent chain where parent context leaks into child sessions unnecessarily. These are fixable once you can see them. Before 3.3, most developers were flying blind on context allocation.
Security Review: Catching What Agents Miss
On April 30, Cursor launched Security Review in beta for Teams and Enterprise plans. It ships two always-on agents: a Security Reviewer that checks every PR for vulnerabilities, authentication regressions, privacy risks, and prompt injection vectors, leaving inline comments at the exact diff location with severity ratings; and a Vulnerability Scanner that runs scheduled codebase scans and posts findings to Slack.
The timing is not coincidental. AI-generated code at scale creates a review surface that human reviewers increasingly cannot cover alone. Moving security scanning from post-commit CI/CD to pre-merge PR review is where AI-generated code needs it most — the point where it is still cheap to fix. Cursor’s security agents check for prompt injection attacks specifically, a vector that standard SAST tools do not cover at all.
When Parallel Agents Actually Pay Off
The community reaction to Cursor 3.x has been divided, and the skepticism is worth taking seriously. The gains are real under three conditions: tasks are genuinely independent (not just separate files — separate code semantics), you can batch-review diffs efficiently when agents complete, and agents have enough context to stay on task without constant intervention. When any of those break down, you end up with four half-done pull requests instead of one finished one.
The bluntest version: vague instructions given to one agent produce one cleanup session. The same vague instructions given to three parallel agents produce three cleanup sessions. /multitask accelerates what you already do well. It does not compensate for fuzzy task definitions.
Use parallel agents for genuinely parallelizable work — adding tests for independent modules, refactoring isolated utilities, running competitive implementations of the same function to compare. Stay single-threaded for systems work where the value comes from reasoning through one hard problem carefully. The Agents Window shows eight slots. You do not have to fill them.
The Verdict
Cursor’s five-week arc — parallel agents, /multitask, Security Review, context breakdowns — is a coherent product strategy, not four disconnected feature drops. The IDE is becoming a runtime for agentic work. The context breakdown in 3.3 is what makes the rest sustainable: you cannot manage costs you cannot see. Enable Security Review if you are on a Teams or Enterprise plan. Reach for /multitask on tasks you can genuinely decompose. Check the context ring before your next billing cycle.
