Cursor Projects Turns One Agent Into a Coordinator for Thousands. Here's What Changes If You Use It.

What happened

Cursor launched Projects on September 10, rolling out in beta to all users of its AI coding tool. The company’s editor is where you chat with an AI agent to write, edit, and run code instead of typing every line yourself.

Until now, working with Cursor meant chatting directly with one agent about one task at a time. Projects adds a layer above that: you describe a larger body of work, like a feature, a full migration, or an entire app, and a coordinator agent takes it from there. The coordinator doesn’t write code itself. Instead, it breaks the work into pieces and directs other agents, called subagents, to do the actual coding, testing, and fixing.

Three things make this possible, according to Cursor. A Project runs on Cursor’s own servers by default, not just your laptop, so it keeps working after you close your laptop and can run far more subagents at once than your machine could handle alone. When something needs to be tested on your machine specifically, the coordinator can still spin up a helper there. Second, each Project keeps a shared set of files that every agent working on it can read and add to, so a new subagent doesn’t need to be walked through your codebase from scratch the way a new hire would. Third, you can set up what Cursor calls subscriptions: instructions for the coordinator to watch a Slack channel, run on a fixed schedule, or watch your pull requests (proposed code changes waiting for review before they merge into your project) and act automatically when one opens or merges, including fixing failing checks.

Cursor says internal users saw real gains from this: people trying Projects for the first time merged 30% more pull requests than before, and people who use Projects as their main way of working merged six times as many. The company hasn’t published pricing details specific to Projects, so it isn’t clear yet whether heavier subagent usage costs more than working with a single agent the normal way.

Why it matters

The shift here isn’t a smarter agent. It’s a change in what you personally have to manage. Chatting with one agent means you’re still the one deciding what to work on next, reviewing each step, and keeping track of what’s in progress. A coordinator that runs on its own schedule and reacts to Slack messages or pull requests removes you from that loop by design, that’s the whole pitch: you set the direction once, and work keeps happening without you prompting it again.

That’s also the part worth being careful with. This launch lands a little over a week after BuilderWithin covered OpenAI’s decision to cut Cursor off from its direct model access following SpaceX’s acquisition of the company, a reminder that Cursor’s underlying setup has been shifting even as it ships ambitious new features. An agent that can act on your repository (the stored history of your project’s code) without a prompt from you each time, including merging or fixing pull requests automatically, has more room to cause damage before you notice than an agent that only responds when you type something. If a subscription is set up to act on every pull request that opens, and the coordinator misreads what “fixing CI” (the automated checks a project runs before code is allowed to merge) should mean for your specific project, it can make a change and merge it before you’ve seen it.

Who should care

Anyone using Cursor for work that spans more than one sitting, a feature that takes a few days, a migration touching many files, or recurring maintenance you currently do by hand. If you’ve been manually re-explaining your codebase to a fresh chat every time you start a new session, the shared context Projects keeps between agents is aimed directly at that annoyance.

It matters less if your Cursor use is mostly quick, one-off edits you review immediately. Adding a coordinator and subscriptions on top of that kind of work is more setup than the task needs.

What builders should do next

Before turning on any subscription that acts automatically, especially one tied to pull requests or a schedule, run it in a mode where it can only report back, not merge or push changes on its own. Cursor’s own shared-context files give you a way to check this: after a few cycles, read through what the coordinator recorded about what it did and why, before you let a subscription act without your review in the loop.

If you want to compare Projects against how you work today, pick one bounded, real task you’d normally do yourself over a few sessions, for example adding a small feature and its tests across three or four files. Do it once the normal way, chatting with a single agent step by step. Then do a similar-sized task once through a Project instead, coordinator and subagents. Compare four things: how many times you had to correct a subagent’s work after the fact, how long the whole task took from start to a version you’d actually ship, how much of your Cursor usage allowance each approach consumed, and how easy it was to recover when something went wrong. Cursor’s own 30% and six-times figures come from its internal usage, not from a controlled test, so treat them as a starting expectation, not a guarantee for your own codebase.

End of article