Cursor 3.3 parallel agents and Split PRs: how to break a refactor into independent slices

The bottom line

Cursor’s 3.3 release on 7 May 2026 ¹ shipped three things at once: a redesigned PR Review tab, a Plan Mode action called Build in Parallel, and a quick action called Split PRs. Build in Parallel takes a multi-step plan, identifies steps that don’t depend on each other, and dispatches them to async subagents that run simultaneously. Split PRs takes the resulting multitask diff and proposes independent pull requests sliced from chat context. The combination wins when refactor work is genuinely independent (separate modules, separate files, contracts agreed upfront) and costs more than sequential when tasks are small, dependent, or share files. Build in Parallel is currently a UI-only action invoked from the Agents Window; Cursor does not expose a public SDK for parallel-agent dispatch as of writer-time.

What Cursor 3.3 ships

The 7 May 2026 changelog entry ¹ covers three features. The PR Review tab adds a Reviews view for inline review threads, a Commits view for focused commit history, and a Changes view with a file tree for navigating larger PRs. Build in Parallel is the headline workflow: per Cursor, it lets the agent “execute on plans faster by multitasking across tasks instead of tackling them one at a time” ¹ by clicking a button to “identify independent parts of your plan and run them simultaneously using async subagents.” Split PRs is the complement, splitting the resulting diff “into PRs” using “chat context to identify logical slices.” ¹

The changelog is the canonical announcement. Cursor’s main docs at cursor.com/docs/agent ⁵ and cursor.com/docs/agent/plan-mode ⁶ still describe the pre-3.3 single-agent and sequential-build flows as of 2026-05-08; neither page mentions Build in Parallel yet. The doc lag is normal for one-day-after-release coverage; if the docs update between this article shipping and you reading it, the docs become the more detailed reference.

A note on the “3.3” label. Cursor’s changelog index ² shows two entries dated within 24 hours, both labelled 3.3: a 6 May 2026 entry that adds an agent context-usage breakdown, ³ and the 7 May 2026 entry that adds parallel agents and Split PRs. ¹ When this article says “Cursor 3.3” without a date, it means the 7 May entry.

Image: Cursor 3.0 launch blog (2 April 2026), used for editorial coverage of the Agents Window architecture that 3.3 builds on.

Section 1: When parallelism wins vs costs more

The decision is whether the work decomposes into independent slices that can be reviewed cleanly afterwards. Liran Baba’s analysis of the Cursor 3 release ¹³ frames the trade-off bluntly: “for tasks under 30 minutes, the orchestration overhead eats the speedup,” and “when Agent B depends on Agent A’s output, you can’t parallelize” — most real work has those dependencies. Krischase’s separate analysis ¹⁴ identifies a second cost: the bottleneck moves from how fast one person can work to how fast a reviewer can integrate what multiple agents produced.

The rough decision table:

Pattern	Parallelism wins	Parallelism costs more
Module structure	Independent modules (UI, API, database, tests in a full-stack feature)	Tight coupling between files multiple agents would touch
Task size	Steps run more than 30 min each, so orchestration amortises	Steps run under 30 min each, so overhead dominates
Dependency shape	Steps share contracts agreed upfront, then diverge	Step B reads step A’s output, forcing a chain
Review capacity	One human reviewer can absorb the resulting PR queue	The queue backs up; standards slip 14

The pre-3.3 community pattern was a manual worktree.json setup ⁹ in which agents claimed task numbers from a coordination directory using atomic mkdir locks. Build in Parallel automates that setup. The trade-off shape is the same.

Image: Cursor Plan Mode documentation, used for editorial coverage of the Plan Mode workflow that Build in Parallel extends.

Section 2: Setting up a multi-agent task in Plan Mode

The workflow is UI-driven. There is no documented CLI or SDK primitive for Build in Parallel as of 2026-05-08; the Cursor CLI ⁷ exposes single-session agent commands and a & message quick-action for pushing a session to a Cloud Agent, but neither of those is a parallel-plan-dispatch primitive. To dispatch parallel work, you go through Plan Mode in the Agents Window.

1. Open the Agents Window. Per the Cursor 3.0 launch post, ⁴ the keyboard shortcut is Cmd+Shift+P → "Agents Window". The window is the multi-workspace surface where local and cloud agents both appear.
2. Switch to Plan Mode. Either type /plan in the agent input, or invoke --mode=plan from the CLI session. Plan Mode’s standard flow runs clarifying questions, codebase research, plan creation, and review-and-edit before building. ⁶
3. Describe the multi-task work. A clean Build in Parallel prompt looks like a refactor described as a set of decoupled changes — for example, “migrate the auth module from JWT-in-localStorage to httpOnly cookies; update server middleware, client code, and tests.”
4. Review the generated plan before clicking Build in Parallel. This is the load-bearing step. If Cursor’s plan-decomposition lists steps that share files or read each other’s output, mark them dependent or re-group before dispatching. The plan is what the parallel run executes against.
5. Click “Build in Parallel”. Cursor identifies independent parts and dispatches them to async subagents that run simultaneously. ¹

