Cursor Self-Hosted Machines move Cloud Agent tool execution onto machines you manage, while the agent loop, inference, and planning stay in the Cursor cloud. That is a different split than running OpenClaw or Hermes yourself, where you host both the process and the tool surface.
Cursor published the product story on September 2, 2026. The Self-Hosted Machines docs and computer use docs fill in workers, pools, what leaves your network, and Linux or Mac desktop control. This post stays with those pages and what the split means next to self-hosted OpenClaw, Hermes, and Grok Bot-class stacks.
Short answer
Use Self-Hosted Machines when Cursor-managed Cloud Agents are not enough: tools must run inside your network next to source control and internal services, you need custom hardware such as GPUs or Macs for iOS work, or your OS and build pipeline are hard to package as a Cloud Agent build. You still start and manage agents from Cursor. Only the execution environment moves.
Stay on Cursor-managed Cloud Agents when isolated Cursor VMs, network allowlists, and private connectivity cover your requirements. Cursor still recommends that path for most teams.
Choose OpenClaw or Hermes when you want the agent process, model routing, tool policy, and host trust on infrastructure you administer end to end. Start from OpenClaw vs Hermes Agent, the self-hosted deployment checklist, and trust boundaries for self-hosted agents.
Execution model
With Self-Hosted Machines, a worker on your side holds the working copy of the repository, edits files, runs commands, can run computer-use tools, and can run local MCP servers. Cursor's harness handles inference and planning, then sends tool calls to that worker. Results flow back for the next round of inference. Cursor's blog is explicit that tool outputs may contain code, and that agent transcripts may be processed and stored by Cursor.
That is not "fully local agent." It is cloud planning plus local execution. Managed Cloud Agents keep both sides on Cursor VMs. Self-Hosted Machines keep planning in Cursor and move tool execution to you.
OpenClaw is a Gateway you run. Model providers, sessions, tools, channels, and optional device nodes sit in a process you operate. Hermes is a process you run from a CLI, messaging Gateway, API server, or supported editor path, with toolsets and terminal backends you configure. In both cases you pick the model path and you own the host trust boundary. Cursor Self-Hosted keeps the Cursor agent loop in Cursor's cloud even when the worker is yours.
Workers: My Machines and pools
You register a machine by installing the Cursor CLI and running `agent worker start`. That opens a long-lived outbound HTTPS connection to Cursor. Cursor never initiates a connection into your network. Docs list outbound needs for the agent session and for artifact uploads. No inbound ports, public IPs, or VPN tunnels are required for the worker link itself.
Workers come in two shapes:
- 1My Machines - one laptop, devbox, or VM on your account. Best for personal workflows. Multiple agents can run on the same machine.
- 2Pools (Team Pools) - a named queue of workers for a team or enterprise. An available worker claims a request. A controller you run can watch the queue and use a spawn script to start machines when demand arrives. Idle timeouts can reset a worker back into the pool, or preserve a workspace for a follow-up. Hibernation can snapshot and stop an idle machine, then restore it within a reconnect window with the same worker ID.
Pools are not tied to one repository. A request identifies the pool; any available worker can claim it. Team Pools need a Cursor Enterprise plan and a service account API key. Personal logins and personal API keys register My Machines workers, not pool workers.
Cursor's September 2 blog names sandbox partners including AWS Lambda, Cloudflare, Coder, Daytona, E2B, Modal, Namespace, and Vercel. The docs also list additional partner hosts and reference templates. Those are places to run workers; you still own the image, secrets, scaling policy, and production validation.
Computer use on Linux and Mac
Computer use lets an agent on a Self-Hosted worker click, type, take screenshots, and drive apps with a UI. With Chrome or Chromium installed, it can drive a browser. It works on macOS and Linux workers for both My Machines and Team Pools. You enable it with an explicit flag: `agent worker --computer-use start`. Cursor docs say computer use and desktop sharing are never enabled by the server.
On macOS, the CLI installs a Cursor Computer Use helper. The worker needs a signed-in desktop session and Accessibility plus Screen Recording grants for that helper app.
On Linux, the worker uses X11. You install desktop packages yourself. The worker can reuse a display you already run, take `--display`, or start a managed TigerVNC desktop with Xfce on headless machines.
Desktop sharing is separate and Linux-only. `--share-desktop` lets authorized viewers watch or take control of an isolated agent desktop from Cursor. Pixels leave through the worker's existing outbound connection. No inbound ports open for sharing.
Treat computer use like any other broad desktop authority. Prefer a narrow MCP or API tool when the job has one. Browser vs MCP as the wrong surface still applies when a typed tool already exists.
What leaves your network
The full checkout, build cache, and machine-local credentials stay on your machine. During a run, the worker sends Cursor the content the agent needs: file contents, terminal output, diffs, screenshots, local MCP results, and routing metadata. If desktop sharing is on, it also streams the agent desktop. Artifacts such as screenshots, videos, and log references can upload to Cursor-managed storage for pull requests and the dashboard.
Privacy Mode also applies to Self-Hosted Machines. When it is enabled, Cursor docs say code sent from the worker is not used for training by Cursor or model providers. Keep secrets out of tool output and artifacts either way.
This is the trust question to write down before you scale pools: you control where tools run, and Cursor still sees the tool stream the agent needs to plan. That is different from a fully self-hosted OpenClaw or Hermes Gateway, where model and tool providers only see what your config sends them, and there is no Cursor agent harness in the middle unless you put one there.
Beside OpenClaw, Hermes, and Grok Bot-class stacks
| Question | Cursor Self-Hosted Machines | OpenClaw or Hermes | Grok Bot-class personal agents |
|---|---|---|---|
| Where does the agent loop run? | Cursor cloud (inference and planning) | Your Gateway or process | Your operator host / bot runtime |
| Where do file edits and shell run? | Worker you manage | Host and backends you configure | Host you attach to that bot |
| Who starts the session UI? | Cursor (app, cursor.com, mobile, Slack, GitHub, Linear) | Your channels and Control UI or CLI | Your bot surfaces |
| Computer use | Opt-in on Mac/Linux workers with `--computer-use` | Browser or desktop tools you enable yourself | Whatever desktop or browser tools that stack exposes |
| What the vendor still sees | Tool outputs, diffs, screenshots, transcripts as documented | Whatever model and tool providers you wire | Whatever that bot's model and tool path sends |
OpenClaw and Hermes fit when you need the whole runtime under your ops checklist: pairing, tool policy, sandboxes, cron, and a trust boundary you can split per team. Cursor Self-Hosted fits when the team already works in Cursor Cloud Agents and needs execution beside private services or on custom hardware, without giving up Cursor's loop.
Grok Bot-class setups raise the same design choice in smaller form: decide where planning runs, where tools run, and what screenshots or shell output leave the box. Do not assume any of these products share the same approval model. Permissions and human approval still belong in the stack you operate.
How this fits implementation work
OrchestriAI does not operate Cursor, OpenClaw, or Hermes. AI agent systems define the job, the tool list, and the human gate. MCP development gives a narrow tool when a broad desktop or shell surface is the wrong default. Systems integration keeps credentials, queues, and side effects on the identity that matches the worker or Gateway you chose.
Self-Hosted Machines is a useful case study for split execution: cloud planning, local tools, outbound-only workers, optional computer use, and a clear list of what still leaves the network. Use that checklist when you compare any vendor cloud agent that offers "run on our loop, on your machines."
Independence and limitations
OrchestriAI is an independent implementation provider. Product names are used for identification only. OrchestriAI is not affiliated with, endorsed by, or sponsored by Cursor, OpenClaw, or Nous Research / Hermes. This article summarizes Cursor's September 2, 2026 Self-Hosted Machines blog, the Self-Hosted Machines docs, and the computer use docs as of early October 2026. Features, plan requirements, partner hosts, and CLI flags can change. Confirm current Cursor docs before you size a worker fleet or enable computer use on a shared desktop.
