Every sandbox pitch for agents starts with the same forced choice: do you run the agent's code in a fast V8 isolate, a microVM, or a full container? We've mapped that trade-off and the vendors that sell each shape. On August 3, 2026, during its second Agents Week, Cloudflare shipped a Preview that argues the choice is the wrong question. The post title says it plainly: your agent needs a computer, not a container.

The package is @cloudflare/computer, and the reframe is worth taking seriously — because most of the friction in agent infrastructure comes from picking one execution model and then fighting it.

The idea: a computer is a filesystem plus a shell, not one box#

When a human sits at a machine, they don't think "should this command run in an isolate or a VM." They have a stable filesystem and a shell, and different commands do different things. git clone is cheap. apt install is heavy. Same working directory either way.

@cloudflare/computer gives an agent exactly that: one persistent virtual filesystem — backed by SQLite, and seedable from cloud storage, a git repo, or files you hand it — plus a shell over two execution backends, with the platform deciding which backend each command needs (Cloudflare, changelog). The workspace is instantiated on a Durable Object, so the "computer" has a real, addressable home that persists across the agent's turns — not an ephemeral container that dies after one response.

The two backends:

The crucial detail is that the filesystem is identical across both. An agent can git clone a repo in a millisecond-start isolate, then run a native build in a Linux container against the same files — no copying state between two systems, no "which environment has my working tree" bookkeeping.

Why this matters: the agent picks, not you#

The usual model makes you decide the execution primitive when you provision the sandbox. That decision is sticky and often wrong: you size for the heavy case (a container) and eat cold starts on the 90% of commands that were just moving files around, or you optimize for the fast case (an isolate) and hit a wall the first time the agent needs ffmpeg.

@cloudflare/computer moves that decision to runtime, per command, and hands it to the agent. Cloudflare's own framing is that agents are "surprisingly capable of selecting the right environment for the task at hand" — a job that only touches files or git stays in an isolate; a job that needs a native toolchain escalates to a container. You stop pre-committing to one shape of compute.

The unlock isn't a faster sandbox. It's that "isolate or container?" stops being an architecture decision you make once and becomes a routing detail the agent resolves every command — over one filesystem that doesn't care which side ran.

For a solo builder, that's the difference between operating two systems (a fast lane and a heavy lane, with glue code to move files between them) and calling one runtime.

When to reach for it — and when not#

Reach for it when you're already building agents on Cloudflare and you want a single workspace that spans cheap-and-fast and full-Linux without running two stacks. It pairs naturally with the rest of the Agents Week kit we broke down here, and with Durable-Object-backed agent state.

Don't reach for it when you need a host-independent sandbox — if the point is to keep your code execution portable across clouds, a standalone E2B, Modal, or Fly sandbox is still the right call; @cloudflare/computer is Cloudflare-native by design.

And the load-bearing caveat: it's a Preview. Prototype the pattern, don't pin production to its exact API yet. Keep your agent's tool interface thin — a run_command(cwd, cmd) seam — so the runtime underneath is swappable when it goes GA or if you move off Cloudflare. That's the same discipline that keeps your sandbox from becoming your architecture.

What it costs#

There's no separate line item for @cloudflare/computer; you pay for the primitives beneath it. Isolate execution rides Workers / Dynamic Workers, the filesystem and workspace instance ride Durable Objects, and the container runtime bills as Cloudflare Containers — charged for every 10ms a container is actively running, with monthly included usage on the $5/month Workers Paid plan (pricing). The practical read: because the fast path is an isolate, most commands cost isolate-money, and you only pay container rates on the minority of commands that actually escalate. Budget it like a Workers app with occasional container bursts, not an always-on VM.

The one-line take#

@cloudflare/computer is the first agent runtime to treat "isolate vs container" as the agent's problem to solve per command, over one filesystem, instead of yours to decide up front. If you build on Cloudflare, it's the cleanest version of "give the agent a computer" yet — as long as you remember it's still a Preview and keep the seam thin. The companion move from the same week is giving each thing your agent builds its own database, which is Durable Object Facets — the storage half of the same story.