Cursor 3 shipped parallel Composer 2 agents and a first-class background agent on 2026-04-02. The launch-week threads on r/cursor and Hacker News split predictably: workflow people called the parallel queueing the first IDE-side win in three quarters, model people pointed out the per-task scores did not move. Both are correct. The TCC editorial fixture (200 queued agent pairs, 14-task scorecard, 1,400-chunk RAG corpus) measures the same gap: parallelism is real, the per-task quality is flat against Cursor 2.9.
What changed
- Queuing a second Composer run in the same workspace no longer cancels the first. In Cursor 2.x, this killed the first run on a small but meaningful percentage of queued pairs; in Cursor 3 it did not happen once across 200 queued pairs in the TCC editorial fixture. The behavior change is documented in the Cursor 3 release post.
- The background agent completes a 63k-line TypeScript rename in 3:12 while the editor stays responsive. Memory footprint peaks at 2.4 GB, up from 1.6 GB on 2.9. The trade is real: the agent runs out-of-band, the editor pays the RAM cost.
What did not change
- Refactor score on the TCC 14-task suite: 8.1 on Cursor 3, 8.1 on 2.9. The parallelism is a workflow win, not a per-task quality win.
- RAG score stayed flat at 7.9 out of 12 on the 1,400-chunk fixture with the default chunker. The chunker setting is still not exposed in the UI; bumping it to 768/128 requires editing
settings.json. See the Cursor 3 shortcuts cheatsheet for the relevant keys. - Tab autocomplete acceptance rate moved from 31% to 44% on TypeScript per the Cursor blog’s published numbers; on Python it is roughly flat. This is a separate Composer 2 underlying-model change, not a parallel-agent story.
- Team admin features are still the Cursor advantage over Windsurf 2.0. Cursor 3 did not change that in either direction; the recurring r/cursor “Cursor vs Windsurf for teams” thread still lands in the same place.
The implication
Parallel agents change how work is sequenced, not how good the work gets. A team already shipping one PR a day with Cursor 2.x can ship two now without context-switching. A team where a single PR per day was already slow because the model itself was the bottleneck does not see help here. The numbers that move that bottleneck are in model scores, not IDE features. See the Claude Opus 4.7 review for where the model-side bar moved in April 2026.
What the threads are saying
The most-upvoted Hacker News thread on the launch converged on “this is the first Cursor release in three quarters where the IDE polish caught up with the model polish”. r/cursor is loud about the .cursorrules migration tripping people up on upgrade; the fix is in the official Cursor docs, which now point to .cursor/rules/*.mdc as the supported path. The Cursor blog’s 3 post flags the indexer speedup (2x cold start) and the disk trade (1.6x index size).
Related
The full review with all 14-task scores is on the Cursor 3 + Composer 2 review. The keybindings and settings that matter are on the Cursor 3 shortcuts cheatsheet. The case for keeping a human at the merge boundary, even with parallel agents, is the case against autonomous agents.
One-line takeaway
Parallel agents change sequencing, not task quality. If the bottleneck was scheduling, the cost just dropped. If the bottleneck was correctness on refactor 14 of 14, the bare-model reviews are still the place to look.