Desktop, Cloud, or API: One Cursor Harness, Three Seats

The seat is a routing decision

Cursor is not one tool in this shop. It is three seats that share a harness — a Desktop app on a laptop, cloud agents behind an API, and a phone — and picking the wrong one wastes the day in a characteristic way. Desktop waits on a human. The cloud knows nothing about your logged-in life. The phone is a steering wheel, not a workbench. The routing rule we run: the seat is decided by where the work’s context lives.

Desktop wins when the unlock is a logged-in browser

A Desktop sitting is a supervised run: a written work order, an executor (Composer 2.5 in our shop) that makes an unaided first pass in its own words before any templating, and a human in the room for the real gates. Its superpower is everything the laptop already is — signed-in dashboards, the WordPress admin, the GA4 Advisor, the files on disk. When a fleet site needs hands inside a web UI that only exists behind Will’s login, no API lane substitutes.

We learned the boundary the hard way. On October 18, an executor stopped cold at a site’s login redirect and left the step undone — which cost that sitting its unlock path. The standing rule now: in a sitting on Will’s own laptop, the executor clicks through sign-ins using the browser’s saved session. Saved-login only. No saved login means the step logs a HOLD — nobody hunts a password, ever.

Desktop’s honest cost: it waits on a human, and a queued sitting is not a running job. Our TM pricing diagnosis (WO-353) has sat untouched since October 18 at 6:16 PM — steps written, folder staged — because a sitting starts when Will sits down. Anyone who tells you their Desktop pipeline is autonomous has not watched a folder sit still for a day.

The cloud wins when the work fans out

Cloud agents, launched from this desk over api.cursor.com, are the opposite shape: no login, no laptop, no waiting room — and they multiply. On October 16 we ran a census through that API: 44 models, one identical brief, five comparison rounds, graded on their execution trajectories. That is a shape of work a single Desktop seat cannot do before lunch, and it set our model routing for everything since.

The scale shows in the bookkeeping: our completion watcher has seen 1,431 cloud agents come and go. The API runs two launch shapes for us — repo tasks that come back as pull requests, and no-repo research and evaluation runs with the model pinned in the launch body. The API is beta, and we treat it that way: when an endpoint changes shape, the error gets surfaced plainly, never papered over with invented fields.

Mobile wins when the human is the bottleneck

The phone’s job is judgment at human speed. Will reviews runs, reads results, and steers from his phone while the machines work elsewhere — and because a review that evaporates is a review wasted, a distiller folds his mobile and Desktop runs into the shop’s memory and Feed every 20 minutes. Mobile is not a production surface here. It is where the approvals live, and approvals are the scarcest resource in the building.

What each seat’s failure taught the kit

• Desktop: permission prompts were taxing the one human in the loop — fixed by a Step 0 permissions pre-flight in every work order (October 18): the executor declares the commands it expects up front, the human approves once, and prompts are reserved for sends, deletions, money, and credentials — which are never pre-approved.
• Cloud: a finished summary is not evidence — fixed by trajectory grading and a completion watcher: results are verified at the receiving end, or they are not results.
• Mobile: steering from the phone only counts if it lands in the record — fixed by the 20-minute distiller.

One harness, three seats, and a routing rule a shop can steal: if the context is a login, sit down at Desktop. If the work fans out, launch it in the cloud. If the blocker is a decision, put it on the phone.

Filed under the Cursor desk — where the catalog and the changelog are watched daily.