Why agents need more than a sandbox
Give an agent a real computer and it becomes more capable. Coding agents already work this way: a filesystem, a shell, packages, and the ability to run and test code turn the model into something that can iterate until the job is done. The key is that the environment is familiar and complete. Containers have been the default way to provide that environment, but they don’t scale to the volume of concurrent agents that agentic systems will demand. The world simply doesn’t have enough compute to give every user’s agent its own containerized environment.
Cloudflare is addressing that with an early preview of @cloudflare/computer, an open-source agent runtime that abstracts away where code executes. Each agent gets a computer — a workspace with a filesystem and execution backends — while the platform optimizes for efficiency and horizontal scale. Containers remain an option, but only when the task truly requires them.
The shift away from containers for agent harnesses
Earlier this year, spinning up a container and running an agent inside it was the standard approach. Recently, the pattern has shifted: harnesses now provide sandboxed code execution via tools, separating the agent’s decision-making loop from the environment where work is performed. But even with that separation, giving every agent a container still creates a compute bottleneck.
Cloudflare has long bet on isolates as the answer. Their key properties — fast spin-up and teardown, horizontal scalability, hibernation when idle, and the ability to spawn child isolates — make them a fit for agents that need to scale to millions or billions of instances. Isolates can store state, spin up their own work, and run untrusted code. The trade-off is that isolates lack the full capabilities of a Linux environment. Containers provide that vertical capability, and Cloudflare’s architecture has supported this hybrid model for a while. The agent harness runs in a Durable Object (an isolate) and calls a container on demand as a tool. That lets the system scale horizontally for the agent loop and vertically for heavy tasks. It works, but it puts the burden on the developer to orchestrate both compute primitives in userspace.
By shipping @cloudflare/computer as an open-source library, Cloudflare is making the runtime an experiment in simplifying that orchestration.
One filesystem, multiple execution backends
The central idea is simple: give agents a declaratively defined filesystem with everything the task requires, plus a set of execution environments that operate on those files. Agents choose the right environment based on the task. File manipulation, data processing, and git operations run fast and cheaply inside an isolate. Commands that need Linux, npm, or a native binary run inside a container. Both environments work against the same files, which stay synchronized with a durable source filesystem.
This enables a more granular approach. The runtime optimizes for using containers only when necessary — Cloudflare’s internal target is having containers needed for less than 10% of agent work, with coding tasks, media manipulation, and document processing handled by isolates.
Getting started with the runtime
A @cloudflare/computer workspace is instantiated on any Durable Object, giving you a virtual filesystem and execution APIs. Install it via npm, then create a workspace. The filesystem is backed by SQLite and can be populated from git repositories, storage buckets, or custom sources. It supports reading, writing, and editing files, and gives you gated, audited operations with a full paper trail.
The package provides a few execution backends out of the box, include one that translates shell code into JavaScript — which runs in a dynamic worker where the filesystem is available directly via bindings — and a container runtime that uses Cloudflare Containers to provide a full Linux environment. In the container case, the filesystem is exposed via a FUSE mount so changes sync back to the workspace. You can also write your own backend, as long as it implements the shared interface that accepts command strings and returns results. The primary use for the workspace is supplying that filesystem and those tools to an agent.
An AI SDK-compatible toolkit sits on top of the workspace for agent-facing tools like read, write, edit, ls, and a special exec tool. The exec tool takes a backend argument, and its description guides the model to choose a fast and cheap worker for simple operations or the full container when needed. Cloudflare indicates that frontier models are good at choosing correctly, falling back to containers only when the task requires it.
The workspace can also be used directly via a Command API, letting you prepare the environment before an agent begins, and it has a node:fs-compatible wrapper for easy use with third-party tools like simple-git or to convert markdown to PDF.
Implications for agent scale
This approach matters primarily for economics and scale. When agent tasks are orchestrated toward the appropriate compute primitive, horizontal scaling is efficient and costs stay manageable. Legacy cloud primitives were not designed for the pattern of many short-lived workloads; isolates were created precisely for that at scale. When an agent is idle or only needs lightweight operation, you aren't paying for a container.
As agentic systems grow, giving each agent its own dedicated process — isolated or otherwise — becomes a necessity. Those agents using only isolates can build, test, and deploy JS applications, craft personalized documentation, and run web-based tasks. When full OS-level capability is genuinely required, containers still exist within the same interface.
Even at this early stage, the key takeaway is a more temperate philosophy: for handling billions of daily agent workloads, the path forward lies not in massive container fleets alone, but in giving every agent only the compute it needs at any given moment.
