Cloudflare Computer Review: A Real Computer for AI Agents

#aiagents #opensource #cloudflare #developertools

Originally published on andrew.ooo — visit the original for any updates, code snippets that aged out, or follow-up posts.

The most capable AI agents all share one boring trait: they get a computer. A filesystem, a shell, packages, the ability to run code, inspect the result, and try again. That loop — act, observe, correct — is what separates a coding agent that ships a working PR from a chatbot that hallucinates a diff. The problem is that "give every agent a computer" doesn't scale. There is nowhere near enough CPU on Earth to hand a full Linux container to every one of the hundreds of millions of agents the industry is racing to deploy.

On August 8th, 2026, Cloudflare shipped an early preview of @cloudflare/computer to answer exactly that. It jumped past +1,000 stars in its first week on GitHub Trending. The pitch: give each agent a computer, but let the platform decide whether a given task runs in a millisecond-cheap isolate, a full container sandbox, or a browser — so a container is only spun up for the ~10% of work that genuinely needs one.

Key stats: Open-source preview (Aug 2026) | Built on Durable Objects + isolates | Three execution backends | Shared SQLite-backed filesystem | Preview only — not production-ready

TL;DR for Developers

Product:     Cloudflare Computer (@cloudflare/computer)
What it is:  Agent runtime that orchestrates isolates + containers as one "computer"
License:     Open source (preview; APIs unstable)
Built on:    Durable Objects (SQLite) + Cloudflare isolates
Backends:    Container (FUSE mount), Isolate shell (just-bash), Isolate JS
Filesystem:  One authoritative SQLite-backed VFS shared across backends
Status:      PREVIEW ONLY — "not suitable for production use at this time"
Best for:    Coding agents, doc/media tasks, anything needing persistent state
Not for:     Production workloads, stable APIs, GPU inference

The Core Idea: Separate the Brain From the Hands

Over the past six months, agent architecture went through a quiet but decisive shift. At the start of 2026, the norm was to spin up a container and run the whole agent loop inside it. By mid-year, harnesses had split the brain (the agent loop deciding what to do) from the hands (the sandbox where code actually runs). The hands became a tool the brain calls when it needs to execute something.

Cloudflare Computer takes that split and makes it the whole design. The agent harness runs in an isolate inside a Durable Object — cheap, hibernatable, and horizontally scalable to effectively infinity. When the agent needs to run a real Linux binary, it calls an attached container on demand, as a tool. When it just needs to run a shell command or a bit of JavaScript, that never touches a container at all.

Cloudflare's stated goal is blunt:

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, and coding tasks, audio/video manipulation, and document creation can all be handled by isolates.

The bet is a decade old. Cloudflare introduced Workers (isolates) almost 10 years ago and Durable Objects six years ago. Isolates spin up in milliseconds, hibernate when the agent is idle, store their own state in SQLite, and can even spawn their own isolates to run untrusted code. That's the horizontal-scale story. Containers give you the vertical-scale story — a real userland when you need pandoc, ffmpeg, or an arbitrary apt package. Computer stitches the two together.

The One Thing That Makes It Work: A Shared Filesystem

The clever bit — the reason tasks can hop between an isolate and a container without a mess — is that there is exactly one authoritative filesystem, and it lives in the Durable Object as SQLite.

Each backend just projects that state differently:

