I have to admit right away that this is a solution I’d love to see in Claude Code or Codex. I have no intention of switching to Cursor, but my first use convinced me that this is a very good idea, provided it’s executed well. Why?
You quickly recognize the common weakness of Claude Code and similar development environments. You’re working on a task, but the AI agent takes many minutes to respond. Either you wait, or you want to work on another task in the project. But when you give a new instruction, you either interrupt the work or pollute the project context, and you end up working needlessly expensively, usually both at once. So you open a new terminal window, explain everything again, and start working, only to discover half an hour later that the task in the other window finished long ago and has been waiting. The result? You start fiddling with multiple terminal panes side by side so you can see what finished where, and you begin jumping from one task to another. Now and then you mix up the windows, so you enter a prompt into the wrong project, and so on. Quite the frustration.
A whole range of tools has tried to solve this, but so far mostly unsuccessfully, partly because they lacked good integration with the development tool. And people don’t want to move away from their tool just because somebody somewhere vibe-coded some new helper scripts. I’ve seen a solution from Kimi that looks more like a kanban board (similar to Kilo from Amazon), and Tencent recently came up with a relatively interesting proposal, but everything is shaky. Then, a month ago, I saw Grok Bot and told myself that this was exactly the solution that would make sense for the average user.
Meanwhile, Grok Bot has gone through explosive growth in interest, and the approach is proving itself. So it’s no surprise that this approach has now appeared in the Cursor development tool, which SpaceXAI (the operator of Grok) recently bought for $60 billion. It’s called Cursor Projects and it’s still in beta. Why isn’t it surprising? The author of Grok Bot is the very team that builds Cursor.
Cursor Projects
How do Projects work? You give all your instructions in a single window; you don’t have to open more. The Coordinator window doesn’t write code itself, it splits tasks among separate agents. And because it only delegates the work, you never have to queue up to talk to it. You give it a task and it answers immediately. The waiting moves one layer down: of course it won’t deliver the task instantly, but it keeps track of when each thing finishes and works on it together with you.
Shared context is the heart of the matter. Each project keeps a set of files that are synchronized to all the machines where its agents run. The agents write into them what they’ve found out: how tests are run, where a given service is configured, how you want your PRs put together. The next agent reads it before starting. That eliminates the cold start, because of which you currently explain the project from scratch in every new window. From my point of view, this is the real novelty of the whole release, and everything else is just operational plumbing.
Cloud as the default, local machine on request. A project runs on its own virtual machine in the cloud, so closing your laptop doesn’t stop it, and it can run more agents in parallel than your machine could handle. Flavio Copes, who described the product a day after launch, says that each subagent can get its own virtual machine with a clean copy of the repository. When something needs to be verified at your place, say a test that depends on a local database, the coordinator launches an agent on your computer. On top of that come subscriptions: the coordinator can watch your PRs (opening, merging, failing CI, review comments), a Slack channel, or simply a schedule, and it acts on its own when something happens. It’s worth mentioning that neither subscriptions nor cloud agents are new; they already arrived in the August release from Aug 19. Projects is to a large extent a repackaging of what Cursor already had, with a coordinator added on top. Simply a clever idea for bringing it all closer to the user.
And what about conflicts, can I see how they’re resolved?
That was the main pitfall of the original way of working. Most of us were too lazy to start new work in the same project in a different worktree, because we’re not stupid, after all, and we know it won’t touch the same files as the neighboring work in the same project. But before long it did, and the agents started acting up. And conflicts were mostly dealt with only in Git, where you have to understand two foreign intentions and fix them, which is sometimes not easy even for AI. In Cursor, a conflict between two working agents means you simply run the combined task again on top of the main branch. It’s actually cheap, and there’s plenty of room for improvement, because the harness can identify that tasks overlap and merge them on the fly.
Four things Cursor didn’t say
How context gets condensed when a thread runs for months. Part of the answer is obvious: the agents write summaries into shared files, so the coordinator stays tolerably “lean” because it doesn’t read diffs. But Cursor hasn’t published documentation on this, and in practice it will be important that it works really well.
How concurrent changes to the same file are handled. For a product that boasts dozens of parallel agents, this is a conspicuous hole. Dragging in-progress chats into a project suggests that the coordinator keeps some kind of ownership table, but that’s my guess. Again, we’ll see in practice.
Who merges. The vendor hasn’t published any default recommendation, so you set the line between “open a PR” and “merge on green” yourself. Let’s count on the need for human oversight and a code-review workflow.
How much it costs. Somebody pays for twenty subagents in the cloud, and for now it comes out of your plan’s “limits,” but there will undoubtedly be an effort to put some kind of price list on it.
Add to that the usual beta ailments. On Linux, Projects didn’t show up on day one, chats are dragged into a project one at a time, and Cursor created a nice naming collision for itself, because until now “project” meant an open folder.
I personally don’t consider the interface polished enough. I could imagine that thanks to the coordinator’s classifier, Projects would let me see the progress of individual tasks more clearly, but it’s definitely a good kickoff. So I say: I’m looking forward to competitors copying it, so I can stop having such a mess in the Ghostty tab bar or in the Claude Code Desktop app.