Cursor launched Projects in beta on September 10 — a feature that, read carefully, is an admission. The pitch: a persistent “coordinator agent” that lives in an open thread, doesn’t write code itself, and instead “directs other agents that do.” It watches Slack channels, follows your PRs, runs on a schedule, and keeps working on a dedicated cloud machine after you close your laptop. Cursor’s own numbers are the headline — new users merge 30% more PRs, and users who primarily rely on Projects merge six times as many. One design-system use case is “on track to touch 20 to 100 PRs a day.”
That is a genuinely useful capability. It is also, almost feature-for-feature, the architecture Claude Code has shipped as its default operating model since Routines went cloud-native in April and Agent Teams and Dynamic Workflows scaled subagent fan-outs to the hundreds. Cursor spent three and a half years building the best AI-augmented text editor on the market. Projects is the moment that editor’s own maker concedes the editor was never the part that scaled.
What Projects actually is#
Strip the marketing language and the mechanism is simple: a supervisory agent sits above a pool of worker agents, doesn’t touch code directly, and maintains shared context across whatever those workers do. It subscribes to external triggers — a Slack channel, a PR event stream, a cron schedule — so it can act without a human opening a chat and typing a task. Cursor’s own framing: “By moving up a level of abstraction, it frees developers from managing agents and lets them direct the work itself.”
That sentence is correct, and it’s also exactly the problem Cursor’s core product spent years reinforcing. An IDE plugin is built around the assumption that a human is sitting in front of a chat panel, one task at a time, approving diffs as they land. Projects works by stepping outside that assumption entirely — the coordinator lives on Cursor’s cloud infrastructure, keeps running when the laptop is closed, and reacts to events a human never triggered by typing. It is, structurally, a delegate-and-review system bolted onto a product whose reputation was built on the opposite pattern: watch-and-approve, one editor tab at a time.
The numbers are real, and they say something else too#
A 30% PR-merge-rate lift for new users and a 6x lift for committed Projects users are strong figures, and there’s no reason to doubt Cursor is measuring something real — more autonomous, always-on delegation genuinely does move more code through review when it’s calibrated well. But notice what the metric is measuring: PRs merged, not code quality, not defect rate, not whether a human actually understood what shipped. A coordinator that “acts when a PR opens or merges” without a person prompting it is optimizing throughput first. That’s the right metric if your product’s job is to look busy in a demo. It’s a much riskier one if the actual job is producing software a team can stand behind six months later — the same gap this blog flagged in Cursor’s SDK push toward programmatic agents and in the $50B valuation piece: autonomy without a rigorous verification layer just moves the review burden downstream instead of removing it.
The part Cursor’s launch post doesn’t say#
Nowhere in Cursor’s announcement is there a mention of what happens when the coordinator’s judgment is wrong — no disclosed rollback protocol, no mention of how “thousands of subagents” get sandboxed from each other or from production credentials, no articulated model for how a human audits a week of unattended, event-triggered coordinator decisions after the fact. Compare that with how Anthropic disclosed Claude Code’s own worktree-isolation fix in August — a security-relevant subagent boundary issue, documented in a public changelog, patched within days, explained in plain language. Cursor’s Projects post is a product launch, not an engineering disclosure. That’s a meaningful difference in a company whose product now runs unattended against your Slack workspace and your PR queue.
It’s also worth remembering who owns this product. Since SpaceX’s $60B acquisition of Anysphere closed in August, Cursor answers to a rocket company, not an AI safety lab — and OpenAI is cutting Cursor’s direct model access off in November over SpaceX and xAI’s terms-of-service history. A feature that runs unsupervised against your codebase and your team’s communication channels is exactly the kind of product where “who’s accountable when it goes wrong, and what’s their track record” matters more than the demo numbers.
Claude Code already lives here#
None of this is a novel problem for Anthropic’s own harness, because Claude Code was built cloud-native and headless from the start rather than retrofitted onto an editor. Claude Code Routines already run scheduled, API, and GitHub-event-triggered automations on Anthropic’s own infrastructure — no laptop required, ever. Agent Teams and Dynamic Workflows already fan work out across dozens to hundreds of subagents with worktree isolation as a security boundary, not an afterthought. And as of this week, the same Claude Code v2.1.269 release that shipped the same week as Cursor’s Projects launch quietly raised the ceiling on concurrent Workflow agents to 256 — via an environment variable in a changelog, not a keynote slide.
That contrast is the actual story here. Cursor is racing to catch up to an orchestration model Claude Code has treated as table stakes for over a year, and it’s doing so while explicitly trying to escape the IDE-anchored, human-in-the-loop paradigm that made Cursor’s name in the first place. Projects is a real, useful step. It’s also proof that the ceiling this blog has flagged in Cursor’s architecture for a year — a tool built around a human watching a chat window — was real enough that Cursor’s own roadmap had to route around it.
Sources: Cursor Blog — “Projects” (Sept 10, 2026, primary, direct fetch); this blog’s prior coverage of Cursor’s SpaceX acquisition, OpenAI’s model-access cutoff, and Claude Code’s cloud-native Routines.