Containers vs Cloudflare Computer: There Is Not Enough Compute for One Box Per Agent

Giving every user their own AI agent has an obvious design. One Linux container each. A shell inside it, a filesystem, a package manager. It works on day one, and it works in the demo.

Then you count the machines.

Most of your users are asleep right now. Their agents are doing nothing at all. But every one of those users still owns a container, and you are paying for it. Either you keep it running, or you store a copy of it and make the user wait while you put it back.

The usual answer is that this is a cost problem, and a bigger budget solves it. Cloudflare says there is no budget that solves it. This is from the post they published on 3 August 2026, alongside a package called @cloudflare/computer:

across all the clouds, all the hyperscalers, there's nowhere near enough compute in the world for every company to give each of their users' agents their own containerized compute environment.

Read that again, because it is easy to skim past. It is not a claim about money. It is a claim about how many computers exist.

If they are right, then the choice nearly every agent framework made in the last two years is finished. That choice was simple: one agent, one container.

Why everybody picked containers

The container was a good answer to a real question, and the question was safety.

An agent runs code that a model wrote. Nobody wants that code touching a real server. Put it in a container and the damage stops at the container wall.

That part is still right. The mistake came one step later.

There is a difference between "untrusted code runs in a container" and "the agent is a container". The first is about safety. The second quietly decides where your user's files live, and the answer it gives is: on a Linux machine that has to keep existing, or be copied somewhere, for those files to still be there tomorrow.

Files are cheap to keep. Machines are not.

The flip

Cloudflare changed which one is the normal case.

An isolate is a small sandbox that runs inside a shared process. A browser tab is one. So is a serverless function. Two things about it matter here. It starts in roughly the time a function call takes, and one machine can hold a very large number of them at once.

What an isolate cannot do is run a normal Linux program. No apt, no native binaries. That one gap is why most people reached for a container and stopped thinking about isolates at all.

So Cloudflare gave the isolate the missing piece: a filesystem that stays behind after the isolate is gone. The container did not disappear. It stopped being the home and became a tool, borrowed for the jobs that really need Linux.

Their own description of the split is the clearest sentence in the whole announcement:

A job that only needs to manipulate files, process data, or manage a git repository can run inside an isolate. A command that needs Linux, npm, or a native binary can run inside a container.

And then the target they set themselves:

Our goal with @cloudflare/computer is to provide an agent with a runtime where a container is required for less than 10% of its work.

Everything else in the design comes out of that one number.

The filesystem is kept in a database because an isolate may only live for a few milliseconds, and the files have to outlast it. Cloudflare calls that filesystem a workspace, and it sits in a Durable Object, which is a small piece of compute with its own private database that you can reach by name. Each user, chat or repository gets one. There are two kinds of isolate, one that runs bash and one that runs JavaScript, because the more commands those two cover, the fewer times a container has to start. And when a container does start, it is not given its own disk. It borrows the same filesystem. Give it a disk and the files move back onto a machine, which is the thing this whole design is avoiding.

Which one to pick

A list of features is what vendors publish and it helps nobody choose. These are the things that actually decide it.

Read the last two rows twice before you get excited about the rest.

Why Cloudflare made this argument

This section is my opinion, not theirs.

Cloudflare is picking a fight it can win. It has spent about ten years building isolates, first for Workers and then for Durable Objects, and it can pack more of these small sandboxes onto a machine than anyone else. What it cannot do is beat AWS or Fly at running virtual machines. Building a normal container sandbox would have meant fighting on their ground with a worse hand.

So it changed the question instead. "Agents do not need containers" is a real engineering argument. It is also, very conveniently, the argument that makes Cloudflare's existing machines the right machines.

Both of those things are true at once, and the second one does not cancel the first. A company that has bet on something for ten years is usually the first to notice when the world starts to reward it.

What it should change is how you read the ten percent. That is a goal Cloudflare has set itself, not a number anyone has measured on a real product. Treat it as a claim to test, and go and measure your own.

Three other things come with this design, and they tell you what it is really for. It puts Durable Objects at the centre, and no other cloud has copied Durable Objects. It gives Cloudflare Containers a serious customer at a point when that product needed one. And it keeps other people's agents, along with their traffic and their model spending, on Cloudflare rather than at a sandbox company.

Where I would use it

Two things fit the shape.

The first is running other people's code. I teach a cohort course, and reading about an idea is not the same as running it. Offering that meant either trusting student code on my own server, which I will not do, or a container per student for people who show up twice. A fresh sandbox per run, over a filesystem that still holds last week's exercise, beats both.

The second is an agent a person comes back to. Most of what I build assumes the conversation is the unit and anything worth keeping goes in Postgres. That is right for records and wrong for what agents actually hold, which looks like files: notes, drafts, uploads, a log kept about someone over months. A folder per user that needs no machine behind it, searched by the agent, is simpler than the memory pipeline I would otherwise build.

What I would not move is anything that already works. The cost is not learning an API. It is a second production system on another platform, with its own deploys, its own monitoring, and its own way of breaking at three in the morning.

It is a preview, and it shows

Cloudflare labels this preview, unstable, and not suitable for production. All three words are doing work, and both fast isolate backends sit behind an experimental flag, so the most interesting half of the design is the half most likely to change under you.

The rough edges are real. Showing files to a container is slow when there are lots of small files, so use it to run a build, not to live in. A workspace holds roughly ten gigabytes, which is a working folder and not a large repository. And a Durable Object handles one thing at a time, so a workspace has one writer: right for keeping files consistent, wrong if two people need to edit at once.

The part I would adopt first is the dullest. Every file operation is checked and recorded, so you get a list of what the agent changed and what it was allowed to change. Anyone who has tried to work that out after the fact knows what the list is worth.

Where this leaves you

The idea travels. The code does not. A per-user filesystem that outlives the machine is something you could build on Postgres and Firecracker, and somebody will. Cloudflare's version is tied to Durable Objects, which no one else has, so picking it means picking a platform rather than a library. If you have never shipped to that platform, edge rendering with Cloudflare Workers is a gentler place to start than an agent runtime.

What I would stop doing today, on any platform, is treating a Linux box as the natural home for a user's agent. That made sense when a machine was the only sandbox we had.

Before your next agentic system design, count two things: how many of your users are awake at any one moment, and how many of your agent's commands really need a Linux binary. If both numbers are small, you are paying for machines whose only job is keeping files warm.

My rule, and I would defend it in a post-mortem: never let a user's data depend on a machine staying alive. Put the files somewhere that survives on its own, then make the computers as throwaway as they always should have been.