Cloudflare says your agent needs a computer. We ran their filesystem on ours.

On 3 August 2026 Cloudflare open-sourced @cloudflare/computer, an agent runtime built around a simple claim: an AI agent needs a persistent computer, not a fresh sandbox that is thrown away after every turn. An agent that cannot remember the file it wrote ten minutes ago is not really working on anything.

We think the premise is correct. We disagree about where that computer should live.

So rather than write a reaction to the announcement, we read the code and ran it. The interesting finding is that the most useful part of it is not actually tied to Cloudflare at all.

What it actually is

The name invites the wrong mental model. This is not a container that persists. They did something more interesting: they split the computer in half and made only one half permanent.

Think of hot-desking. The desk is temporary, you get whichever one is free, and it is wiped every evening. Your locker is yours and stays put. Tomorrow you get a different desk and the same locker.

A container is the opposite arrangement. It gives you a private office, and every evening the office is demolished with everything in it. That is fine for a web server which never stops running. It is wrong for an agent, because an agent works in bursts with long gaps between them, and during the gaps nothing is running. You either keep an empty office heated all night, which is expensive, or you lose everything the agent did, which is useless.

So the files live in SQLite and are permanent. The thing that executes commands stays disposable and is recreated per turn. Between turns you pay for storage, which is almost free. You pay for compute only while the agent is actually working.

The argument they are making

Cloudflare's framing is that containers will not scale to the number of agents the industry expects. Their post says there is "nowhere near enough compute in the world for every company to give each of their users' agents their own containerized compute environment". Their answer is to run most agent work in lightweight JavaScript isolates, translating shell commands into JavaScript so that routine file operations never need a Linux kernel, and to escalate to a real container only when something genuinely requires one. They target under 10 percent of work hitting containers.

That is a real scaling problem if you are Cloudflare and you are hosting millions of other people's agents. It is not a scaling problem if you are one company running agents on hardware you own. Worth separating the engineering from the business model that shaped it.

The part that is not Cloudflare specific

The repository is MIT licensed and contains five packages. The one that matters is dofs, a SQLite-backed virtual filesystem. It has zero runtime dependencies.

Crucially, dofs is not written against Cloudflare's Durable Objects API. It is written against an interface. The entire coupling is this:

interface SQLStorageLike {
  exec(query, ...bindings): { toArray(): Row[] }
}
interface DurableObjectStorageLike {
  sql: SQLStorageLike;
  transaction?(closure);
  transactionSync?(closure);
}

That is the whole contract. One method that runs SQL and returns rows, plus an optional transaction wrapper. Cloudflare even ships an implementation backed by Node's built-in SQLite, with a comment in the source noting that the Workers SQL surface is a subset of Node's, so anything that runs on Node also runs on their platform.

The implication runs in the other direction too, and that is the part worth testing.

What we ran

Cloudflare's own Node implementation uses an in-memory database, which demonstrates portability but proves nothing about durability. So we wrote roughly forty lines swapping it for a file-backed SQLite database, built the package, and exercised it across three separate sessions: create a workspace, drop all process state, reopen from the file, mutate it, then reopen once more.

session 1: create an agent workspace
  PASS  4 entries written and listed

session 2: all process state dropped, reopen from the file
  PASS  README survived restart
  PASS  nested file survived
  PASS  300KB binary intact  size=300000
  PASS  binary bytes correct
  PASS  rename across directories

session 3: reopen again, confirm the mutations stuck
  PASS  mutation persisted across restart
  PASS  moved path persisted

  one sqlite file holds the whole workspace: 396 KB
  8 passed, 0 failed

The entire agent workspace, directory tree, text files, a 300KB binary and all, lives in a single 396KB SQLite file. The provider exposes more than fifty methods covering the usual POSIX surface: mkdir, readdir, rename, symlink, stat, watch, open, truncate.

No Cloudflare account. No Durable Objects. No network.

One bug worth knowing about

Our first attempt failed, and the failure is instructive if you try this yourself.

We returned a lazy cursor from exec, deferring the query until someone called toArray(). But the library's Database.run() discards the cursor without ever calling toArray(). Every schema statement silently did nothing, and the failure surfaced three statements later as a confusing "no such table" error pointing at a table we thought we had just created.

Execute eagerly. The interface looks lazy and is not.

What forking gets you, and what it does not

The licence is MIT, so anyone can fork this, modify it, rebrand it, and ship it commercially. That is not the interesting question. The interesting question is what you actually get.

You get a durable, transactional agent filesystem that runs anywhere Node runs, with no vendor account attached. That is genuinely useful and it is the hard part to write well.

You do not get the execution half. The isolate-versus-container routing, the shell-to-JavaScript translation, the hibernation behaviour, that is where Cloudflare's actual product lives and it is coupled to their platform. A fork gives you the workspace, not the runtime. Anyone telling you otherwise has not read past the README.

The sync layer has no network in it

This is the part we did not expect. The sync module contains no Cloudflare references, no object-store calls, and no HTTP at all. What it exposes instead is a change feed: fetchChanges(db, cursor) yields everything that changed since a cursor, and fetchObjects(db, hashes) yields content addressed by hash.

That is a git-shaped design with no opinion whatsoever about how bytes travel. You supply the transport. Which means the two things that normally weld a library to a platform are both absent here: the storage coupling is a single method, and the sync coupling does not exist.

What you would actually build with it

Take a delivery driver or a service technician. They photograph a delivery order on a phone. It lands in an agent workspace held in a single SQLite file on the device. The phone is in a warehouse basement with no signal, which does not matter, because the agent is working locally against a local filesystem. When the phone rejoins the company network, the workspace syncs to the machine in the office and the document is processed there.

At no point does the document pass through a cloud. That is the whole difference. Every mainstream version of this flow, whether a storage service or a SaaS capture app, routes the document through infrastructure belonging to someone else. This one goes from the phone to a server the business owns.

Two further properties matter more on a phone than on a server. The filesystem is transactional, so an operating system killing your app mid-write leaves you consistent rather than corrupted, which on Android is a routine event rather than an edge case. And because the entire workspace is one file, the answers to the questions a client actually asks become simple: encrypt one file, back it up as one file, and wipe one file when an employee loses the handset.

On porting it

Because the SQL contract is one method, any SQLite binding on any platform satisfies it. The obstacle is not portability, it is that the package is JavaScript and most Android work is not.

The pragmatic route is not to port the code at all. The schema is seventeen statements. Reimplementing it over the platform's own SQLite gives you a native application with no embedded JavaScript engine, and you keep the part that is actually valuable, which is the change-feed design rather than anyone's TypeScript. Take the protocol, not the dependency.

The caveat, stated plainly

The version is 0.1.0-alpha.1. Every README in the repository carries the same warning: "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." The specification under the docs directory is explicitly forward-looking, describing intent rather than the code as it exists today.

We are reporting a verified experiment, not recommending anyone put this in front of customers next month. Those are different claims and the difference matters.

Why this matters if you run a business rather than a platform

Strip away the vendor framing and Cloudflare has published a careful argument that agents need persistent state that survives between sessions. We agree. The question that follows is simply where that state sits.

If your agent's working memory holds supplier invoices, delivery orders, patient records or client files, the answer is not somebody else's infrastructure, however well engineered. It is a machine in your building, where the data was already sitting, under a filesystem you can inspect and back up like any other file.

That was already our position. What changed this week is that one of the largest infrastructure companies in the world published the architecture argument for us, and then open-sourced a filesystem that runs perfectly well on hardware they do not own.

We tested it because a claim you have not run is just a claim.