Cursor Projects vs Background Agents

Cursor shipped Projects on 10 September 2026, and the first question in every thread about it was some version of cursor projects vs background agents: is this a new product or a rename of the cloud agents people already run? It's a new layer sitting on top of the old one. Background agents, now called cloud agents, are still the thing that writes the code. Projects is the thing that decides which agents to start, keeps what they learned, and carries on when nobody has asked it to.

Key Takeaways:

• Projects adds a coordinator agent that plans and delegates but writes no code itself
• Cloud agents stay exactly as they were: isolated VMs that clone a repo and produce merge-ready pull requests
• The genuinely new capabilities are persistent context across months and runs that trigger on a schedule, a Slack channel, or a PR
• Cursor's own framing is that "a Project runs on its own computer in the cloud, so closing your laptop doesn't stop it"
• It shipped in beta, rolling out to all users from launch day; cloud agents themselves bill at API pricing for the model you pick

What Cursor Projects actually is

The changelog entry is dated 10 September 2026 and opens without much ceremony: "Today we're launching Projects in Cursor. Projects lets you take on larger bodies of work, such as a feature, a migration, or a full app. It maintains context over months of work, delegates tasks to thousands of subagents, and performs recurring work without being prompted."

Three claims in that paragraph do real work, and they are not equally interesting. Delegating to subagents is table stakes now. Maintaining context over months is harder than it sounds and is the one most likely to disappoint in beta. Performing recurring work without being prompted is the one that changes what the tool is for, because it moves an IDE feature into the category of things that run while you are asleep.

You find Projects in the left-hand nav. Inside one, Cursor describes the arrangement plainly: "The coordinator agent in a project doesn't write code itself; it plans the work, delegates it to agents that implement it, and brings the finished work back to you to check." The coordinator creates and manages those agents for you, running as many in parallel as it judges the work needs.

Cursor projects vs background agents: what actually changed

Start with what did not change, because that is most of it. A cloud agent is still, per Cursor's documentation, an agent that runs "in isolated VMs in the cloud with full development environments instead of on your local machine." It clones your repo, installs dependencies, has network access, and it ends its life by producing "merge-ready PRs with artifacts to demo their changes" including screenshots, videos and logs. You can run as many in parallel as you want, and they do not need your laptop connected. That was true before Projects and it is true after.

Billing is unchanged too: cloud agents are charged at API pricing for the model selected, and Cursor asks you to set a spend limit the first time you use them. You need a paid Cursor plan. None of that moved.

What Projects adds sits above all of it, in two pieces.

The first is memory that outlives a task. A single cloud agent has always been amnesiac by design; it wakes up, clones, works, opens a PR, and dies, taking everything it figured out about your codebase with it. Cursor's answer is a shared context that lives at the project level, synchronised across every machine its agents use, with each agent's research feeding back in. Their phrasing is that "the shared context grows with the Project, making the coordinator more effective over time." Whether that holds up over the months they are advertising is the single thing worth testing before committing a migration to it.

The second is that Projects can start work on their own. You can subscribe a Project to a Slack channel, put it on a schedule, or point it at pull requests, and it acts without anyone typing a prompt. That is the line where the comparison stops being a comparison, because a background agent has never been able to do anything until a human asked.

The coordinator is the part to watch

A manager that doesn't do the work is a familiar idea and a hard one to get right. The coordinator's job is decomposition, and decomposition is where multi-agent systems usually fall apart: split a migration wrong and you get eleven parallel agents confidently editing the same four files in incompatible directions, then a pile of pull requests nobody can review.

Cursor has hedged this sensibly by keeping a human in the loop at the end. The coordinator "brings the finished work back to you to check," which is the right default for a beta, and is also an admission that review load is the real bottleneck. Running a thousand subagents is easy. Reading what a thousand subagents produced is not.

The context claim deserves the same skepticism. "Months of work" is a strong promise, and every system that has made it so far has run into the same wall: shared memory that grows without pruning eventually poisons the thing it was meant to help, because a decision that was right in July becomes a confidently repeated mistake in September. Cursor has not published how the project context is compacted, weighted, or expired. Until they do, the sane test is to run a Project alongside work you would have done anyway for a few weeks and check whether the coordinator's suggestions improve or merely lengthen.

