Cursor Made Sandboxes Interchangeable: What Eight Backends Behind One Agent Pool Means for Self-Hosted Platforms

More than 60% of the pull requests Cursor merges internally are now created by its own cloud agents. That number, disclosed in the company's September 2, 2026 launch post for Self-Hosted Machines, is the reason the rest of the announcement matters: when agents write most of your code, the machines they run on stop being an implementation detail and start being the product decision.

Self-Hosted Machines lets teams run Cursor's cloud agents on infrastructure the team manages — inside its own network, next to internal services and source control, on custom hardware. The headline feature is a worker pool: a named queue of machines that scales with developer demand and serves any repository. But the more consequential move is underneath the pool. Cursor partnered with eight sandbox providers — AWS Lambda, Cloudflare, Coder, Daytona, E2B, Modal, Namespace, and Vercel — so a worker can be started and orchestrated wherever a team's sandboxes already run. Cursor just declared the execution substrate a commodity, and the pool and the queue the actual product.

Here is the matrix, because everything else in this post hangs off it:

Three isolation architectures, one worker contract. That is the whole story: eight substrates, three bets, a single queue in front of them.

The pool is the product​

Cursor-hosted environments remain the default — each session on a dedicated VM in Cursor's cloud. Self-hosted is the escape hatch for three situations Cursor names explicitly: tool execution must happen inside your network, agents need custom hardware (GPUs, Macs for iOS builds) or infrastructure Cursor doesn't package (Kubernetes, sandboxes, managed VMs), or your OS and build pipeline can't be expressed as a Cloud Agent build.

The mechanism has four parts, and each one is something a platform team should recognize as infrastructure it already knows how to build:

1. Workers connect your infrastructure to the Cursor agent loop. A worker is a process running on your machine that executes tool calls — commands, file edits, repository operations, browser actions. Cursor keeps the agent loop, inference, and planning; the worker does what the loop decides.
2. My Machines is the single-developer path: connect one worker, run your own sessions on it.
3. Pools are the team path: a named queue of workers serving a team or enterprise. A new agent chat names a pool, not a machine. If a worker is free, it claims the request. If not, the request waits until capacity appears — no per-repo queues, no capacity planning by developers.
4. A controller plus a spawn script closes the loop on scaling. The controller watches the request queue and invokes a team-supplied spawn script to start machines as demand arrives; capacity shrinks as workers disconnect. Your existing cloud infrastructure scales with developer demand, in both directions.

Two lifecycle details do most of the economic work. Teams set an idle timeout per worker: on expiry the machine resets and re-enters the pool, or preserves its workspace in case the agent gets a follow-up. And hibernation covers the expensive middle ground — snapshot and stop an idle machine instead of releasing it. A follow-up inside the reconnect window restores the snapshot and restarts a worker with the same ID; outside the window, the request just moves to a fresh machine.

Pools are also deliberately repository-agnostic: any available worker can claim work from any repo. That is what lets one pool serve many repositories instead of fragmenting into per-repo capacity islands.

Read that list again and notice what is missing: nothing in it is specific to code generation. Queue, claim, spawn, idle-timeout, snapshot, restore — this is a generic batch-scheduling substrate wearing an agent costume. That generality is exactly why a self-hosted PaaS should pay attention.

The idle machine is the bill​

Agent sessions are bursty in a way that punishes naive capacity planning. A session can stay alive for hours while the agent spends most of that wall-clock time waiting — on model inference, on the human, on a long test suite — and burns CPU only in short tool-execution bursts. The cost question is never "what does a minute of compute cost" but "what does an hour of session cost," and the answer is dominated by whatever you do with idle machines.

A worked example makes the spread concrete. Take a typical session: 3 hours of wall-clock life, 20 minutes of actual tool execution on a 2-vCPU worker, sandbox compute at roughly $0.05 per vCPU-hour (the going rate E2B and Daytona both cluster around, per 2026 pricing comparisons). All numbers below are illustrative, but the ratios are the point:

Leaving machines running costs roughly 5x the hibernate path for the same session, and the gap widens with longer sessions and more concurrent agents. This is why Cursor built both knobs — idle timeout and hibernation with a same-ID reconnect window — instead of picking one. The timeout handles sessions that are truly over; hibernation handles sessions that are merely quiet. Any self-hosted sandbox layer needs both, because the workload's burstiness is structural: it comes from the agent loop waiting on inference, not from anything your scheduler can smooth out.

