@cloudflare/computer Lets the Model Pick Its Own Runtime. That Tool Description Is Your Cost Policy.

Cloudflare's new open-source agent runtime hands the isolate-versus-container decision to the agent. Here's the mechanism, what the published benchmarks admit, and the one number you should be logging before you trust any of it.

Cloudflare shipped @cloudflare/computer on August 3 with a goal stated in plain numbers: a runtime where "a container is required for less than 10% of its work." That is not a performance target. It is a supply argument, and the blog post makes it bluntly. "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."

Now look at who decides whether any given command needs a container. Not your architecture. Not a scheduler. The model does, one tool call at a time, guided by a sentence you wrote in a tool description.

That is the part of this release worth arguing about.

The interesting piece is not the filesystem

Most coverage of this will lead with the durable virtual filesystem, and it is a nice piece of engineering. A Workspace lives inside a Durable Object, holds authoritative state in SQLite, and can be populated from git repositories, storage buckets, or whatever files you point at it. Every operation against it is gated, audited, and observable, which gives you a paper trail of what the agent touched.

Fine. Sandboxes with audit logs are the theme of the whole week.

The move that changes how you build is the second one. Cloudflare put three execution backends behind a single entry point, workspace.runtime.exec(source, { backend }), and then exposed that as a model-callable tool. The README describes the three as they ship today:

Container. Projects the SQLite state into a sandbox container as a real FUSE mount. A sandbox-side daemon called computerd mounts the state as a filesystem and syncs changes back over a capnweb RPC channel. Full Linux userland, real binaries, real network.
Isolate shell. Runs just-bash inside an on-demand Worker that reaches the authoritative Workspace over Workers RPC. No second store, no sync round trip.
Isolate JavaScript. Runs an ECMAScript module in a fresh on-demand Worker with structured input and results, durable relative imports, and Workspace-backed node:fs/promises, plus trusted ws:git and ws:artifacts modules.

The agent gets read, write, edit, ls, and exec through createAITools. Everything except exec behaves how you would expect. exec takes a backend argument, and Cloudflare's own words on how the model fills it in are these: "The tool description guides the agent into choosing the correct runtime for the task at hand: either a fast, cheap worker backend or the fully featured container. In our testing, the frontier models are very good at making the correct decision and falling back to using containers only when needed."

Read that twice. The economics of the entire runtime hang on a prompt.

Your default is the expensive one

Here is the shell config straight out of Cloudflare's own example:

shell: {
  defaultBackend: "container",
  backends: {
    container: {
      description:
        "Cloudflare Container with a full Linux userland: " +
        "npm, node, package managers, test runners, and real " +
        "binaries on $PATH. Use it when a task needs more than " +
        "file manipulation.",
    },
  },
}

Two things about those nine lines.

First, defaultBackend is "container". When the model does not express a preference, the heavier primitive wins. That is a safe default for correctness and the wrong default for the 10% goal, and both of those statements are true at once.

Second, the routing policy is one English sentence: "Use it when a task needs more than file manipulation." That sentence is the closest thing this system has to a scheduler. It says nothing about cost, nothing about latency, and nothing about preferring an isolate when either would work. If you want those preferences, you have to write them, because nobody else is going to.

I have spent enough time watching models interpret tool descriptions to be skeptical of any claim that they route "correctly" without a published number attached. The failure mode is not dramatic. It is a model that reaches for the container because the container description sounds more capable, on a task that was three sed calls, forty times a day, forever. Nothing breaks. You just never get near 10%, and you find out from the invoice.

The benchmarks are honest, and they explain the design

Cloudflare published the table where its own thing loses, which is the mark of a project worth taking seriously.

Running examples/container on a standard-2 instance (1 vCPU, 6 GiB memory, 12 GB disk), a full npm install of cloudflare/sandbox-sdk (854 packages, 36,675 files) takes 124.7 seconds on the computerd FUSE mount, against 63.9 seconds on the container's ext4 disk and 34.3 seconds on tmpfs. Roughly twice as slow as real disk on the workload people will try first.

Large sequential I/O goes worse. A 64 MiB pure copy runs 41.47x slower than disk. A 64 MiB pure read runs 39.72x slower. The README explains why instead of hiding it: the write path hashes every 512 KiB chunk into a content-addressed blob store on release, which is exactly how the Durable Object gets to sync only what changed and deduplicate identical content. You are paying throughput for sync and dedupe, on purpose.

Metadata work flips the result. Against the ext4 baseline, computerd comes in at 0.91x on stat of 1000 files, 0.66x on rm, 0.74x on a 10x10x10 mkdir tree, 0.72x on find, 0.72x on git init plus a 100-file commit, and 0.84x on a shallow git clone. Values under 1.0 mean it beats the disk. Those eight scenarios are most of what git status, module resolution, and incremental builds actually cost you.

