After deeply experiencing Cursor Projects for the past month, I have come to love it and believe it represents the next evolution of Coding Agents.
Unfortunately, the current AI hype has shifted toward Personal Agents. While various companies are pushing their own Personal Agents, Cursor Projects has somewhat been overshadowed by its own sibling, Grok Bot, which is quite a pity.
Although Grok Bot offers a good experience and comes with a well-configured cloud computer, its interaction style feels unfamiliar for development work. Since it is designed for general users, fine-grained control can be difficult. Switching between Codex and Grok Bot often feels jarring due to the vast difference in their styles.
If you share these feelings, I highly recommend giving Cursor Projects a try.
What is Cursor Projects
When introducing the Projects feature, Cursor described it as follows:
Projects allow you to undertake larger-scale work, such as a feature, a migration, or an entire application. It maintains context over months of work, delegates tasks to thousands of sub-agents, and automatically completes periodic work without needing prompts.
In other words, you no longer need to meticulously direct specific agent dialogues as you would with traditional Coding Agents. Instead, you direct the work content itself, and Projects orchestrates the agents to complete the job.
Using Cursor Projects feels like a transitional form between a Coding Agent and a Personal Agent. Let’s compare them:
| Codex | Cursor Projects | Grok Bot | |
|---|---|---|---|
| Work Location | Local | Cloud + Local | Cloud |
| Number of Chats | Multiple | Single | Single |
| Chat Context | Local Directory | Work Project | Bot |
Traditional Coding Agents (like Codex) have a very straightforward usage pattern: we keep the configured development environment on our local machine, and the agent runs locally. When we want to do something, we open a session to tell the agent. You can open multiple sessions at will, and you can edit, compress, or fork each session yourself.
Cursor Projects, however, uses a multi-agent architecture: you only interact with an Orchestrator, which then assigns an appropriate number of agents to execute tasks. When you need to do a second task, you don’t open a new chat; instead, you continue on the existing foundation and let the Orchestrator keep refining the work. It also remembers your methods and requirements, continuously pushing work items forward.
As you can see, Cursor Projects’ level of freedom lies between a Coding Agent and a Personal Agent. It consolidates interaction into a single chat, removing the need to manage multiple sessions, yet it remains more suitable for development than Grok Bot.
The biggest difference between it and Codex is the level of focus. With Codex, you focus on a task. With Cursor Projects, you focus on a project—which is exactly where the name comes from.
What Work is Cursor Projects Suitable For
Cursor Projects proves exceptionally powerful in the right scenarios. In my experience, it is perfect for work that requires long-term follow-up and continuous adjustment or improvement.
Recently, I’ve been using Cursor Projects to develop Beacon, a Loop Engineering framework. I use a single Cursor Project to track Beacon’s development, deployment, and the operation, observation, and adjustment of over five Loop Engineering tasks (which I call Profiles). The entire process is quite tedious because I first need to develop the Beacon code, package the CLI after merging, and then deploy Beacon and the Profiles on another Mac mini, which involves various configuration files. When issues arise, I also need to check the Pi session on the Mac mini.
Imagine how chaotic this would be if I used Codex: I would have to tell Codex the deployment locations for Beacon and Profiles every time, manually trigger packaging and deployment after changes, and remember the locations of various Profiles on the Mac mini…
Cursor Projects handles all these trivialities perfectly.
First, Cursor Projects runs in the cloud but also supports connecting your own machine as a worker. I connected my Mac mini as a worker. This way, I can stay in the Cloud environment while developing Beacon code and switch to the Mac mini environment for deployment. The environment selection is handled automatically by the Orchestrator without any intervention from me.
Second, Cursor Projects can remember work progress and workflows. When I find its working mode doesn’t meet expectations, I correct it and say, “Remember this.” This allows its way of doing things to align more closely with my preferences. For example, I told it to let me approve the PR after every code change, and automatically deploy to the Mac mini once the PR is merged. This way, I can oversee every iteration without worrying about operations or typing a prompt like “automatically deploy after PR merge” every single time.
This project has been running for nearly four weeks now. Initially, I wasn’t entirely sure what Cursor Projects could do, so I used it cautiously. Now that its scope of responsibility and SOPs are clear, I can act as a “hands-off manager”—I just throw anything related to Beacon and Profiles to the Cursor Project and leave it in the background. When I remember, I come back to inspect the results.
The process is very stress-free. I don’t have to think about what to control next—I just hand the task over; nor am I interrupted by its replies—I just check the results when I’m free, knowing it will get the job done.
Tips for Using Cursor Projects
I use Cursor Projects paired with the Grok model. The Grok model seems specifically optimized for this scenario during training. When I switch to other models, such as Claude Sonnet 5.5 or GPT 5.6 Sol, the experience is nowhere near as good as with Grok.
The most important thing when using Cursor Projects is to shift your mindset. Don’t use traditional micro-management. Instead of “what should be done,” you should describe “what the goal is” to save yourself effort. Since it’s called Projects, you should start a Project for a work project rather than just using it for a temporary task. The longer it runs, the more its power is realized.
Of course, when a Project is first established, you should still provide detailed guidance to help it remember SOPs and your preferences before gradually delegating authority.
For complex, tedious tasks that require long-term follow-up, Cursor Projects is highly recommended. It can continuously track progress, allowing you to easily pick up where you left off without digging through a pile of chat history or repeatedly emphasizing your workflow.
When is Cursor Projects Not Suitable
Of course, Cursor Projects is not a silver bullet. In many scenarios, I would recommend Claude Code, Codex, or even Cursor’s own chat mode.
- When your task consumes a large number of tokens in a single go. Cursor subscriptions aren’t that durable. I usually let Codex build the framework at the start of a project (which requires many tokens) and then switch to Cursor Projects for long-term maintenance. Alternatively, you can let Cursor Projects handle the coordination while calling Codex for specific execution. After all, for heavy lifting, the Codex subscription volume is more substantial.
- When your task can be finished in a day or two. The value of Cursor Projects lies in long-term progress and workflow tracking. A “use-and-discard” task ends before it can accumulate value.
- When you are in a hurry. For example, troubleshooting alerts or handling user feedback. You might need results immediately. As a cloud-based multi-agent system, Cursor Projects’ overall output speed isn’t that fast and might just add fuel to the fire.
- When your task throughput is high. For example, if you need to open 5–8 sessions to handle multiple branches of a task simultaneously. Cursor Projects only has one main chat; while you can issue 5–8 items at once, all the replies will be mixed together, making them difficult to process.
- Highly procedural and fixed tasks. For example, “scheduled daily scans” or “troubleshoot when an alert appears.” Although these are long-term tasks, the process is too fixed. Using Cursor Projects for this is like using a cannon to kill a mosquito, and it easily wastes your quota. Such tasks are better left to a Loop Engineering system.
Next time you have a task suitable for Cursor Projects, give it a try—it might bring you a completely new way of working.