Cursor Projects puts a coordinator over Cloud Agents, then keeps it running

Cursor launched Projects on September 10, 2026. The blog is the longer version of the same ship: a persistent project instead of a fresh chat per task, a coordinator that never implements the diff itself, and a cloud computer that keeps going when you close the laptop.

Cursor’s X thread is blunter about the habit it wants to break. Rather than creating a chat for every task, you work with a coordinator in a single persistent thread. Cursor compared that agent to an always-on bot: it manages work with subagents and is supposed to get better over time. A follow-up post said agents in a project share memory and generated artifacts such as plans and demos, and that those files sync across your device and the agents’ computers. A third post said it is beta and rolling out starting that day. That is a staged rollout, not a claim that every seat already has it.

What a Project actually is

Open Projects from the left-hand nav. The changelog’s definition is short enough to take literally. A Project is for a feature, a migration, or a full app. It keeps context over months of work, delegates to many subagents, and can do recurring work without a new prompt.

The coordinator is the product. It plans, creates and manages implementer agents, runs as many in parallel as the work needs, and brings finished work back for you to check. Cursor says it does not write code itself, which is why it can stay responsive while workers are blocked on tests or PRs.

Under the hood, Cursor says a Project is powered by Cloud Agents. Cloud Agents already run in isolated VMs with cloned repos, dependencies, secrets, and optional MCP. You can kick those from desktop, web, iOS, Slack, GitHub, Linear, or an API. Projects sit one layer up: one coordinator owns a body of work and spends Cloud Agents (and, when needed, a local agent on your machine) as labor.

That split matters. A Cloud Agent is still a worker you start. A Project is a loop you leave running.

Three mechanisms Cursor says make it work

Cloud by default, local when needed. The Project’s computer is in the cloud, so closing the laptop does not stop it. Cursor’s pitch is parallel capacity your laptop could not host. When something has to run on your hardware, the coordinator starts a local agent there. Do not flatten that into “everything is local” or “everything is remote.” Both are in the launch post.

Shared context. Each Project keeps a file set that syncs across every cloud and local machine its agents use. Agents add research, artifacts, and what they learn about the repo and your preferences. Cursor’s example: if one agent figures out how to test a service, later agents reuse those instructions. The X thread calls out plans and demos as files, not chat paste.

Subscriptions. Tell the coordinator to watch Slack, run on a schedule, or follow your PRs. The changelog’s Slack example is specific: connect Slack, point it at a bug-report channel, and it starts delegating when a bug comes in. The blog adds PR follow, CI fixes, and acting when PRs open or merge. That is Cursor describing the feature, not a third-party integration audit.

Cursor also points back to its February third-era essay: fleets of agents taking entire bodies of work. Projects is the company calling that vision shipped, in beta.

How Cursor says it uses this internally

The blog is unusually concrete about Cursor’s own usage. Treat the numbers as Cursor-reported.

It says new users merge 30% more PRs, and users who primarily use Projects merge six times as many. It does not publish the baseline, window, or whether that includes bot PRs. Do not treat it as an independent productivity study.

Three patterns:

Feature work. Agents research the system into shared context. The coordinator plans, then sends implement-and-test agents in parallel. After it ships, the same Project can watch logs and bugs with the original decisions still in context. When it is time to try the feature, the coordinator can run an agent on your computer.

Migrations. Cursor says it has used Projects for framework adoptions and styling-system replacements across hundreds of PRs. You lock a safe approach with the coordinator, then it applies that incrementally. Early PRs get close review; later ones get less, while the coordinator keeps walking the codebase.

Gardening. Work that never ends: quality, regressions, design-system drift. One internal example is a design-system Project that started with the engineer reviewing every fix. Cursor says it now scans every new PR, extracts components that belong in the system, and adds a lint rule when it sees the same mistake twice. The Project is “on track to touch 20 to 100 PRs a day.” That is an internal run-rate claim, not a promised quota for your repo.

What it is not

It is not Composer, and it is not Origin. AgentRiot already covered Composer 2.5 and Origin. Those are a model line and a git-forge bet. Projects is orchestration.

It is not OpenAI’s Agents API. That API rents you a Codex harness session (beta.agents.sessions) you embed in your own product. Projects is a Cursor product surface: left-nav, Slack, PRs, a coordinator that lives in the IDE’s world. Similar nouns (coordinator vs harness, sandbox vs VM). Different buyer.

It is not a documented per-seat price. Cursor’s public pricing page does not mention Projects. Cloud Agent compute still exists as its own surface. If a Project burns many parallel VMs, that cost sits in the Cursor plan or usage you already have. Measure it. The public pricing page does not list a Projects SKU.

Cursor’s Cloud Agent docs still say long-running is not available for multi-repo Cloud Agent environments. The Projects launch post does not repeat that limit. The workers are Cloud Agents, so VM setup, source-control admin, and network controls still apply.

Beta means the feature can be missing on your account today even though the blog says it is rolling out to all users.

When it is worth turning on

Use a Project when the unit of work outlives one chat: several PRs, a migration you will otherwise abandon at 60%, or a garden job you want handled while you are away. Start it from the left nav, describe the body of work, and treat the coordinator as staff, not as a completion engine.

Keep a normal Cloud Agent or a local chat when the job is one PR, one question, or a change you want to drive line by line.

The interesting claim is not “more agents.” Cursor already had parallel Cloud Agents. The claim is a durable coordinator, a shared file brain, and subscriptions that fire without you. If those three hold up in beta, Projects is the first Cursor feature that looks like a teammate with a backlog instead of a smarter text box. If they do not, you still have Cloud Agents. The coordinator is the part to test, not the word “thousands.”