There is a formal difference, and Cursor itself can see it and agrees
your machine this run is explicitly a self-hosted private worker (usePrivateWorker: true). Cursor’s UI/docs still fold that under “cloud agent,” which collides with the managed Cursor-cloud runners. From your side it’s just a remote agent session that happens to execute on your worker, not theirs.
“Self-hosted agent” (vs “Cursor cloud agent”) would be the clearer split. That’s product copy, not something I can change from here - worth filing as feedback if you haven’t already.
I see some bugs or discussions (like How to ensure Automations and API agent runs use self-hosted workers only (not Cursor-hosted)? - #16 by Colin ) which would be easier to clarify if the word “cloud” was not involved at all. “Require Self-Hosted Pool for All Cloud Agents” doesn’t seem like a setting that should exist. They should be separate, like “Allow self-hosted agents?” “Allow users to use Cloud Agents?” or something. Clean, separate, obvious. Just like GitHub or GitLab self-hosted runners vs. their SaaS cloud runners.
Maybe it’s just due to some rough edges due to the feature launching recently, but I wind up having to go to cursor.com/agents to launch against my self-hosted agent “for sure” because otherwise it seems like my Cursor desktop app can be misleading where it’s actually going to launch (don’t get me started on mobile - it folds all agents from the same host into one “agent”)
Cleaning up the product titles and each application (desktop, mobile, web) to be consistent and clearer settings delineation would iron out a lot of confusion, in my opinion! Oh and please fix iOS to see all the self-hosted agents independently
Agreed this is mostly a naming collision, not a runtime mystery.
From the agent’s side, usePrivateWorker: true already means “this run executes on your registered worker,” which is closer to a self-hosted runner than to Cursor’s managed cloud fleet. Folding both under “cloud agent” in UI/docs makes settings like “require self-hosted pool for cloud agents” sound contradictory, even when the control plane is doing the right thing.
A clean split that matches how people already talk about GitHub/GitLab runners would help:
Managed cloud agent — Cursor-hosted runner
Self-hosted / private worker — your machine, still remotely orchestrated
Same remote-session UX, different execution venue. Once the words stop overlapping, the Automations/API “must use my workers” threads get much easier to reason about.
I wind up having to ask the agent itself if it’s running self hosted or not (to confirm) and it always winds up reporting it’s usePrivateWorker: true status - it’s usually pretty obvious based on the spinup time, I’m not stressed about data privacy in this, it’s moreso that I have my self-hosted agents on my development server with access to various things. If it winds up in the cloud it’s useless to me (I’m not leveraging the cloud<->SCM relationship like that)
A good chunk of this was cleaned up recently. The feature is now called Self-hosted machines (My Machines for a personal machine, Team pools for shared workers), and the setting you quoted is now “Require self-hosted and personal machines”. Self-hosted still lives under Cloud Agents on purpose: Cursor runs the agent and the model, and all the tool execution (terminal, files, builds) happens on your machine. More detail here: Self-Hosted Machines | Cursor Docs
On the desktop app, we just fixed one case where a self-hosted run could be labeled “Cloud”. If a run still lands somewhere you didn’t expect, a screenshot of the “Run on” picker before you send would help us track it down.
