Guide intermediate

Cursor 3.3 Build in Parallel: Async Subagents and Split PRs

Published May 12, 2026 · by Pondero Editorial

The short version

Cursor 3.3 shipped May 7, 2026 with Build in Parallel, Split PRs, and a redesigned review surface. Why Split PRs is the only one that changes team throughput, and how to estimate the rest.

Table of Contents

Cursor 3.3 Build in Parallel: Async Subagents and Split PRs

Published May 12, 2026, by Pondero Editorial

The one feature that changes how your team works

Cursor 3.3 landed on May 7, 2026 with three headline changes, and they are not equal. Build in Parallel cuts your wall-clock time. Quick-Action Pills save you clicks. Split PRs changes your team's review throughput, and that is the one to actually plan around. The first two make one engineer faster. The third makes the bottleneck (human review of agent-sized diffs) tractable, which is the constraint that was actually holding teams back.

If you ship large agent-generated PRs that sit in review because nobody wants to read a 1,200-line diff, upgrade for Split PRs and treat the rest as a bonus. This is the most operationally useful Cursor release since 3.2's multitask canvases, and the reason is the review math, not the parallelism.

What Changed

Three features and a redesign.

Build in Parallel. Cursor identifies plan steps with no dependency between them and runs them at the same time with async subagents; dependent steps still run in order. The entry point is a "Build in Parallel" button on the plan view, running on the same /multitask machinery from 3.2. The mental model that matters: it does not parallelize a single LLM call, it parallelizes independent slices of a plan. So the speedup is bounded entirely by your plan's dependency structure, not by Cursor. A plan that is one long dependent chain gets nothing; a plan that is mostly independent edits across files gets close to the theoretical max.

Split PRs. From a multitask change set, you can now invoke a quick action that uses chat context to identify logical slices, creates a backup snapshot, and proposes a split plan for approval. The default is independent PRs unless the dependency graph says otherwise. For teams that have a "max 400 lines per PR" reviewer norm, this is the feature you have been hand-rolling with git add -p for months.

Quick-Action Pills. You can pin frequently used skills (custom prompts, agents, rules combos) as pills at the top of the chat surface. Click to invoke. This is a small UX change with a real productivity impact if you have a skill library that grew past what fits in the slash menu.

PR review redesign. Cursor's PR review surface now has three tabs: Reviews (inline threads and comments), Commits (history), and Changes (file tree and navigation). Reviewer status and pending review banners are surfaced inline, and the same quick-action pills carry over for the most common next steps.

A few smaller items shipped alongside:

  • A context usage breakdown for agents that shows how rules, skills, MCPs, and subagents consume your context window. Long-overdue diagnostic for anyone who has hit "context full" mid-session and had to guess what to trim.
  • Settings for controlling Explore subagent behavior and support for general model names in subagent configuration.
  • Bugbot gained a High effort option (May 11) plus natural-language custom effort levels.

Why It Matters

Two workflow shifts, and both are real.

Start with plan-to-merge latency. In plan-then-execute mode on a multi-file refactor, you have been sitting through steps with no ordering reason to run sequentially. "Update the schema, then the migrations, then three call sites" hides a cut: the three call-site edits do not depend on each other. Build in Parallel finds and runs that cut. The candid way to estimate the payoff before you trust it: count the steps in a typical plan, then count how many genuinely depend on a prior step's output. The wall-clock you save is roughly the fraction that do not, capped by your subagent concurrency. Dependency-heavy migration plans save little. Fan-out plans (touch N independent files the same way) save the most.

The second is review throughput, and it is the real story. Agent-generated PRs broke code review by being too large to review well: a reviewer skims a 1,200-line seven-file diff and rubber-stamps it, which defeats the point of review. Split PRs turns that one diff into four scoped PRs a reviewer can actually hold in their head. The constraint on shipping agent work was never the agent's speed. It was the human review queue, and this is the first Cursor feature that attacks that constraint directly.

The PR review redesign matters less in isolation. It is a polish pass, not a workflow change. But combined with Split PRs, the surface now matches the new mental model: many small PRs, each with its own review thread, surfaced together.

How to Use It

Try Build in Parallel on a multi-step plan. Generate a plan as usual, then click "Build in Parallel" instead of "Build." Cursor will show you which steps it identified as independent before it kicks off the async subagents.

Use Split PRs for any multitask change set above ~300 lines. Run your multitask flow, review the proposed split plan, and approve. Each slice gets its own backup snapshot, so a bad split is recoverable.

Audit your context with the new breakdown. Open Settings, then Context, for the breakdown by rules, skills, MCPs, and subagents. If agents run slow or hit a full context window, this is the first place to look and the first thing 3.3 lets you actually see.

Pin your top three to five skills as Quick-Action Pills. No-brainer if you have invested in a custom skill library.

Pricing did not change in 3.3. Build in Parallel and Split PRs are available across plan tiers, though Enterprise teams will want to coordinate with admins on the May 4 admin controls release if you are gating async execution behind seat-level limits.

This post is part of Pondero's daily coverage of AI tool updates. See all coding guides.