Section 3: How Split PRs work

Split PRs takes the multitask diff that Build in Parallel produces and proposes independent pull requests. Per the changelog, the action “use[s] chat context to identify logical slices, default[s] to independent PRs unless dependencies are required, create[s] a backup snapshot, and propose[s] a split plan for your approval.” ¹ The backup snapshot is mentioned but not documented in detail; treat it as Cursor’s safety mechanism rather than a recovery primitive you should rely on without testing.

Split PRs is invoked as a quick action from the chat context. After review and approval of the proposed split, the PRs land in dependency order: independent PRs go up immediately, and dependent PRs wait for their predecessors to merge. The new PR Review tab is where the resulting PRs surface, with the Reviews / Commits / Changes views ¹ as the navigation surface.

Image: Cursor pricing page, used for editorial coverage of the tier-availability discussion.

A note on tier availability. The 7 May changelog ¹ does not gate Build in Parallel or Split PRs behind a tier, and the pricing page ⁸ does not list either feature in any tier’s feature box as of 2026-05-08. What the pricing page does list as a Pro-tier feature ($20 per month) ⁸ is “Cloud agents,” which is the underlying primitive the changelog points to when it talks about “async subagents.” A reasonable inference is that Build in Parallel works across tiers but is throttled by each tier’s Cloud agents allowance, with Hobby (free) users hitting the same “Limited Agent requests” rate cap ⁸ that throttles their other agent usage. This is inference from the tier feature lists, not a Cursor-confirmed mapping; verify with Cursor support before committing a team to a tier on the basis of parallel-agent expectations.

Section 4: Common pitfalls

Four pitfalls show up consistently in the third-party analyses of Cursor’s parallel-agent workflow. The official 3.3 release thread on Cursor’s community forum ⁹ had no community replies extractable as of writer-time (the thread was 24 hours old), so the gotchas below come from earlier 3.x community work and named third-party blogs.

Same-file edits cause overwrites. Per Krischase, ¹⁴ “never run two agents on the same branch simultaneously.” If Cursor’s plan decomposition routes two parallel steps onto the same file, one will overwrite the other when the work merges. The fix is to review the plan before clicking Build in Parallel and re-group any same-file steps. Claude Code’s agent-teams docs ¹¹ make the same point: “two teammates editing the same file leads to overwrites; break the work so each teammate owns a different set of files.”

Dependency chains masquerading as independent work. Per Baba, ¹³ “when Agent B depends on Agent A’s output, you can’t parallelize. That’s most real work.” If step B reads step A’s output, the parallel run will either block waiting on A or produce divergent results. The fix is the same plan review.

Orchestration overhead on small tasks. Baba’s threshold ¹³ is 30 minutes per step; below that, sequential agent mode is faster. Build in Parallel is the wrong tool for a five-step polish pass.

Cloud agent budget exhaustion. Build in Parallel runs through Cloud agents, which draw from the user’s tier-allotted credit pool. The pricing page ⁸ shows tier names and per-tier usage multipliers (Pro+ at 3× Pro; Ultra at 20× Pro) but does not publish exact request limits or per-task credit costs, so the per-month spend on a parallel-heavy workflow is not predictable from the pricing page alone. Third-party review claw.mobile ¹⁵ documents mixed community feedback on parallelism quality (meaningful speedups on independent tasks; agents stepping on each other in tightly coupled codebases) — useful directional context but not a spend benchmark. Monitor billing in the first parallel runs and treat the run cost as variable until your team’s pattern is established.

Image: Cursor changelog index, used for editorial coverage of the rapid release cadence.

Where to go next

If parallel-agent work is core to your workflow but Cursor’s UI-only invocation is a constraint, two alternatives are worth knowing.

Claude Code ships sub-agents and an experimental agent-teams feature. ^{11 10} Sub-agents are the closer match to Cursor’s own pre-3.3 single-session pattern: a side task runs in its own context window and returns a summary. Agent teams are the closer match to Build in Parallel: independent context windows, shared task list, async coordination. Agent teams are gated behind CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 as of 2026-05-08 and require Claude Code v2.1.32 or later. ¹⁰ Treat that experimental flag as subject to change.

GitHub Copilot’s product page ¹² mentions “agents on GitHub” and the ability to “assign tasks to agents like Copilot, Claude by Anthropic, and OpenAI Codex,” but it does not document a dedicated parallel-agent primitive comparable to Cursor’s Build in Parallel or Claude Code’s agent teams as of 2026-05-08. The Copilot agent surface is single-session in the documentation that exists.

A final note on Cursor’s release cadence. The product ships rapid releases: two changelog entries labelled 3.3 went out within 24 hours of each other. ² The workflow described above applies to the 7 May 2026 release; if a 3.4 or 4.x release lands between writer-time and your reading time, re-check cursor.com/changelog ² to confirm the UI surfaces and tier mapping match what’s in front of you.