@cloudflare/computer: an Agent Runtime That Treats a Container as a Tool, Not a Home

Cloudflare opened its Agents Week on August 3 with a different bet than its peers: instead of giving every agent a container, it gave every agent a filesystem and a choice of execution engines. The early preview of @cloudflare/computer, an open-source agent runtime, is built around one argument: the world does not have enough container compute for billions of concurrent agents, so the container should be the occasional tool, not the permanent home.

The package is installed with npm install @cloudflare/computer and runs on any Durable Object. Its centerpiece is a Workspace: a virtual filesystem backed by SQLite that can be populated from git repos, storage buckets, or plain files. All read, write, edit, and shell operations on that filesystem are gated, audited, and observed, so the agent leaves a paper trail of what it changed.

The brain/hands split, made literal#

The key architectural move is separating the agent loop from its execution environment. The harness runs in an isolate (the "brain"), and two execution backends provide the "hands":

• An isolate-based runtime that compiles shell commands to JavaScript via just-bash and runs them in a dynamic worker, with the filesystem available directly through worker bindings.
• A container backend using Cloudflare Containers, which gives a full Linux userland with npm, node, native binaries, and test runners. Files reach the container through a FUSE mount, and changes sync back to the shared workspace.

Both backends implement the same exec(string, options) interface, and both work against the same files. The agent is handed an AI SDK-compatible toolset (read, write, edit, ls, exec), where exec takes a backend argument. The tool description tells the model when to reach for the container: file manipulation, data processing, and git operations run in the cheap isolate; anything that needs a real Linux userland falls back to the container. Cloudflare says frontier models are "very good" at making that call correctly.

The positioning is explicit about the cost logic. Spinning up a container per user per agent "will not scale to hundreds of millions, then billions, of concurrent agents" - which is why the industry is scrambling for CPU compute, not just GPUs. Cloudflare's answer is the bet it has been making since Workers: isolates that spin up fast, hibernate when idle, store state, and scale horizontally. Last year it gave isolates the ability to attach container sandboxes on demand; @cloudflare/computer is the packaging of that pattern into a reusable runtime. Their stated target: a container is needed for less than 10% of an agent's work, with coding tasks, document creation, and media manipulation handled by isolates.

What this says about the agent infrastructure race#

This is the second major "sandbox as a product" play in a week, and the philosophies are nearly opposite. Vercel's sandbox multi-agent isolation starts from containers and isolates agents inside them; @cloudflare/computer starts from isolates and treats the container as a fallback runtime. Both are answering the same question: what does an agent actually need to act on the world? Cloudflare's answer is a filesystem contract plus pluggable execution, which is a deliberately thin abstraction - the workspace API is a node:fs-compatible wrapper, so third-party JavaScript libraries can use it without adapters.

Two details are worth watching. First, the workspace is durable by default because it lives in Durable Object storage, which removes the cold-start state problem that plagues ephemeral sandboxes. Second, the whole thing is open source from day one, positioned explicitly as "an experiment to learn with our customers," which suggests Cloudflare is gathering usage data on what percentage of agent work actually needs containers before committing to primitives.

The developer takeaway#

If you build agents on Workers, this replaces a chunk of custom plumbing: instead of writing your own sandbox orchestration, you get the workspace, the toolset, and the backend selection in one package, with examples for wiring it into @cloudflare/think agents and raw model loops. If you build agents elsewhere, the idea is the portable one: a shared, audited filesystem with a graded set of execution runtimes is a cheaper default than a container per agent. Given container boot times, per-second billing, and the horizontal-scaling ceiling, the "container only when needed" pattern is likely to show up in more harnesses over the next few quarters - the compute constraint is real for anyone running agents at scale, not just Cloudflare.

Continue Reading#

• Agent Workspaces Need Filesystem Contracts - why a defined filesystem boundary is the core of agent reliability
• AI Agent Code Sandbox Comparison 2026 - how the sandbox-as-a-service players stack up
• Agent Sandbox Architecture Guide - the tradeoffs in designing an agent execution environment
• Cloudflare Agent Memory Primitive - Cloudflare's previous agent-state play, also built on Durable Objects
• Vercel Durable Execution Programming Model - the competing durable-execution approach to long-running agent work

Sources#

• Your agent needs a computer, not a container - Cloudflare Blog (August 3, 2026)
• cloudflare/computer repository
• Cloudflare Containers docs
• Dynamic Workers docs
• just-bash