Automater
Upgrade to ProDownload Lite free

Cursor Projects vs. the Tray: Who Owns Your Fleet Coordinator

Cursor Projects puts a fleet coordinator in the IDE. The ownership table: what it runs, what a local tray owns (stall flags, kill switch), and what breaks.

Portrait of Russell Winslow
15 min read
All articles
Cursor Projects coordinator loop and the desk operating layer drawn as two overlapping circles, with the local agent on your laptop in the overlap
Two loops, one process with two owners. The overlap is the only row in the ownership table with two names in it.
THE FIELD GUIDE

Go deeper. Build your own.

Picture 9:40 on a Tuesday morning. The Cursor Projects coordinator you set up on Monday has eleven subagents open on machines you have never logged into, one local agent running tests on your laptop, and a Slack channel feeding it new work while you slept. The tray icon next to your clock can see exactly one of those twelve processes.

Cursor shipped Projects on Sep 10, 2026 as a beta: a coordinator agent that plans the work, delegates it to as many subagents as the work needs, and brings the finished pull requests back for you to check. It is a real fleet coordinator, and it lives in the IDE. It is also the second thing on your desk that believes it runs your fleet, because the tray companion that inventories supported CLIs on the machine, raises stall flags, and keeps the local archive believes the same thing.

By Tuesday you should have a one-page ownership table: which loop owns planning, which owns the process on your laptop, who holds the kill switch, whose meter counts what, and the three places the loops collide when nobody writes that page down. Cursor’s launch copy gets quoted once, in the next section, and then the table does the work.

Cursor Projects on Sep 10, 2026: it plans, delegates, and never blocks

The changelog entry and the companion blog post “Introducing Projects,” by Alexi Robbins and Fredrika Lindh, describe the shape plainly (Cursor changelog; Cursor blog). Projects is a beta, “rolling out to all users starting today,” built for “larger bodies of work, such as a feature, a migration, or a full app.” It “maintains context over months of work, delegates tasks to thousands of subagents, and performs recurring work without being prompted.”

Cursor changelog entry titled Cursor Projects, dated Sep 10, 2026, opening with the paragraph about delegating tasks to thousands of subagents Screenshot: Cursor changelog, “Cursor Projects” (Sep 10, 2026), captured Sep 13, 2026.

The coordinator’s job description is the part that decides ownership. “The coordinator agent in a project doesn’t write code itself; it plans the work, delegates it to agents that implement it, and brings the finished work back to you to check. Coordinators create and manage agents on your behalf, running as many in parallel as the work needs.” It runs “on its own computer in the cloud, so closing your laptop doesn’t stop it,” and “when something needs testing on your machine, the coordinator spins up a local agent to run it there.” You can “tell the coordinator agent to watch a Slack channel, run on a schedule, or follow all your PRs,” the subscription model Cursor’s Aug 19, 2026 changelog had introduced for cloud agents “only, for now.” The blog adds the sentence that matters most here: because it delegates rather than executes, “it is never blocked and is always responsive to direction.”

Cursor blog post Introducing Projects by Alexi Robbins and Fredrika Lindh, dated Sep 10, 2026, showing its table of contents Screenshot: Cursor blog, “Introducing Projects” (Sep 10, 2026), captured Sep 13, 2026.

Two absences matter as much as the quotes. The changelog entry contains no pricing, limits, or permission language. And Cursor’s own numbers, that “new users merge 30% more PRs while users who primarily use Projects merge six times as many,” are Cursor measuring Cursor’s users on work they chose Projects for. Cursor was not alone that day: OpenAI’s Agents API went to public beta on Sep 10 with subagents of its own (OpenAI). The news ends here.

Acting agents turned ownership into a runtime question

A chatbot that suggests a migration has no process on your machine. A coordinator that performs one has several: the cloud computer, a subagent per unit of work, and the local agent it spins up to run tests where your toolchain lives. Every one of those processes can stall, spend, write, and be killed, and each verb needs an owner.

