Cursor 3 shipped last Thursday, and the most telling detail is what it is not. It is not a new coat of paint on the VS Code fork. The founders wrote that they built the new interface from scratch, centered on agents, and the file editor is now the thing you open when an agent needs a human.
We wrote in November that Cursor 2.0 had moved the editor toward agents. Cursor 3 finishes the move. Here is what changed, how we ran a fortnight of client work in it, and the two questions we asked before letting it near a client repository.
What Changed
- One window for every agent. Local agents on your machine and cloud agents on Cursor's infrastructure appear in a single sidebar, across every repository you work in. Agents you started from your phone, from the web, from Slack, from a GitHub issue or from a Linear ticket all land in the same list.
- Hand-offs in both directions. A cloud agent that finishes a draft can be pulled down to your machine to edit and test with Composer 2. A local session can be pushed to the cloud so it keeps going after you close the laptop.
- Evidence from cloud agents. When a cloud agent finishes, it attaches screenshots and a recording of the thing it built.
- A review flow that ends in a merged PR. A new diffs view for reading and editing changes, then stage, commit and manage the pull request without leaving the window.
- A built-in browser for opening the local app and prompting the agent about what it sees, and a file viewer with full language support and go-to-definition.
- A plugin marketplace with hundreds of plugins bundling MCP servers, skills and subagents.
If you upgrade and nothing looks different, it is because the new window is behind a command until you switch: open the command palette and choose Agents Window.
How a Fortnight Looks Now
Our fortnightly cycle in Takeoff & Climb has been stable for a while: a set of specs from the roadmap, one agent per spec in its own worktree, review, merge, demo. Cursor 3 does not change the cycle. It changes where each step happens.
Specs become tickets become agents. We track roadmap items in Linear on most builds. In Cursor 3, a ticket can start a cloud agent directly. The spec is the ticket body. By the time we sit down, the first draft of each feature is a branch with screenshots attached.
Cloud for the draft, local for the judgment. The hand-off is the feature we use most. A cloud agent produces the first eighty percent overnight. We pull the session down in the morning, run it against the real dev database, poke at the edge cases, and finish it locally. Nothing about that was possible when a cloud agent was a black box that emitted a pull request.
Review is the job. With four to six branches landing a day, the diffs view is where an engineer spends most of the time. This is the same lesson as every parallel-agent release: the bottleneck is reading, not writing. Cursor 3's review flow is the best we have used because it assumes that.
The recording is the demo. Cloud agents attach a video of the built feature. We have started collecting those into the fortnightly demo. Clients watch the agent's own run-through, then we show the version we finished.
Two Questions We Asked First
Where does the code run? Cloud agents run on Cursor's machines. For most startup clients that is fine and we say so in the Flight Plan. For a client whose contracts say the code cannot leave their environment, it is not, and those builds stay on local agents only. Cursor 3 makes both easy to see in one list, which is more than we could say last month.
What does it cost after this week? The other headline of the past week was the end of flat-rate agent use. Anthropic told Claude subscribers that third-party harnesses are no longer covered by their plan and now bill as extra usage, and OpenAI moved Codex to token-based credits the same week. Cursor 3 itself did not change pricing, and Composer 2 comes with what Cursor calls high usage limits. But the direction across the industry is clear: unattended agent work is metered. We now quote agent spend as a line item in Clearance, split between the interactive work a subscription covers and the overnight work it does not.
What We Are Not Doing Yet
We have not moved rules and skills into the marketplace. Every client repository already carries its conventions in files checked into git, and we would rather generate a Cursor plugin from those than maintain a second copy in a marketplace. When the marketplace can be the source of truth for a single client and nothing else, we will revisit.
We are also not starting agents from Slack for client work. It is a good feature for a product crew talking to itself. For a client build, every agent starts from a spec, and specs live in the tracker, not in chat.
The Founder's View
If you are watching a build in Cursor 3, you will see more branches, more screenshots and more recordings than before. The question to ask your crew is the same one as always: what is the review step, and who does it? An agent dashboard that makes it easy to start ten things is only as good as the discipline that finishes them.
For us that discipline is the spec in front and the review behind. Cursor 3 makes both faster. It does not make either optional.
Ready to Watch Your Build Land Branch by Branch?
At Dev Force One, Cursor 3 and Claude Code fly every Takeoff & Climb, from a ticket in the tracker to a reviewed pull request and a recorded demo.
What you get:
- A visible board: one agent per roadmap item, with screenshots and recordings as each one lands
- Judgment where it matters: cloud agents for the draft, a human on your machine for the finish
- Clear costs: agent spend quoted in Clearance, split between interactive and overnight work
Want to see a fortnight of your product built this way? Book a Pre-flight call and we will map the first sprint.