There is one detail in the launch text that quietly marks the boundary of the whole design. "When something needs testing on your machine, the coordinator spins up a local agent to run it there." Everything that can happen inside a cloned repository happens in the cloud; everything that needs your actual environment comes home. That escape hatch tells you where the cloud half stops.

Where a repo-shaped agent stops

Cursor's design assumption is that the unit of work is a repository and the unit of output is a pull request. For writing software, that assumption is correct and it is why the product works. It also means a large category of work sits outside the boundary entirely.

Think about what usually surrounds a migration. Somebody has to read the vendor's dashboard to confirm the old endpoints are actually retired, export a report, check whether the staging billing account got charged, file the ticket, and answer the email asking whether Thursday still works. None of that lives in a repo, so none of it is a pull request, so no cloud agent can close it out. That is the gap Zentor covers: a hosted cloud AI computer with a real desktop and its own logins, which means the parts of the job that happen in a browser and an inbox have somewhere to run that is not your laptop.

The two fit together rather than competing. Cursor's coordinator is better at your codebase than a general-purpose machine will ever be, because it was built for exactly that and it has the repo mounted. Zentor runs beside it for everything with no repo attached, and because it is a hosted environment rather than a process on your machine, a job started from a laptop is still going when you pick it up on a phone. Free access runs three days on 1,000 credits and the $20 plan renews 1,000 credits a month, which is enough to find out whether the non-code half of your week is automatable before deciding anything.

Worth being clear about what this launch means competitively, since it would be silly to pretend otherwise. When Cursor writes that closing your laptop doesn't stop the work, they are making the same argument for hosted execution that Zentor has been making, and they are making it to a few million developers. That is a good week for the premise. The disagreement is only about scope: Cursor put a cloud computer behind an IDE, and we think the computer should not be behind anything in particular.

Who should turn this on now

Turn it on if you have a genuinely long-running piece of work with a clear finish line and a codebase big enough that context is the expensive part. A framework upgrade across a monorepo is the canonical case. So is a migration you have been putting off for two quarters precisely because nobody can hold the whole thing in their head.

Leave it alone if your work arrives as a stream of small unrelated tickets. A coordinator adds planning overhead that only pays back when the plan is worth making, and for a two-file bug fix you are better off with a plain cloud agent or the editor you already have open. The older head-to-head between cloud agents and always-on assistants still applies to those, and the broader trend lines across Cursor, Copilot and Claude Code have not been redrawn by one launch.

One more thing that is easy to miss on day one: the coordinator decides how many agents to run, and you are paying for every one of them at API rates. Parallelism that a human would never have chosen is the default failure mode of a system rewarded for finishing quickly, and the bill arrives regardless of whether the eleventh agent contributed anything. Watch the first few runs rather than trusting the plan.

And treat the beta label as load-bearing. Scheduled autonomous runs against a real repository, billed at API pricing, is a combination that deserves a spend limit set deliberately rather than accepted at the default.

FAQ

Is Cursor Projects the same as background agents?

No. Background agents, now cloud agents, are the isolated VMs that clone your repo and open pull requests. A Project is a layer above them that plans work, delegates to those agents, keeps context between runs, and can start work on a schedule without a prompt.

In cursor projects vs background agents, which one writes the code?

The agents do. Cursor states that the coordinator agent "doesn't write code itself" and instead plans, delegates, and returns finished work for you to review.

Does a Cursor Project keep running when I close my laptop?

Yes. Cursor says a Project runs on its own computer in the cloud, so closing the laptop doesn't stop it. Tasks that specifically need your machine are handled by a local agent the coordinator starts for that purpose.

What does Cursor Projects cost?

Cursor has not published separate Projects pricing. The underlying cloud agents are billed at API pricing for whichever model you select, and a paid Cursor plan is required. Set a spend limit before running anything scheduled.

Can a Project start work without me asking?

Yes, and this is the main behavioural change. Projects can subscribe to a Slack channel, run on a schedule, or watch pull requests, then act on their own.

Is Projects available to everyone?

It shipped in beta on 10 September 2026, rolling out to all users from that day. Rollouts land in waves, so a missing nav item most likely means yours has not arrived yet.

Feature descriptions and quoted wording were read from Cursor's changelog entry of 10 September 2026 and its cloud agents documentation, both checked on 11 September 2026. Pricing for Projects specifically had not been published at the time of writing.