Before Sep 10 the answer on a single desk was simple. The CLIs were the workers, you were the coordinator, and the tray companion was the one boss that saw all of them. Projects moves the coordinator into the IDE and onto a machine you do not administer. The tray did not lose any of its jobs. It lost its monopoly on knowing what is running.

The ownership table: which loop owns what

Print it, argue with it in a design review, then keep it next to the Project.

Concern Projects coordinator (IDE loop) Tray companion (desk loop) When both run
Planning and delegation Plans, spawns subagents, brings PRs back Does not plan Coordinator, always
Cloud subagents Isolated copies on Cursor’s machines Cannot see them Coordinator; export evidence (step 6)
Local agent on your laptop Spawns it, hands it the task Can see the local process; transcript import must be tested Two owners; write the rule (step 2)
Stall detection Coordinator task state; launch material does not document local-process health Stall flags per process, every CLI Desk for anything local
Kill switch Steer from the IDE; launch material does not define stop semantics End the process, keep the transcript Desk; a remote stop is a request
Archive and evidence Context files and history, on Cursor’s terms Local Library of every CLI’s transcripts Desk for local; you export the rest
Token meter Cursor’s usage views Local meter across supported CLIs Neither sees the whole bill (step 4)
Permissions Not described in the launch material One dialect for the local CLIs Shared policy file, or drift
Subscriptions (Slack, schedule, PRs) Acts without a prompt Sees only the resulting local work Coordinator; desk sets a budget per trigger
Provider weather Dies with its model access Local CLIs keep running Desk holds the continuity plan

Three rows never resolve to one owner: the local agent, the meter, and permissions. Those are the collisions, and the runbook exists to settle them before a Tuesday does.

When Cursor Projects is the right shape

Say yes to Projects when every line below is true, and put the answers in the Project’s description so the next operator can see what you assumed.

  • The work decomposes into units with a mechanical pass/fail. A migration of a few hundred PRs, a design-system sweep, a dependency bump across services. Tests, type checks, and lint decide each unit; this is the work Cursor says it runs Projects on itself.
  • Cloud by default is acceptable for this code and these secrets. If not, Cursor’s Sep 2, 2026 changelog entry on self-hosted machines, which “let you keep tool execution entirely in your own network,” is the thing to evaluate first. It is a deployment, not a checkbox. Confirm that the intended Project can target the pool before treating it as an option.
  • You can name the human who reads the first ten PRs in full. The blog’s model is “early on, you review each PR closely. As the fixes hold up, you review less.” That only works if someone reviewed a lot first, and “hold up” needs a number before PR one.
  • The trigger is bounded. “Follow all your PRs” is bounded by your PR volume. “Watch a Slack channel” is bounded by nothing you control; the sibling playbook on Slack-to-agent subscriptions has the allowlist and the rate limit.
  • The bill has a ceiling you wrote down. Cursor’s 30% and 6× are why you will be tempted; the chart shows them next to the number Cursor did not publish.

Stat tiles of Cursor Projects vendor claims: 30 percent more PRs, six times as many PRs, thousands of subagents, and zero lines on pricing, limits, or permissions Cursor’s own numbers, labeled as such. The tile that matters for the ownership table is the zero.

Read the two percentages as a description of the fit, not a forecast of yours. They come from people who chose Projects for work that suits a coordinator, the population the checklist is trying to put you in.

When the tray companion still owns the desk

Three things stay on the machine no matter how good the coordinator gets, because they are properties of the machine, not of the plan.

Stall flags. The coordinator knows a subagent finished or did not. It does not know that the local agent it spawned has been sitting on a confirmation prompt for eighteen minutes, because from the coordinator’s side that is “still running.” A stall flag is a process-level observation: transcript stopped moving, process alive, waiting on input. That is a desk job.

The local archive. A supported local session exposes an importable record. The coordinator’s context files are Cursor’s record of Cursor’s work. When a local agent does something you need to reconstruct, the transcript on disk is the evidence, and the desk layer keeps it searchable across supported CLIs, not only the one Cursor spawned.

