The 43x You Accept for the 0.66x

Cloudflare opened Agents Week on 2 August, and on 3 August published @cloudflare/computer: an open-source runtime that hands an agent a filesystem and a place to run things. The framing is economic. Giving every user's agent its own container does not scale, so the runtime routes work between cheap isolates and full Linux containers, with a stated target of needing a container for less than 10% of an agent's work.

That is a cost argument. The repository makes a different one.

What it actually is

The package is a SQLite-backed virtual filesystem living inside a Durable Object, with one execution entry point and three backends behind it. The container backend projects the SQLite state into a sandbox as a real FUSE mount, where a daemon called computerd syncs changes back over a capnweb RPC channel. The isolate shell backend runs just-bash in a Dynamic Worker. The isolate JavaScript backend evaluates an ECMAScript module in a fresh Dynamic Worker. All three address the same files, and a workspace can be constructed with no backend at all if you only want the filesystem.

The problem it saves you from hand-rolling is real: keeping an agent's working directory durable across restarts, and letting a shell command and a JavaScript call see the same tree without you writing the sync layer. That layer is where teams lose weeks.

Read the performance doc, not the post

The announcement does not publish benchmarks. The repository does, in docs/19_performance.md, measured on a Cloudflare Containers standard-2 instance with 1 vCPU, 6 GiB of memory and 12 GB of disk. Ratios are computerd divided by the baseline, so below 1.0 means computerd is faster.

Against the container's ext4 root disk, computerd wins on metadata: removing 1000 files at 0.66x, traversing a directory tree at 0.72x, a git init plus a 100-file commit at 0.72x, creating a directory tree at 0.74x, a shallow git clone at 0.84x, stat across 1000 files at 0.91x.

Against the same disk, it loses badly on bulk bytes: writing 64 MiB at 16.93x, reading it back at 39.72x, copying it at 40.46x, overwriting it at 43.35x. The doc names the mechanism rather than leaving it to inference — the write path hashes every 512 KiB chunk into a content-addressed blob store on release, which is what lets the Durable Object sync only changed chunks.

The composite number is the useful one. A full npm install of cloudflare/sandbox-sdk, 854 packages and 36,675 files, took 124.7 seconds on the FUSE mount against 63.9 seconds on ext4 and 34.3 seconds on tmpfs. Roughly 2x the disk baseline on a dependency install of that size.

So the adoption question is not what containers cost. It is the shape of your agent's I/O. An agent that greps, edits, stats and commits is running on the side of the table where this design wins. An agent that pulls model weights, unpacks tarballs or moves media is paying an order of magnitude, and the 10% container target will not hold for it.

That claim is falsifiable, and the repo ships the falsifier: run bash script/run-fs-bench.sh against your own workload shape. If a trace of your real agent is dominated by large sequential I/O rather than metadata operations, the argument above is wrong for you and the container backend is not an optimization you can defer.

Maturity, from the activity rather than the prose

The repo carries an MIT license and was created on 5 June 2026, under a different name — the old cloudflare/workspace path still redirects to it. In two months it has accumulated 566 commits on main from 6 contributors, 553 stars, 33 forks, zero open issues and five open pull requests, the oldest filed on 31 July. There are 17 tags, the newest v0.1.1, and no published GitHub releases behind them.

The npm registry is blunter. Four versions exist: 0.0.0 on 29 July, an alpha on 30 July, then 0.1.0 and 0.1.1 about 42 minutes apart on 3 August, the day of the announcement. The registry record was created five days before the blog post went up.

Both READMEs carry the same notice in bold: preview only, APIs unstable, not suitable for production use at this time. The top-level one goes further and says the specification under docs/ is forward-looking and should be read for intent rather than as a description of the code today. That caveat is worth sitting with, because the benchmark file lives in that same directory. The numbers come with a reproduction script, which is the only sane way to settle it.

One dependency deserves naming. The isolate shell — the cheap path the whole cost argument rests on — is just-bash, which is a Vercel Labs project, pinned as a caret range on ^3.0.1. That package is on 3.2.0 today, having shipped 97 versions since late December, and its issue tracker separately shows 97 open. Cloudflare's economics here inherit another vendor's release cadence.

Who should not use it

Anyone shipping this quarter. The preview notice is not boilerplate, and the gap between a prototype that works and a system that survives contact with real users is the whole subject of why enterprise AI doesn't ship. Also anyone expecting a large working tree: the documented limit is about 10 GB per workspace, shared with the Durable Object's own storage, and the container-side filesystem is held in memory — the README says to aim for agent-scale workspaces rather than full monorepos.

Three things to check before you spend a sprint on it. Your Worker needs the nodejs_compat flag, and the two isolate backends additionally need the experimental flag plus a Worker Loader binding. The computerd binary is no longer shipped inside the npm tarball, where it added roughly 120 MB; it now comes only as a container image, so the container backend costs you a registry pull. And pin the exact version rather than a range: latest resolves to 0.1.1 today, but the package config now carries a publish tag other than latest, so what a bare install gives you is a moving answer.

This is the right thing to prototype against in a week where you can throw the prototype away, and the wrong thing to put under a roadmap. If your evaluation harness is already telling you where an agent spends its time, that trace answers the adoption question faster than any pitch does — which is the argument in from PoC to production AI, applied to a filesystem.