Most agent sandbox products are sold on developer experience: here is an isolated place to run untrusted code, here is how you attach it. Cloudflare's @cloudflare/computer, released as an open source preview on 3 August by Matt Carey and Aron Carroll, is sold on something else entirely [1].
It is an argument about the total amount of compute that exists.
The sentence the whole design rests on: "there's nowhere near enough compute in the world for every company to give each of their users' agents their own containerized compute environment" [1].
That is a capacity claim, not a convenience claim, and it deserves to be taken seriously on its own terms. If every user of every product eventually has agents running on their behalf, and each of those agents wants a Linux box, the arithmetic does not work. Something has to give, and Cloudflare's proposal is that the container should stop being the default unit.
The design
An agent needs a filesystem, a shell, tools and the ability to run code. Cloudflare's move is to notice that it does not need a whole Linux userland for most of that.
So the harness lives in an isolate, inside a Durable Object, and a container is attached on demand as a tool [1]. The isolate is the same primitive that has run Cloudflare Workers for the better part of a decade: fast to start, cheap, horizontally scalable, and able to hibernate when idle.
Holding the two together is a virtual filesystem backed by SQLite, which can be populated from cloud storage, source control, or any files you choose [1][2]. Both execution backends see the same files. The isolate path uses just-bash, which translates shell code into JavaScript running in Dynamic Workers. The container path gets a FUSE mount, so files are visible inside the container and changes sync back [1].
The API is deliberately small. The core call is exec(string, options), and the toolkit exposes read, write, edit, ls and exec, with exec taking a backend argument that decides where the work runs [1]. There is also a node:fs compatible wrapper so third-party libraries that expect a normal filesystem keep working [1].
That is a genuinely tidy piece of engineering. One filesystem, two execution substrates, one call to run something.
The number to hold onto
Cloudflare states the target plainly: "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" [1].
Sub-10% is a falsifiable claim, and it is the right one to make. If a container is needed for half an agent's work, the architecture has added a layer without removing the scaling problem. If it is needed for 5%, the economics change substantially, because the expensive primitive is only paid for one call in twenty.
What is not in the announcement is any measurement of where that number actually lands. There are no benchmarks and no cost figures in the post [1]. That is entirely reasonable for an early preview, and it means the central claim is currently a design goal rather than a reported result.
Worth knowing before you plan around it, because everything downstream depends on which side of that 10% your particular workload sits.
The part nobody is discussing
Here is what makes this architecturally interesting rather than merely efficient.
The backend argument on exec has to be set by something. Cloudflare describes frontier models as effectively choosing between the fast, inexpensive worker backend and the container, "falling back to using containers only when needed" [1].
Read that again. The model decides which execution substrate to use, per command.
That is a real design choice with real consequences, and I have not seen it discussed anywhere in the coverage. It means the cost profile of your agent is now partly a function of model judgement. A model that reaches for the container reflexively lands you above the 10% target and the economics degrade. A model that avoids it too eagerly runs commands in an isolate that needed real Linux, and fails in ways that are probably subtle rather than loud.
We have spent this month on exactly this class of problem from other angles. Agents that report success they did not achieve. Delegated instructions that quietly lose the constraint they started with. This is the same shape: a decision moved into the model, where it is cheap to make and hard to audit.
The question I would want answered before depending on it is not whether isolates are fast. They are. It is: how often does the model pick correctly, what does a wrong pick cost, and can I see the distribution of that decision across a real workload? None of that is published yet, and it is the thing that decides whether sub-10% is achievable in practice or just achievable in principle.
The rest of the platform is moving the same direction
Two entries from Cloudflare's changelog in the weeks after the release make the strategy clearer than the launch post does on its own [2].
On 17 August, Qwen 3.8 27B landed on Workers AI with vision, reasoning modes and function calling [2]. On a later entry, FUSE support arrived for Containers in local development across Docker environments [2].
Take those together with @cloudflare/computer and the shape is obvious. The same platform now supplies the isolate, the container, the filesystem that spans them, the local development story for the FUSE mount that joins them, and the model that decides which backend to use. That is a vertically integrated agent runtime rather than a sandbox product.
Which is a strength and a lock-in at the same time, and worth naming as both. The strength is that the pieces are designed against each other rather than bolted together, and the FUSE-in-local-dev entry in particular removes the usual gap where the thing works in production and cannot be reproduced on a laptop. The lock-in is that the SQLite-backed workspace, the Durable Object placement and the isolate runtime are not portable primitives. An agent built on this does not lift to another provider without a rewrite of its execution layer.
What the coverage added, which was not much
The independent reporting on this is thin. InfoQ covered it on 7 August with an accurate architectural summary and the appropriate caveat that Cloudflare Computer is "still an early preview and is only suitable for experiments, exploration and prototypes" [3]. What it does not contain is a comparison against the other hosted sandbox providers, an independent assessment of whether isolates genuinely solve agent scaling, or any third-party reaction [3].
That is not a criticism of one outlet so much as an observation about how infrastructure launches get covered. The architecture diagram gets redrawn, the claims get restated, and the falsifiable number goes unexamined. If you want to know whether the sub-10% goal holds, nobody has checked, and the only way to find out for your workload is to measure it yourself.
Where this sits against the alternatives
The honest framing is that Cloudflare is making a different bet from the rest of the sandbox market, not a strictly better one.
The hosted sandbox providers give you a full Linux environment per session with a straightforward mental model: it is a machine, it behaves like a machine, everything you know applies. You pay for that in start-up latency and in cost per concurrent session, which is exactly the cost Cloudflare is arguing does not scale to a world of billions of agents.
Cloudflare gives you something cheaper and stranger: mostly not a machine, occasionally a machine, with a filesystem that spans both. If your agent's work is genuinely dominated by file manipulation, data processing and shell-shaped tasks, that is a large saving. If your agent needs native binaries, package managers and a real userland most of the time, you are in the greater-than-10% case and the extra layer buys you little.
Nobody has to guess which they are. Instrument the commands your agent actually issues, sort them into "needs real Linux" and "does not", and read the ratio off your own logs. That takes an afternoon and it converts a vendor's design goal into a fact about your system.
Worth saying about the timing
This shipped on 3 August, which makes it three weeks old rather than news. I am covering it now because the architecture argument has not dated at all, and because the interesting question about it has still not been answered by anyone.
Two things to keep in view. The preview is explicitly not production-ready, and Cloudflare says so [1][3]. And the API is still moving: the post notes that the useThink: true parameter "soon will not be needed", which is a small but clear signal that the surface has not settled [1].
Prototype on it, by all means. Measure your own container ratio while you do, because that is the number that tells you whether this design is for you, and it is the number nobody else can produce on your behalf.
References
[1] Matt Carey and Aron Carroll, Cloudflare — Your agent needs a computer, not a container: introducing @cloudflare/computer. Article
[2] Cloudflare Changelog — Preview: @cloudflare/computer agent runtime. Article
[3] Sergio De Simone, InfoQ — Cloudflare Launches Persistent, Stateful, Computer-Like Environments for Agents. Article