The kill switch. A stop button in an IDE that is itself sending instructions to a cloud computer is a request with latency. Ending the process on your machine is a fact. Keep both, and never let the IDE be the only one. I have yet to regret a local kill switch.

On the desk layer, Automater Lite, free, provides fleet awareness for supported CLIs on the machine, stall flags in the tray, keepalive across reboots, a local Library, a local token meter, and vault redaction. Downloads currently cover Windows x64, macOS on Apple silicon, and Linux x86_64. Pro adds managed sessions, fleet and integration-health controls, pop-outs, diagnostics, and built-in Files, Terminal, and Browser mini-apps. It cannot see the Project’s cloud computer or cloud subagents, and it enforces nothing on Cursor: no gateway, org policy, routing, or identity. Test whether Cursor’s local Project agent writes a format this build’s Library imports before relying on that path. Automater Lite is free on automater.ai; Pro is $50/year.

Two control loops diagram: the Cursor Projects coordinator loop on the left, the desk operating layer on the right, and the local agent spun up on your laptop in the middle tagged collision The IDE loop plans, delegates, and reviews. The desk loop flags, meters, archives, and kills. The local agent is in both.

Run both under one policy file, in six steps

Budget an afternoon. Steps 1 and 2 are the policy; 3 through 6 make it true.

Step 1: write the ownership table as a file

One file, checked into the repo the Project works on, read by humans and by whatever hooks you run. Illustrative shape:

# fleet-policy.yaml: illustrative; one per repo the coordinator touches
coordinators:
  cursor-projects:
    scope: cloud # cloud computer plus cloud subagents
    may_spawn_local: true
    local_agent:
      owner: desk # once it exists, the desk owns the process
      max_concurrent: 1
      max_runtime_min: 45
      stall_grace_min: 15 # longer than your slowest legitimate test run
      on_stall: flag_then_kill
      on_desk_kill: do_not_respawn
    budget:
      per_project_day_usd: 40 # illustrative ceiling
      on_exceed: pause_and_page
desk:
  kill_switch: local_process # the IDE stop is a request
  archive: local_transcripts
  meter: local_plus_export

Step 2: give the local agent a name, a budget, and a grace window

The row with two owners becomes a rule: the coordinator may start it, the desk decides when it is stuck, and the desk ends it. Set stall_grace_min longer than your slowest legitimate test run, or the flag fires on every integration suite. Keep max_concurrent at one until step 3 has shown you how the coordinator behaves; two local agents from one coordinator is how a laptop becomes a build farm.

Step 3: make the kill switch local, and test it on a boring Tuesday

The drill: open a Project on a throwaway branch, let it spawn the local agent, end that process from the desk, and watch what the coordinator does next. Cursor’s launch material does not specify restart behavior, so write down which of three outcomes you get.

  1. It marks the task failed and waits. Good. The desk’s kill is final, and do_not_respawn is documentation rather than a fight.
  2. It respawns the local agent. Then a desk kill is a pause, and you need max_concurrent: 1 enforced on the desk plus an instruction to the Project not to retry local tasks without a human.
  3. It routes the task to a cloud subagent. The kill moved the work off the machine. Whether that is acceptable is the “cloud by default” line in your checklist, answered again, under pressure.

Repeat the drill after every Cursor update that mentions Projects. Behavior you tested in September is not behavior you have in November.

Step 4: meter both loops and join them by day

The local meter counts local sessions. Cursor’s usage view counts the cloud loop. Neither sees the other, and the launch material does not publish a cap for a coordinator that runs “as many in parallel as the work needs.” Record your own fan-out baseline instead of using a single-CLI estimate as the floor. Join the two by date and Project:

# illustrative: one row per day per loop, joined on the date column
join -t, -j 1 <(sort local-meter.csv) <(sort cursor-usage-export.csv) > fleet-bill.csv
awk -F, '$2+$3 > 40 {print "over ceiling:", $0}' fleet-bill.csv

The sibling playbook on metering coordinator fan-out has the alert thresholds and the orphan sweep. The owner is the desk, because the desk is the only place both numbers land.

Step 5: route approvals through one permission dialect

