Cursor launched Projects on September 10, 2026, and the most interesting detail is a constraint: the coordinator agent in a project does not write code itself; it plans the work, delegates it to agents that implement it, and brings the finished work back to you to check. A planning agent that is deliberately forbidden from touching files is an unusual design choice. It is also a deliberate response to a real problem with how coding agents have worked so far.
What the coordinator agent actually changes
Single-agent sessions fail at scale not because the model is bad, but because context windows get crowded. The coordinator-worker pattern exists because single agents lose accuracy as context windows grow-a problem sometimes called context rot. Cursor's answer is architectural separation: one agent holds the plan and the long-running project state; separate subagents each take a scoped task with a clean context.
Instead of opening a fresh chat for every task, you work in one persistent thread with a coordinator agent that plans a large body of work and hands the actual coding to a fleet of subagents running in parallel, mostly in the cloud. The coordinator itself runs on a cloud machine, which matters for a concrete operational reason: the coordinator runs on a cloud machine and keeps working when the developer's laptop is closed, decoupling agent throughput from human availability.
The other piece that actually matters here is subscriptions. You tell the coordinator agent to watch a Slack channel, run on a schedule, or follow all your PRs, and it starts delegating each time a matching signal arrives - for example every time a bug report comes in. That is a different model from "open a chat, get an answer, repeat." The coordinator wakes itself up.
OpenAI's public beta Agents API and Cursor's new Projects feature both launched September 10, converging on the same coordinator-worker architecture: a coordinator manages the overall objective while specialized subagents execute individual pieces. When two major labs ship the same pattern on the same day, it is less a coincidence and more a signal about where the ceiling on single-agent systems has landed.
The 6x PR number and what it leaves out
Engineers who used Cursor Projects as their primary workflow merged six times as many pull requests as those who did not, per Cursor at the September 10 launch. New users who ran Projects alongside the standard IDE merged 30% more PRs.
Take the 6x figure seriously as a direction, less seriously as a measurement. The 6x merge-rate figure is self-reported; practitioners note setup overhead makes Projects worthwhile only for multi-PR features and migrations, not quick one-shot tasks. That is consistent with what the architecture actually does well: it is genuinely useful for work that outlives a single chat - big features, long migrations, and never-ending maintenance.
The cost question is real and under-discussed in the launch coverage. The cost model is the catch. You pay API rates for every subagent, and a coordinator spinning up many of them in parallel is a metering question, not free productivity.
To make that concrete: look at what the underlying models cost per completed task. On Terminal-Bench 4.0, Codex with GPT-6 Astra scores 58.2% and Claude Code with Fable 5.1 scores 57.9%. Codex reached 57.9% at $7.12 per task; Claude Code with Fable 5.1 needed $14.76 for the same score. A coordinator spinning up ten parallel subagents for a migration is not ten conversations at $0.10 each - it is closer to ten resolved tasks at $7-$15 each, depending on model and effort level.
How the coordinator pattern fits into the broader agentic coding landscape
GitHub Copilot Workspace, Devin, OpenHands, and Claude Code are all converging on coordinator-plus-subagent primitives; Cursor's advantage is execution pace, not novel architecture. So the coordinator agent is now a pattern, not a product differentiator. What differentiates tools is how they handle the seams: shared context between agents, cost metering, and what happens when a subagent fails mid-task.
Cursor's answer to shared context is explicit:
each Project keeps a set of files that sync across every cloud and local machine its agents use, so research and notes about the codebase build up instead of disappearing at the end of a session.
That is closer to a first-class project memory layer than to the ad-hoc .cursor/rules files most teams were maintaining by hand before this.
On the model side, the landscape moved again on September 22. Anthropic shipped Claude Opus 5.5 and made it the Claude Code default the same day. OpenAI answered with GPT-6 Sol and GPT-6 Luna, halving the token price of its mid and low tiers.
Codex's recommended model now costs half of Claude Code's per token. Anthropic reports Opus 5.5 at 66.4% on Terminal-Bench 4.0 against GPT-6 Astra's 57.9%. The benchmark lead is real, but whether it justifies the per-task price delta depends on task type. Well-specified tickets and CI scripting go to Codex, where $8.39 per resolved task beats $11.84 when both models resolve at the same rate. Repo-wide refactors and open-ended investigations go to Claude Code, where an Opus 5 lead with Sonnet 5 workers fans out across the codebase and agents hand findings to each other instead of requiring re-explanation of context.
When the coordinator model actually earns its overhead
The coordinator pattern introduces real setup cost and real per-subagent billing. It earns those costs under specific conditions.
- Multi-PR features: work that will produce four or more pull requests, where keeping the coordinator's shared context file is cheaper than re-establishing it in each session
- Long migrations: the classic case where one developer would spend two weeks doing careful, repeated groundwork; a coordinator running overnight can compress that
- Event-driven maintenance: a Slack bug-report channel where the coordinator dispatches a subagent per incoming ticket, without a human in the loop for triage
It does not earn its overhead for:
- Quick one-shot fixes where the full task fits in a single agent session
- Exploratory work where the goal is still being defined - coordinators need a clear objective to delegate against
- Teams without metering visibility into per-subagent token spend (the bill surprise is real)
A teammate like Beagle can help here at the handoff point - surfacing a completed coordinator run's PR summary into the right Slack thread so the reviewing engineer has context before opening GitHub.
Beagle in action#eng-migrations, 7:42amThe coordinator agent is the right structural answer to a real technical problem. The cost model is not yet simple enough to ignore. Run the per-task numbers against your actual task mix before assuming the productivity headline applies to your team.
Cursor coordinator agent: common questions
What is a coordinator agent in Cursor Projects?
A coordinator agent in Cursor Projects is a persistent, cloud-hosted planning agent that breaks a large goal into tasks, delegates each to separate coding subagents, and returns finished pull requests to the developer for review. It does not write code itself. Setup takes roughly five minutes from the Projects panel in the Cursor IDE.
How much does Cursor Projects cost?
There is no separate price for Projects
- it bills through your existing Cursor plan and API token consumption. The real cost is per subagent task: independent benchmarks put flagship-model tasks at $7-$15 each depending on effort level and model. A coordinator spinning ten parallel subagents on a migration can run $70-$150 for a single session's work.
Is the coordinator-agent pattern unique to Cursor?
No. OpenAI's public beta Agents API and Cursor's Projects feature both shipped on September 10, converging on the same coordinator-worker architecture. Claude Code's Agent Teams, GitHub Copilot Workspace, and Devin all use similar planner-worker splits. Cursor's differentiation is integration depth and the Slack subscription trigger, not the core architecture.
When should I use Claude Code instead of Cursor Projects?
Repo-wide refactors and "figure out why this is broken" investigations suit Claude Code, where an Opus 5 lead with Sonnet 5 workers fans out across the codebase and agents hand findings to each other instead of requiring context to be re-explained. For well-scoped, terminal-executable tasks where cost per task matters, Codex within Cursor is the cheaper route to equivalent benchmark performance.
What is "context rot" and why does it matter for coding agents?
Context rot is the accuracy drop that occurs when a single agent's context window fills with accumulated task history, making earlier information less influential over model outputs. This is the core reason the coordinator-worker pattern emerged: single agents lose accuracy as context windows grow. The coordinator-subagent split keeps each worker's context narrow and fresh, while the coordinator holds the long-lived project state separately.