Container projects the SQLite filesystem into a sandbox container as a real FUSE mount. A sandbox-side daemon (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 in a Dynamic Worker. It reaches the authoritative filesystem over Workers RPC — no second store, no sync round-trip.
Isolate JavaScript runs an ECMAScript module in a fresh Dynamic Worker with Workspace-backed node:fs/promises, durable relative imports, and trusted ws:git / ws:artifacts modules.

Because all three read and write the same SQLite-backed store, an agent can write a file with a cheap isolate shell command, then hand it to a container to run pandoc on it, and the container sees the same bytes. Every operation is gated, audited, and observed — which matters a lot when the thing writing files is an autonomous model. The filesystem can be backed by a git repo, a storage bucket, or arbitrary files.

There's a subtle detail worth calling out: a Workspace can be constructed with no backend at all, giving you just the filesystem. That's a genuinely useful primitive on its own — a durable, auditable VFS you can attach compute to later.

What the Code Looks Like

The single execution entry point is workspace.runtime.exec(source, { backend }). The selected backend decides whether source is a shell command or an ECMAScript module. Backends connect lazily on first use and register under stable IDs, so one workspace can expose several.

A container-backed exec looks roughly like this:

// Inside a Durable Object / Worker
import { Workspace } from "@cloudflare/computer";

const ws = new Workspace(env, { /* backend config */ });

// Write a file via the cheap isolate path...
await ws.fs.writeFile("/recipe.md", "# Pancakes\n\n- flour\n- eggs\n");

// ...then run a real Linux binary in the container backend
const result = await ws.runtime.exec(
  "pandoc /recipe.md -o /recipe.pdf",
  { backend: "container" }
);

// The PDF now lives in the same shared filesystem
const pdf = await ws.fs.readFile("/recipe.pdf");

Need to run a shell command without paying for a container? Point the same call at the isolate shell:

const { stdout } = await ws.runtime.exec(
  "ls -la && wc -l /recipe.md",
  { backend: "isolate-shell" } // just-bash in a Dynamic Worker
);

The official tutorial example builds exactly this shape: one endpoint, one agent that writes a markdown recipe card on the isolate host and runs pandoc on it in the container to produce a PDF. Other examples generate a Worker project and publish it to Cloudflare Artifacts as a clone-ready repo, or turn a prompt into an image with Workers AI and return a shareable link. There's also examples/think-compare-runtimes, a web UI that runs the same agent task against the container and worker runtimes side by side — a smart way to see where the isolate path is good enough.

How It Compares

Computer sits in a crowded 2026 field of agent sandboxes — E2B, Daytona, Modal, Northflank, plus Cloudflare's own Sandboxes SDK (which went GA in April 2026). The difference is philosophical:

Sandbox-per-agent tools (E2B, Daytona, Cloudflare Sandboxes) give every agent a real container. Simple mental model, but you pay container economics for every agent, even idle ones.
Cloudflare Computer tries to make the container the exception, not the rule. Most work stays in isolates that cost almost nothing when idle and hibernate between turns; the container is a tool you reach for.

If Cloudflare's "less than 10% needs a container" claim holds even halfway, the economics are very different at the scale of millions of concurrent agents. That's the whole thesis: isolates are the horizontal-scale primitive, containers the vertical-scale escape hatch, and one shared filesystem makes the seam invisible.

Community Reaction

The GitHub Trending surge and coverage from InfoQ and others within a day of launch tell you the framing landed. The recurring take in developer circles: "Mac Mini farm for every user agent" and "always-on VPS per session" look like transitional hacks, not end states — and Computer is a credible bet on what replaces them. Isolates that hibernate and start in milliseconds, without billing a full guest OS while the model thinks, are an obviously better fit for spiky agent workloads.

The healthy skepticism is just as loud: this is a preview, the APIs are explicitly unstable, and the whole thing is deeply wired into Cloudflare's platform. It's not a portable library you drop into any stack — it's a bet on Durable Objects. Whether the isolate backends can really cover coding, audio/video, and document tasks as broadly as Cloudflare claims is the open question the community wants answered with real workloads.

Honest Limitations

Read this before you build anything on it:

Preview only. The README is unambiguous: "NOT suitable for production use at this time." APIs are unstable and the design is subject to change. The spec under docs/ is forward-looking — it describes intent, not what the code does today.
Platform lock-in. This is not runtime-agnostic. It runs on Durable Objects and Cloudflare isolates. There's no "just run it on my own box" path.
Cost model is layered. You're on Cloudflare's Workers Paid plan ($5/month floor), and container usage bills on top of Workers requests and Durable Objects — active-CPU rates plus storage. Cheap when isolates carry the load; not free.
The 10% claim is unproven at scale. "Less than 10% needs a container" is the design goal, not a measured result across arbitrary agent workloads. Media-heavy or exotic-binary tasks may push far more work into containers than the pitch implies.
No GPU story here. This is a CPU-compute play. If your agent needs GPU inference, that's a separate part of the stack.
capnweb / FUSE sync is new surface area. The container backend syncs a FUSE mount back to a Durable Object over an RPC channel. That's elegant, but it's also a novel, preview-grade data path — expect rough edges.

FAQ

Is Cloudflare Computer the same as Cloudflare Sandboxes?
No. Sandboxes (GA April 2026) give each agent a real container via the @cloudflare/sandbox SDK. Computer is a higher-level runtime that orchestrates isolates, containers, and browsers as one "computer," using containers only when needed. Sandboxes can be one of the backends Computer reaches for.

Can I use it in production today?
No. The maintainers explicitly say it's a preview for feedback only, with unstable APIs, not suitable for production. Use it for experiments and prototypes.

Do I have to run everything in a container?
That's the point of the design — no. Shell commands can run in just-bash inside a Dynamic Worker, and JavaScript can run in an isolate with a Workspace-backed node:fs. Containers are reserved for work that needs a real Linux userland.

How do files stay consistent between an isolate and a container?
There's one authoritative filesystem in the Durable Object, stored in SQLite. The container projects it as a FUSE mount and syncs changes back; isolate backends reach the same store over RPC. Every backend sees the same bytes.

What does it cost?
Pricing follows Cloudflare's Containers/Workers model: a $5/month Workers Paid floor, then active-CPU container billing plus Workers requests and Durable Objects usage. The savings come from keeping most work in cheap, hibernatable isolates.

Is it open source?
Yes — it's a public monorepo (@cloudflare/computer, @cloudflare/dofs, @cloudflare/computerd, and more), released as a preview. Read each package's README for its specific status.

The Bottom Line

Cloudflare Computer is one of the more interesting infrastructure bets of 2026 because it questions an assumption everyone else took for granted: that "give the agent a computer" means "give the agent a container." By making the isolate the default and the container the exception — held together by a single SQLite-backed filesystem — it's aiming at the one resource the agent boom is actually short on: CPU compute at planetary scale.

It is emphatically not ready for production, and it ties you to Cloudflare's platform. But as a preview of where agent runtimes are heading — hibernating isolates for the thinking, containers only for the heavy lifting, one filesystem to unify them — it's the clearest articulation yet of the post-container agent stack. Worth cloning the examples and running think-compare-runtimes to see how much of your own agent's work an isolate can quietly absorb.