Hi, this is Hoda.
“Projects,” the new feature Cursor announced on September 10, 2026 (US time), isn’t just an extension of the existing Agent Mode and Plan Mode — it’s a feature that breaks the very idea of “one chat” as the unit of work. To cut to the conclusion, the difference comes down to this:
- Agent Mode / Plan Mode / Ask Mode → mode switches that decide how a single Agent behaves within one chat (one session)
- Cursor Projects → a management layer that sits outside the “chat” unit entirely and holds an entire piece of work over the long term
Let’s dig into that difference in more detail below.
Overview of Cursor Projects
Projects is built for big pieces of work that span weeks or months — feature development, migrations, or building out an entire app. You start a Project from the left nav, tell it what you want built, and from there an agent called the “coordinator” takes over.
It runs via a cloud agent rather than from the IDE, so you open the Agent Window first and select it from there.
You can create a new one like this:
The important part is that the coordinator itself never writes any code. Its job is strictly to plan, delegate the actual implementation to separate subagents running in the cloud, and hand the finished work (a draft PR) back to you for review. Because it’s never blocked waiting on execution, it can always respond to whatever additional instructions you send it.
It runs in the cloud, so it keeps working toward the goal automatically even after you close your laptop.
Three mechanisms sit underneath Projects.
-
Work doesn't stop when you close your laptop (cloud execution by default)
-
Shared files build up per Project and carry over to the agent on the next task, too
-
It can kick itself off — watching Slack, tracking PRs, running on a schedule — without you having to prompt it
-
Well suited to work that can't finish in a single chat, like a migration spanning hundreds of PRs
-
Because the coordinator delegates to multiple subagents in parallel, token usage scales up roughly with the number of agents
-
It's still in beta, so Projects-specific pricing and any concurrency limits haven't been published
-
It raises the review burden on your side, since multiple draft PRs can come back at once
-
For a small, one-off fix, regular Agent Mode is still faster and cheaper
How it differs from Agent Mode / Plan Mode / Ask Mode
This is probably the part you’re most curious about, so here it is as a table.
| Ask Mode | Agent Mode | Plan Mode | Cursor Projects | |
|---|---|---|---|---|
| Who writes the code | No one (read-only) | The Agent implements directly | The Agent implements after you approve a plan | The coordinator never writes code — a delegated subagent implements it |
| Unit of work | One exchange | One task / one chat | One task / one chat | A feature, migration, or whole app (can span multiple PRs) |
| How long it runs | Only during the session | Only during the session | Only during the session | Weeks to months |
| Where it runs | Local (inside the editor) | Local, or launched as a Cloud Agent | Local | Cloud by default; spins up a local Agent only when needed |
| Context | Gone once you close the chat | Same (separate things like .cursor/rules persist) | An approved plan can be saved as Markdown | Accumulates in Project-specific shared files that carry over to the Agent on the next task |
| What kicks it off | A person prompts it each time | A person prompts it each time | A person prompts it each time | A person’s instruction, plus autonomous starts from Slack, PRs, or a schedule (Subscriptions) |
| Best suited for | Understanding code, asking questions | Mid-sized implementation or fixes | Complex features with multiple possible implementation approaches | Long-running feature development, large migrations, ongoing maintenance |
In other words, the difference between Agent Mode and Plan Mode is really just a difference in the steps within the same single task — whether you insert a plan-approval step before implementation or not.
Projects, on the other hand, removes the premise of “a single task” altogether, and brings a whole system of approval, delegation, and memory to bear on something much bigger: a “piece of work.” If the plan you build in Plan Mode is a blueprint for one task, the shared context in Projects is closer to an operating manual that keeps growing for as long as the project continues.
The three core mechanisms, in a bit more detail
Cloud execution (cloud by default, local only when needed) A Project runs on a dedicated cloud environment, so work keeps going even while your own machine is asleep. The coordinator only spins up a local Agent when a test genuinely has to be reproduced locally.
Shared context Each Project keeps a set of files that stay synced across every agent working on it, cloud and local alike. Once one agent works out how to test a service, every agent after it can reference the same files and follow the same steps. The idea is that the more this accumulates, the more accurate the coordinator becomes over time.
Subscriptions You can set watch conditions — a specific Slack channel, a PR being opened or merged, a fixed schedule — and once a condition is met, work starts without waiting for a person to give further instructions.
The foundation for this is Cloud Agent’s monitoring feature (Automations); Projects can be thought of as folding that capability under the coordinator and combining it with shared context.
What kind of work it’s suited for
Cursor itself calls out three use cases:
- Feature development: the same Project owns the whole arc — research, planning, parallel implementation and testing, and even post-release bug fixes — while holding onto context the whole way through
- Migrations: work that’s “easy to start but hard to finish.” You review each PR strictly at first, then hand more and more of it over to the coordinator as things stabilize
- Gardening: ongoing quality upkeep and regression monitoring that never really ends. The idea is to continuously scan new PRs, and if the same mistake keeps showing up, have it add a lint rule to catch it going forward
Put the other way: if you’re just fixing the color of a single button, there’s not much point opening a Project — regular Agent Mode is plenty.
Pricing
As of September 2026, Projects itself doesn’t have a separate price tag — it’s offered as a beta feature to users on a paid plan. That said, since it runs on the Cloud Agent infrastructure, you’re still on the hook for whatever API pricing applies to the model you’ve chosen. Cursor itself notes that running, say, five subagents in parallel means roughly five times the token usage by simple arithmetic — “thousands of subagents” is described as an upper ceiling, not something every job actually needs.
Things worth checking before you adopt it
- Start with a single repository and a single kind of task first
- Keep production releases and anything billing-related outside the scope of automatic permissions
- Review your shared-context files periodically — stale instructions left in there can cause the same wrong call to get repeated
- Keep the trigger conditions for Slack- or schedule-based starts narrow, and watch for false triggers
- Don’t relax the assumption that everything comes back as a draft PR — keep merge rights in human hands
Summary
- Agent Mode / Plan Mode / Ask Mode are “modes” that decide how a single Agent behaves within one chat
- Cursor Projects is a separate layer that manages an entire “piece of work” — spanning multiple PRs or tasks — over the long term, using a coordinator and shared context
- The biggest difference between the two comes down to who implements the work: “the person you’re directly talking to” (Agent Mode) versus “a delegated subagent” (Projects)
- It’s a good fit for feature development, migrations, and ongoing maintenance. For a small, one-off fix, regular Agent Mode is still all you need
I’ve covered Plan Mode in more detail in a separate article on the site, so check that out too if you’re interested.
