Cursor Opens a Beta of Projects, Where a Coordinator Agent Directs Subagents

Cursor released a new feature called Projects in beta on September 10, 2026, and started rolling it out to all users the same day¹. Projects is meant for large units of work, such as a single feature, a migration, or an entire app. According to Cursor, a Project holds on to context across months, hands tasks to thousands of subagents, and carries out recurring work without waiting to be asked¹.

Cursor describes Projects as the concrete form of the “third era of software development” it outlined in February: a vision in which large groups of agents carry complete pieces of work from start to finish, and developers shift from managing individual agents to steering the work itself¹.

The Coordinator Does Not Write Code

The person using a Project talks to a coordinator agent assigned to that Project. The coordinator never writes code; instead, it gives instructions to the agents that write it¹. Cursor’s explanation is that because the coordinator only delegates, it never gets tied up and can respond to direction at any time.

Cursor names three capabilities behind this¹.

The first is “cloud by default, local when needed.” Each Project runs on its own computer, so shutting a laptop does not stop it, and it can run more subagents side by side than a local machine could. When something has to be checked on the user’s own machine, the coordinator launches a local agent there. The second is shared context. Every Project keeps a set of files that stays synchronized on each machine, whether in the cloud or local, that its agents work on. Agents add their findings, artifacts, what they have learned about the codebase, and how the user likes work done. Once one agent works out how to test a given service, later agents can reuse those steps. The third is Subscriptions: the coordinator can monitor a Slack channel, start on a schedule, or track every one of the user’s pull requests, fixing CI and reacting when PRs are opened or merged.

A Month of Updates, Now Bundled Into One Unit

Cursor has shipped a steady run of cloud-agent announcements over the past month. On August 17 it opened an early beta of Origin, its code hosting service, and on August 19 it added Subscriptions, which let cloud agents follow PRs and Slack and wake themselves up, along with dedicated virtual machines for subagents. August 27 brought a way to start a cloud agent without connecting GitHub, and September 2 brought self-hosted machines, which keep tool execution inside a company’s own network.

As of August 19, Subscriptions was a feature attached to individual cloud agents. In Projects, it becomes a capability of the coordinator, which sits above many subagents and a shared context that all of them read and write. Pieces that arrived separately are now grouped under a single unit, the Project. The blog post does not say whether Projects can run on self-hosted machines.

In the same week, OpenAI also released its Agents API in public beta, offering the Codex harness as a managed service. The two point in a similar direction, in that the tool provider takes over session management and delegation to subagents for long-running agents.

How Cursor Uses It Internally, and Tapering Off Review

Cursor says it has been using Projects internally for several months, including for migrations spanning a few hundred PRs, for keeping its design system consistent, and for shipping Projects itself¹. Its engineers’ usage falls into three patterns: feature work, migrations, and “gardening,” meaning maintenance work that never really ends.

The approach it describes for migrations is concrete enough to be useful when planning adoption. At the start, the user settles on a safe method with the coordinator and reviews each PR in detail. As the fixes prove reliable, review is scaled back and the coordinator continues the migration on its own. In the gardening example, one engineer runs a Project for the design system. At first the engineer checked each fix and corrected the wrong ones; now the coordinator goes through every new PR, pulls out components that belong in the design system, and adds a lint rule once it has seen the same mistake twice. Cursor says this Project is expected to touch 20 to 100 PRs a day¹.

On productivity, Cursor gives internal figures: merged PRs rise by 30% among people newly using it, and are six times higher among those who rely mainly on Projects¹. The baseline and the period behind these figures are not stated, and they come from Cursor’s own measurement, so they should be read with that in mind.

What to Decide Again Before Adopting It

Neither the blog post nor the changelog lists pricing¹². Since Projects runs many subagents in parallel, the only way to know how the compute will be billed is to check against your own plan.

Permissions and review also carry more weight than when agents were used one at a time. If the coordinator follows every PR and goes off to fix CI, you need to decide in advance which branches its subagents may push to and how far they may merge without human approval. Cursor’s own pattern of reducing review once things are stable also needs a definition of what counts as stable; without one, checks may simply fade away.

Running many agents in the same repository is itself known to be difficult. An experiment Anthropic published in August showed failure patterns in which similar agents reach the same decisions, including 18 of 30 agents creating the same branch name. Projects, with a coordinator assigning work and passing knowledge through shared context, can be read as placing the job of sorting out such collisions on the coordinator. During the beta, a practical approach is to start with a small migration and find out how much can be delegated in your own repository.

Sources

1. Introducing Projects - Cursor official blog (September 10, 2026)
2. Cursor Projects - Cursor official changelog (September 10, 2026)