Sensitivity check the other direction: if your agents are GPU-backed (Modal's pitch — "a machine tailor-made for its task," up to H100s at about $3.95/hour), the idle multiplier applies to dollars per hour, not cents, and hibernation goes from nice-to-have to the feature that decides whether the finance team lets the pilot continue. Idle policy is a cost control that scales with the price of the underlying hardware.

Eight substrates, three isolation bets​

Group the eight providers by architecture and the buying logic gets clear:

Snapshot-resume microVMs (Lambda, E2B, Vercel). Firecracker-class isolation with launch-from-snapshot and suspend-on-idle. AWS's pitch for the integration is explicit: near-instant launch from snapshot, suspend when idle, resume with full state, zero fleet management. Pick this bet when session density and idle economics dominate — exactly the bursty-session workload the cost example above describes.

Containers on someone's network (Cloudflare, Namespace, Daytona). Cloudflare runs each session in an isolated container backed by Cloudflare Containers while Cursor hosts the loop; the draw is execution inside infrastructure and network controls the team already operates. Daytona adds VM and Windows classes for the sessions containers can't hold. Pick this bet when data gravity or OS diversity dominates — agents next to internal services, builds that need Windows or kernel features.

Purpose-built workspaces (Coder, Modal). Coder brings the dev-workspace model (persistent, opinionated environments); Modal hands each session a sandbox sized to its task, GPUs included. Pick this bet when the session's machine genuinely differs per task — the "Macs for iOS, GPUs for evals" end of Cursor's own list.

No bet wins outright, which is precisely Cursor's point: the vendor with the most to lose from fragmentation chose to support all three rather than crown one. For a team choosing today, the decision procedure is short — data must stay in-network (containers on your cloud), sessions need exotic hardware (workspaces/specialized sandboxes), otherwise default to snapshot-resume microVMs and spend your engineering on idle policy instead.

What it takes to become backend number nine​

The pool and the queue are the product; the substrate is a plugin. So what must a self-hosted PaaS build before its own nodes can be one more backend in that matrix, instead of the machine the agent escapes? Four things, each mapped to a mechanism Cursor already shipped:

1. A pool-aware scheduler: queue, claim, spawn. A named queue that agent sessions address, workers that claim requests, and a controller that turns queue depth into machines via a spawn script. If you run Cluster API on owned hardware, the spawn script is a machine-lifecycle call you already own; the missing piece is usually the queue in front of it.
2. Per-agent isolation on shared boxes. One agent per microVM (Firecracker/Kata) or a hardened container boundary with network egress controls — never one shared userspace where a compromised session can read its neighbor's secrets. Cursor's default (dedicated VM per session, secret redaction, egress controls) is the bar your substrate has to clear before any agent vendor will route to it.
3. The idle lifecycle: timeout plus hibernate. The worked cost math above is the spec. Snapshot/restore for the quiet-but-alive session, reset-and-repool for the finished one, a reconnect window keyed on worker identity. Without this, your per-session cost is the top row of that table, and no scheduler cleverness elsewhere compensates.
4. A utilization API for autoscaling. The controller needs to see queue depth, worker state, and claim latency to decide when to spawn and when to stand down — exposed cleanly enough that teams can build their own autoscaling on top rather than filing tickets against yours.

Note the shape of the list: it is all execution substrate. Nothing about model routing, planning, or agent frameworks — and that asymmetry is the next section.

What not to copy​

Cursor kept the agent loop, inference, and planning on its side of the worker contract in every single integration — Cloudflare's docs state the split plainly. The eight providers sell places for tools to execute, not opinions about how agents think. A self-hosted platform copying this launch should copy the boundary, not just the topology: build the worker contract (spawn, claim, isolate, hibernate, report utilization), and let agent vendors — Cursor today, whoever tomorrow — bring the loop. The moment your sandbox layer starts expressing opinions about agent behavior, you have rebuilt the thing the matrix exists to avoid rebuilding, and you compete with all eight providers at once instead of interoperating with them.

There is a second non-goal worth naming. Cursor did not build a ninth sandbox; it wrote eight integrations against substrates teams already ran. "Become a backend" beats "build a backend" as a roadmap: the fastest path to your nodes serving agent sessions is a worker-compatible execution endpoint on hardware you already operate, not a from-scratch sandbox product.

The substrate is a plugin​

Step back and the launch reads as a maturation event for the whole agent-infrastructure category. Daytona raised a $24M Series A in February 2026 on "a computer for every agent"; E2B, Modal, and the rest each raised tens of millions to be the place agent code runs. Cursor's answer is that there is no "the" — there is a pool, a queue, a spawn script, and eight interchangeable places to put the worker. Competition moved up the stack from "whose isolation is best" to "whose pool semantics are best," and isolation became table stakes with three surviving architectures.

For teams running their own machines, that is permission and a spec. Permission: a leading agent vendor validated running agent tool execution on customer-controlled infrastructure at enterprise scale. Spec: the four-item checklist above, with the cost model telling you which item pays for itself first (hibernation, almost always). Build the worker contract on your own fleet, and your Hetzner boxes are not the machine the agent escapes — they are backend number nine.

Sources: Cursor, "Run cloud agents on machines you manage" (Sep 2, 2026); Cloudflare press release on Cursor Cloud Agents on Cloudflare Sandboxes (Sep 2, 2026); Cloudflare Sandbox SDK tutorial for Cursor Cloud Agents; Qovery, "The 9 Best Infrastructure Platforms for Running Agentic Workloads in 2026"; MarkTechPost, "Best Agent Sandboxes in 2026"; Daytona $24M Series A coverage (Feb 2026). Pricing figures are per-public-comparison illustrative rates, labeled as such in the text.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.