What Cursor Shipped
On September 10, 2026, Cursor launched Projects in beta — the company’s biggest shift from “AI coding assistant” to “agent orchestration platform.” A Project is a long-running body of work (a feature, a migration, a whole app) managed by a coordinator agent that plans the work and delegates implementation to subagents running in the cloud. The coordinator doesn’t write code itself; it directs agents that do.
The work keeps going after you close your laptop. Each Project runs on its own dedicated cloud computer, and the coordinator can spin up local agents when a task needs your machine. Rolling out to all users in beta — no separate signup beyond the Cursor app.
How It Works
One coordinator, many subagents
The coordinator plans the work, creates and manages subagents, delegates implementation and testing, and brings finished work back for your review. Cursor’s framing puts the fan-out at “thousands of subagents” running in parallel. Treat that number as marketing direction rather than a number you’ll hit on day one — but the architecture genuinely supports wide parallelization.
Shared context that accumulates
Every Project keeps its own files, synced between cloud and local machines. Agents contribute research, artifacts, testing strategies, and lessons about the codebase as they work — so when agent #47 starts, it inherits what agent #3 learned about testing the payment service. This attacks the most annoying weakness of coding assistants: every new chat starting from zero.
Subscriptions: work that starts itself
Projects can initiate work from external signals Cursor calls subscriptions. The coordinator can watch a Slack channel for bug reports, follow all your pull requests, react to CI failures, or run on a schedule — then wake up, delegate, and report back without being prompted. Point it at the repo’s PR queue and it keeps triaging after hours.
Guardrails
Cursor blocked autonomous pushes to main branches — the coordinator proposes, humans dispose. That’s a deliberate trust-building choice: the biggest adoption barrier for autonomous coding isn’t capability, it’s whether teams believe the output.
The Productivity Claims (Read Carefully)
Cursor says users who primarily use Projects merge six times as many PRs, and that new users merge 30% more PRs. These are Cursor’s own numbers, published without baselines, cohort sizes, or time windows — unaudited vendor claims. The direction is plausible (parallel agents do produce more output), but “6x” describes Cursor’s heaviest adopters, not what you’ll get on your first project.
The honest way to think about it: Projects multiplies output volume. Whether that volume is good depends on review. At high fan-out, the bottleneck moves from writing code to reviewing it — someone still has to decide whether the work that came back is correct. Budget reviewer time, not just agent time.
The Pricing Gap
Cursor did not disclose pricing for Projects at launch and gave no date for the beta rollout finishing. That’s the biggest open question: coordinator-plus-subagents architectures consume significant compute, and how Cursor meters it (per subagent? per task? bundled into existing tiers?) determines whether this is economical for a freelancer or only for funded teams.
Until pricing is public, treat Projects as a powerful beta to learn — not infrastructure to bet a business on.
Cursor Projects vs Claude Code Projects
Anthropic redesigned Claude Code Projects a week later (September 17) around the same coordinator concept. Key differences:
| Cursor Projects | Claude Code Projects | |
|---|---|---|
| Coordinator | Plans, delegates, doesn’t code | Scopes, delegates, assembles |
| Worker isolation | Cloud computer + local agents | Own git branch + repo copy per thread |
| Collision model | Shared files, synced context | Git merge conflicts |
| External triggers | Subscriptions (Slack, PRs, schedules, CI) | Goal-driven threads |
| Pricing | Undisclosed | Usage-metered per thread |
| Availability | Beta, rolling out to all | Beta, Pro/Max first |
Cursor leans toward autonomous, always-on operation (subscriptions reacting to signals); Claude Code leans toward git-native engineering workflows. If your work is PR-queue-driven maintenance, Cursor’s model fits. If it’s branch-based feature development, Claude Code’s model fits. Our Claude Code Projects breakdown covers the Anthropic side in depth.
Getting Started Sensibly
- Start with a bounded project. A well-defined migration or a single feature — not “rebuild our backend.” Learn the coordinator’s planning quality on something reviewable.
- Write good project context. The shared files are the coordinator’s brain. Seed them with architecture notes, conventions, and testing instructions before delegating.
- Set up one subscription. A Slack bug-report channel or the PR queue is the natural first autonomous trigger. Watch what it does for a week before adding more.
- Protect main. The autonomous-push block is on by default — keep it that way until you’ve reviewed enough agent output to trust the pattern.
- Track the real metric. Not PRs merged — PRs merged without rework. That’s the number that tells you whether the fleet is helping.
For the broader AI coding landscape, our Muse AI account guide covers getting started with generous free tiers.
What “Thousands of Subagents” Means in Practice
Let’s be honest about the flagship number. “Thousands of subagents” describes architectural capacity, not a recommended operating point. In practice, your effective fan-out is bounded by three things:
- Review bandwidth. Every subagent’s output needs human review before it merges. Ten parallel agents producing PRs is already a full-time review job. A thousand would need a review organization, not a reviewer.
- Task independence. Real codebases have coupling. The more agents touch shared code, the more their outputs conflict — and conflict resolution is serial work that eats the parallel gains.
- Cost. Until Cursor publishes metering, wide fan-out is an unknown bill. The rational move is narrow pilots with measured review cost, then scale.
Cursor’s own best example is telling: an internal design-system Project “on track to touch 20 to 100 PRs a day.” That’s impressive, but notice it’s a design system — the most parallelizable codebase shape there is (independent components, clear interfaces). Your monolith with shared state won’t fan out the same way. Match the tool to the codebase shape.
The September 2026 Wave in Context
Projects didn’t ship alone. The same September wave brought Rollouts (deployment monitoring that opens revert PRs on regressions), Security Review (automated exploit detection on every PR), and self-hosted machines (code never leaves your network). Read together, the wave’s thesis is clear: Cursor is building the full software lifecycle — write, review, deploy, monitor, secure — with agents at every stage and the IDE as just one interface.
For a freelancer or small team, the immediately useful pieces are Projects (for migrations and multi-part features) and Security Review (free automated scrutiny on every PR). Rollouts and self-hosted machines matter once you’re shipping to production with real users.
Official source: Cursor
Frequently Asked Questions
What is Cursor Projects?
A beta feature (launched September 10, 2026) where a coordinator agent plans long-running engineering work and delegates to subagents on cloud computers, with shared context and autonomous triggers.
How much does Cursor Projects cost?
Undisclosed at launch. Cursor hasn’t published pricing or metering details — the biggest open question about the feature.
Do the subagents write code without supervision?
They write code, but autonomous pushes to main branches are blocked. Finished work comes back for human review, and humans merge.
What are subscriptions in Cursor Projects?
Autonomous triggers: the coordinator watches a Slack channel, PR queue, CI failures, or a schedule, and starts work on its own when signals arrive.
Is Cursor Projects better than Claude Code Projects?
Different designs for different workflows. Cursor emphasizes always-on autonomous operation with external triggers; Claude Code emphasizes git-native parallel threads with merge-conflict collision handling. Many teams will end up using the one matching their existing workflow.
Should I trust the “6x more PRs” claim?
It’s Cursor’s own unaudited figure for its heaviest adopters, published without methodology. Expect real productivity gains, but measure PRs merged without rework on your own team before believing any multiplier.