Best sandbox for Cursor agents in 2026

Cursor's agent works best with a sandbox it can start itself from MCP, one browser approval, no key in mcp.json, and per-use billing.

Runtime gives Cursor's agent, in the editor or the agent CLI, a fresh Firecracker microVM for every experiment, reached through one MCP entry that holds no secret. The agent keeps editing on your machine while builds, test suites and servers run in a machine with its own Linux kernel. A sandbox waiting for the agent's next step costs $0.03125 an hour for 2 vCPU and 4 GiB, and it pauses itself after 60 seconds with nothing happening, so the evening the agent forgot about costs storage and nothing else.

Where can Cursor's agent run code?

Cursor gives its agent three places to work, as its docs described them on 1 October 2026:

For Self-Hosted Machines, Cursor's integrations page lists partner guides for AWS Lambda, Cloudflare, Namespace, Modal, Daytona, E2B, Vercel, Tensorlake, Coder and Superserve. A worker opens "an outbound HTTPS connection to Cursor, and Cursor sends agent tool calls over that connection", so it needs no inbound ports.

What should Cursor's agent get from a sandbox?

• Setup an agent can do alone. The first Runtime tool call prints a link and a code; you approve Connect agent once, and the agent has every tool. Nothing secret goes into .cursor/mcp.json, so the project file is safe to commit.
• A machine per idea. runtime_sandbox_create returns a running microVM; runtime_sandbox_fork copies one with its memory, so two fixes can be tried side by side from the same state.
• Servers you can open. An app the agent starts gets a private HTTPS preview address that you open in your browser.
• Your laptop left alone. A runaway npm install, a fork bomb or a test that wipes a directory lands on a machine made for it.
• A cost that follows use. CPU is billed on what the code actually uses, so an agent that thinks for minutes between commands pays little for the wait.

What does a day of Cursor agent work cost?

Fifteen hundred agent tasks a month, each twenty minutes on a 2 vCPU, 4 GiB sandbox and busy for 150 CPU-seconds, at each provider's published rates:

A run on Runtime, recorded 1 October 2026

Add the server once, for every project:

JSON{  "mcpServers": {    "runtime": { "command": "npx", "args": ["-y", "withruntime", "mcp"] }  }}

Or run the agent CLI itself inside a sandbox, for a job nobody watches:

TypeScriptimport { Sandbox } from "withruntime";await using sbx = await Sandbox.create({ timeoutSeconds: 3600 });await sbx.exec("curl -fsSL https://cursor.com/install | bash", { check: true, timeoutMs: 600_000 });console.log((await sbx.exec("~/.local/bin/agent --version")).stdout);

On 1 October 2026 that install ran in a fresh production sandbox:

textcurl -fsSL https://cursor.com/install | bash   exit 0~/.local/bin/agent --version                   2026.10.01-e373342

Cursor's installer ran unchanged on Ubuntu 24.04 and put agent in ~/.local/bin. Print mode, --approve-mcps and a prepared sandbox for CI are in Cursor CLI in a sandbox, and the editor setup is add Runtime to Cursor.

When might another sandbox fit better?

• Cloud Agents started from Cursor's own interface. Self-Hosted Machines run those agents on a worker you host, on Cursor Enterprise; Cursor's partner guides cover the providers above.

Sources

Checked 1 October 2026.

• Cursor self-hosted machines: integrations: the partner guides, the Enterprise and service-account requirements, and how a worker connects
• Each provider's published rates, checked 23 September to 2 October 2026, as the pricing guide lists them
• The recorded run: Cursor's installer and agent 2026.10.01-e373342, in a production sandbox on 1 October 2026