Cloudflare Wants Your Agent in a Container Less Than 10% of the Time

TL;DR

On Monday, Cloudflare released @cloudflare/computer, an MIT-licensed agent runtime built on a blunt bet: giving every agent its own Linux container is not going to work. The authoritative filesystem lives in SQLite inside a Durable Object, and three pluggable backends execute code against that one filesystem, with a real container held back as the expensive fallback. Cloudflare's stated design target is that the container handles under 10% of an agent's work. Its own README says the package is preview only and not suitable for production.

The argument, which is better than the product

The launch post makes a claim worth reading even if you never install the thing. Container-per-agent is the default architecture right now, and Cloudflare says it does not have a future:

There's nowhere near enough compute in the world for every company to give each of their users' agents their own containerized compute environment. This will not scale to hundreds of millions, then billions, of concurrent agents.

The observation underneath it is the useful part: most of what a coding agent does is not Linux. Reading a file, writing a file, editing a diff, listing a directory, grepping, cloning a repo, walking a JSON blob. None of that needs a kernel, a package manager, or a native binary. It needs a filesystem and something that can mutate it.

So Cloudflare split the two. The filesystem is the constant. The execution engine is swappable.

How it actually works

State lives in SQLite inside a Durable Object, which is Cloudflare's stateful serverless primitive. Three backends register against that filesystem and you pick which one runs a given command.

Think of it as a kitchen where the pantry never moves. What changes is whether you reach for the microwave, the hob, or the industrial oven, and the ingredients are in the same place either way. Cloudflare's argument is that most agent work is microwave work and the industry has been firing up the industrial oven to reheat a file diff.

The three backends

• Worker JavaScript. Runs ECMAScript modules with node:fs/promises support, so third-party libraries that expect a filesystem can be pointed at the virtual one.
• Worker shell. Runs shell commands through just-bash, a simulated bash environment written for agents. Note the publisher on that repo: it is a Vercel Labs project. Cloudflare's answer to the container problem runs a competitor's bash, which is the most 2026 sentence in this post.
• Container. A real Linux userland running a daemon called computerd, mounting the same SQLite filesystem over FUSE. This is the one you are supposed to avoid.

All three backends are optional. The filesystem works on its own, which means you can start with a workspace and no execution at all and add engines later.

The 90/10 bet

The stated goal is specific enough to hold Cloudflare to it later:

Provide an agent with a runtime where a container is required for less than 10% of its work, and coding tasks, audio/video manipulation, and document creation can all be handled by isolates.

That caveat matters. The launch post ships an architecture and an argument, not numbers. There are no published startup latencies, no cost comparison, no measured workload showing 90% of some real agent trace staying out of the container. If you are evaluating this, you are evaluating a design, and you will have to generate the evidence yourself.

What you get in the box

The package README lists a fairly complete agent surface, which is the strongest practical signal here. Filesystem methods cover readFile, writeFile, mkdir, readdir, rm, and grep. Process control covers exec, getExec, killExec, and disposeExec, so long-running commands are addressable rather than fire-and-forget.

Git is first class: clone, add, commit, and a general cli escape hatch. There is an AI SDK compatible toolkit exposing read, write, edit, ls, and optional exec and publish tools, which is the part that lets you drop this under an existing agent loop instead of rewriting one. Assets publishing, artifacts, and R2-backed read-only mounts round it out.

The repo is a monorepo of five packages: @cloudflare/dofs for the Durable Object filesystem, @cloudflare/computer-rpc, @cloudflare/computerd, the public @cloudflare/computer, and a prebuilt computerd binary. Eight runnable examples ship alongside.

The setup tax

Getting to a first exec() is not one npm install. You add the nodejs_compat compatibility flag, declare Durable Object bindings and migrations, and for either isolate backend you need an experimental flag plus a Worker Loader binding.

The limits are documented and reasonable for what this is. A workspace holds roughly 10 GB. The container's filesystem is held in memory, which is an explicit agent-scale design choice rather than a general-purpose disk. And FUSE I/O in the container is slower than native disk, which is the honest cost of making one filesystem visible to two very different execution models.

The sentence the launch post does not lead with

The README opens with this:

PREVIEW ONLY. This package is provided as a preview for feedback only. APIs are unstable and the design is subject to change. Suitable for experiments, exploration, and prototypes. It is NOT suitable for production use at this time.

So Cloudflare's position is that the industry's current agent architecture cannot survive contact with a billion concurrent agents, and its replacement is not ready for your customers yet. Both things can be true. But it does reframe what this release is: a design proposal with running code attached, published during a themed announcement week, not infrastructure you migrate onto this quarter.

Whether you should care

Care about the idea, regardless of vendor. If you run agents today, you probably provision a sandbox per session and pay for a full Linux environment so an LLM can call read, write, edit, and occasionally npm. Instrument that. Count how many of your agent's tool calls actually need a kernel. If the answer is under 10%, Cloudflare's thesis holds in your workload and the money you are burning on idle userland is real whether or not you ever touch a Durable Object.

The lock-in question is also real. The filesystem is a Durable Object, the isolates are Dynamic Workers, the containers are Cloudflare Containers. The MIT license covers the code, not the substrate. Moving this design to your own infrastructure means rebuilding the parts the package makes look like a simple import.

Try it if you are prototyping an agent harness and want to see what falls out when the container becomes the exception rather than the assumption. Do not put it in front of customers. The README already told you that, and unlike most preview labels, this one is on the first line rather than a footnote.

Key Takeaways

• Cloudflare released @cloudflare/computer on August 3, an MIT-licensed agent runtime where the filesystem lives in SQLite inside a Durable Object and execution backends plug in around it.
• Three backends: ECMAScript modules in a Worker, shell commands via Vercel Labs' just-bash in a Worker, and a real Linux container running computerd with the same filesystem mounted over FUSE.
• The stated design target is that a container is required for under 10% of an agent's work. Cloudflare published no benchmark backing that number.
• The API is complete enough to be useful: filesystem, process control, git clone and commit, and an AI SDK compatible toolkit.
• Documented limits: roughly 10 GB per workspace, an in-memory container filesystem, and FUSE I/O slower than native disk.
• The README says PREVIEW ONLY and explicitly not suitable for production. The argument about container-per-agent economics is worth stealing even if the package is not.

Sources: Cloudflare Blog, cloudflare/workspace on GitHub, @cloudflare/computer README, Cloudflare Durable Objects docs, vercel-labs/just-bash