The local agent shares a machine with CLIs that already have a permission policy: Claude Code’s permission modes and allow/deny rules in settings.json (Claude Code docs), Codex CLI’s sandbox and approval flags (Codex CLI docs), and the restricted mode table that maps them to tiers. If Projects exposes permission controls, write them into the same table with the same tiers. If the Project’s local agent can write where the local CLIs must ask, the policy on the machine is whichever one was written last.

Step 6: export the coordinator’s evidence on a schedule

Which subagent touched which file, which PR came from which plan, what the Slack channel told the coordinator at 3 a.m. The cloud loop’s record lives on Cursor’s terms; the hybrid fleet playbook covers provenance per host. The rule: anything you would need in an incident gets copied to the desk before you need it, on a schedule.

What breaks, and how you’ll know

Two owners, one process. Signal: a stall flag that clears and re-raises on the same task within minutes, or a second local agent appearing while the first is being ended. Cause: the coordinator respawned. Fix: step 3, outcome two, enforced on the desk.

The meter blind spot. Signal: PRs arriving from the Project with no local session to match them, and a Cursor bill that grows on days the local meter was flat. Cause: cloud subagents are invisible locally by design. Fix: the join in step 4 and the daily ceiling, with on_exceed pointed at a human.

Subscription noise becomes work. Signal: the Project’s PR count outruns the plan you wrote, and open PRs at 8 a.m. nobody asked for. Cause: your subscription policy let more triggers through than the budget allowed. Fix: allowlist the channel, cap triggers per hour, and keep a human gate on merge through branch protection with required reviews (GitHub Docs).

Provider weather. OpenAI’s post of Aug 28 proposed ending Cursor’s model access on Nov 12 (OpenAI); the Cursor-after-SpaceX piece covers the hedges. Signal: coordinator tasks failing at the model call while local CLIs under other providers keep working. Fix: the desk holds the fallback, the same task restated to a local CLI from the transcript you kept.

“Review less” arriving early. Signal: approve latency on Project PRs dropping toward zero before the tenth PR. Cause: consistency across PRs reads as correctness. Fix: the number you wrote in the checklist, and the self-test in when not to use a coordinator.

A good coordinator is not the boss

Projects is a good coordinator and a bad boss. Good coordinator: it plans, delegates, and never blocks, and Cursor’s own migrations are evidence it works for work with a mechanical pass/fail. Bad boss: it sees only what it spawned, on machines it controls, under a policy you cannot read yet. InfoWorld’s Sep 11, 2026 note on the Agents API applies to any coordinator you do not host: when one vendor provides “the model, context management, tools, orchestration, and execution environment, moving to another platform becomes harder” (InfoWorld).

The desk layer is operating-layer infrastructure, not a smarter prompt: fleet awareness of supported CLIs on the machine, stall flags, the local archive, the local kill switch, and the meter for supported local runs. Pair the two on paper first, and let the coordinator do what it is good at inside a policy the desk can see. One boss is still the right number. The boss is just not the IDE.

FAQ: Cursor Projects and local fleet control

Is Cursor Projects a fleet coordinator or an IDE feature?

Both. Projects is an IDE feature whose coordinator agent plans work, delegates it to as many cloud subagents as the work needs, and spins up local agents for testing, which is a fleet coordinator’s job description. It does not inventory other CLIs on your machine, raise process-level stall flags, or archive their sessions.

Can a tray companion stop a Cursor Projects agent?

It can end the local agent’s process on your machine and keep its transcript, the kill switch that matters for anything running on your hardware. It cannot stop the coordinator or its cloud subagents; those stop from the IDE, on Cursor’s terms. Test what the coordinator does after a local kill before relying on either.

Does Cursor Projects replace a local session archive?

No. Projects keeps its own context files and history for its own agents, on Cursor’s infrastructure. Supported Claude Code, Codex, and other local sessions can feed an archive on your machine. Test a Project’s local-agent import before claiming it can be searched and replayed beside them.

Sources

YOUR NEXT READ

Stay in the loop.

Explore all Intel ↗