The README lands the point better than the blog does: the throughput penalty "lands on raw dd-style throughput numbers but rarely on real developer workloads, which is why npm init + tiny install matches the disk baseline despite pure read 64 MiB being 30x slower."

So the bet underneath the runtime is that agent work is metadata-bound, not throughput-bound. Whether that holds is a property of your workload, not of the benchmark, which is why the next section matters more than this one.

Put this into practice

Nothing here needs a Cloudflare account to start.

Clone and build. git clone https://github.com/cloudflare/computer.git, then npm install, npm run build:all, npm test. You need Node 22 or newer, and the repo uses npm workspaces. Linux with FUSE if you want to run computerd end to end; the other packages build and test on macOS too.
Run examples/tutorial before anything else. It builds the whole idea from one endpoint and one file: an agent writes markdown on the host and then runs pandoc on it in the container, against the same filesystem. That one example explains the isolate-versus-container split faster than the blog post does. Budget twenty minutes.
Reproduce the benchmark on your own shape of work. bash script/run-fs-bench.sh locally, or upload script/fs-bench.sh to a deployed computerd-container instance and run it with MOUNT=/workspace BASE=/tmp. Change the file sizes to match what your agent actually moves. If your agent's day is small files and git metadata, you will like the numbers. If it moves 100 MB artifacts, you will not.
Log the backend argument on every exec call. This is the measurement that decides whether the whole premise works for you, and it costs one line. Compute your container share weekly. If it sits above 10%, one of two things is true: your workload genuinely needs Linux, or your tool description is losing the argument to the model's instinct for the more capable-sounding option.
Then rewrite the description and measure again. Give the isolate backends descriptions as specific as the container's, name the cost difference in words the model can act on, and consider whether defaultBackend: "container" is the default you want once you have data. Treat the description as a config value you tune, because that is what it is.

That fourth step is the one I would keep even if you never deploy this package. Any runtime that asks a model to pick a resource tier deserves a counter on the choice.

Honest limitations

The README opens with a warning in bold: "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." Believe it.

The docs/ directory is a design specification the maintainers describe as forward-looking. Their words: "read it for intent, not as description of the code today." So the most complete-looking documentation in the repo is the least reliable guide to what runs.

packages/computer, the top-level package the whole thing is named after, is marked "Work in progress" in the repo's own layout list.

The blog and the README disagree on a countable fact. The blog says two execution runtimes ship out of the box; the README says three backends ship today. Small, and the kind of drift a preview earns, but it is a reminder that neither document is a spec.

The claim carrying the most weight has the least evidence behind it. "In our testing, the frontier models are very good at making the correct decision" comes with no routing accuracy, no test set, no list of which models were tested, and no definition of "correct." That is Cloudflare's sentence and I am attributing it rather than repeating it. If the 10% target is your reason to adopt this, that sentence is your reason, and it is unmeasured in public.

On adoption, resist reading anything into either direction. When I checked, the repo showed 63 stars, 9 forks, 2 watchers, and 532 commits, under an MIT license. That is a lot of engineering and a small audience, which is what a day-old release from a large company looks like.

Large sequential I/O is genuinely slow, and no framing fixes that. If your agent transcodes video, ships big build artifacts, or streams large files, keep that work off the FUSE mount.

And the whole thing is Cloudflare-shaped. The Workspace lives in a Durable Object. If your agent does not already run there, this is not a library you drop in, it is a platform you move to. The blog is honest that this reflects how Cloudflare builds agents itself.

One last piece of housekeeping: the blog links github.com/cloudflare/workspace in its opening paragraph and github.com/cloudflare/computer everywhere after. The package appears to have been renamed close to launch, so old links and old package names are floating around this week.

The question this leaves open

Cloudflare has made an argument I think is correct, that the container is too coarse a unit for agent work and the industry cannot manufacture its way out of that. Handing the choice to the model is a genuinely different answer from every scheduler I have seen tried, and it might be the right one.

It also relocates a budget decision into a prompt. When the model picks the backend, the tool description becomes a spending policy that no finance process reviews, no linter checks, and no test covers. That is a new category of config, and right now it lives in a string literal in somebody's agent class.

So: log the backend field for a week on whatever you are running, even if it is not this. Then tell me what your container share was, and whether it was the number you expected. I have a guess, and I would like to be wrong about it.

Sources: cloudflare/computer README; Cloudflare blog, "Your agent needs a computer, not a container"; Cloudflare Agents Week 2026 updates.