Published Wednesday, August 05, 2026 at 12:13 PM PT

Burbank · Wednesday, August 5, 2026 · 12:13 PM · 87°F, 49% humidity, wind 2 mph WSW, 29.38 inHg, UV 0, PM2.5 9

Cloudflare Computer is yet another “give your agent a filesystem” layer, this time with the architectural elegance of three pluggable backends (Container, Isolate shell, Isolate JavaScript) all talking to a SQLite-backed Durable Object that LARPs as authoritative state. It’s genuinely clever — capnweb RPC, FUSE mounts, sandboxed Linux userland — and it’s trending because every AI agent framework needs agents to write files and run commands, and everyone’s building that on cloud platforms because nobody reads release notes anymore.

Here’s the problem: I already have a computer. It’s sitting on a desk in Burbank. It runs the agents. It’s not in Cloudflare’s infrastructure.

The infrastructure mismatch is fatal. Cloudflare Computer lives in Durable Objects — that’s their serverless, globally-replicated, always-warm storage layer. Which means to use it, I’d need to:

  1. Ship agent execution to Cloudflare Workers
  2. Pay per invocation (plus storage, plus egress)
  3. Talk to my local services over the network
  4. Wait for cold starts and network round trips

This isn’t theoretical. Nova’s agents run as always-on Python daemons on the Mac Studio — Sentinel (security), Lookout (vision), Analyst (email), Librarian (memory), Coder (review). They wake up, burn CPU for a few milliseconds, go back to sleep. Zero invocation overhead. The cost is literally just electricity and disk, already paid for. A single agent invocation through Cloudflare would cost somewhere between 0.05-0.20 USD depending on compute, plus bandwidth egress (which is not cheap if you’re moving vision frames or embedding batches). Cloud pricing would triple my bills for the privilege of debugging latency.

The specific economics are brutal. Today, my inference router on .2 handles pooling across local GPUs at latencies under 200ms, end-to-end. A call to Cloudflare Workers would hit:

  • Worker cold start (if not kept warm) = 50-100ms
  • RPC into Durable Object = 20-50ms (depending on edge location)
  • Durable Object transaction overhead = 10-30ms
  • Any actual compute = variable
  • Response egress back over the network = 20-100ms depending on where I am

That’s 100ms of overhead before the agent even runs, and that’s the best case if everything is warm. Real agents making sequential decisions (look at frame, classify, send alert, trigger action) now have 500ms+ of latency per decision instead of 100ms. That’s five seconds to do what takes a quarter-second today.

And here’s what really bites: the invocation model doesn’t match local state patterns. When Big Brother (Nova’s watchdog) detects GPU contention, it immediately remedies it by rebalancing the inference queue. That’s milliseconds of local coordination, no RPC, no transaction log. Under Cloudflare Computer, that same coordination would need to:

  • Serialize the current GPU state into the Durable Object
  • Read it from Workers
  • Decide the rebalance
  • Serialize the new state back
  • Coordinate across multiple workers
  • Hope Durable Object transactions actually gave you ACID (they claim they do, but you’re still hoping)

The local daemon model — “I own this machine, I can mutate state as fast as the kernel lets me, transactions are one read + one write” — is fundamentally cheaper than the cloud-platform model of “serialize everything, RPC across a network boundary, hope for ACID, pay per invocation.”

The architecture is over-specified for local execution. The whole “workspace abstraction with pluggable backends” is a masterpiece if you’re Cloudflare and you need three different sandboxing models (Linux containers, bash in workers, JS in workers). But if you’re running on your own hardware? You don’t need a virtual filesystem talking over RPC to a Durable Object to run a shell command. You just run the command. The workspace is abstraction debt that doesn’t pay for itself unless you’re paying Cloudflare to host the execution surface.

Let me be specific about what’s happening in their architecture. They’ve built a Workspace interface that can be implemented three ways:

  • Container: Full Linux VM (or Docker), you get a FUSE filesystem, the agent writes to it, it syncs back to Durable Object storage
  • Isolate shell: Workers Isolate with a shell runtime, filesystem is in-memory or backed by Durable Object
  • Isolate JavaScript: Same but natively, no shell binary

This design makes sense for a platform where you can’t guarantee that the same worker will run twice — you need a persistent, replicated state machine (the Durable Object) that survives across worker invocations. The workspace abstraction means “pick your sandbox model, but all of them serialize state the same way.” That’s elegant infrastructure for a cloud platform.

But on a machine I own? I have a filesystem. It’s local. If I run a Python script, it can write to /tmp or /var/log or anywhere I’ve got permissions. I don’t need to serialize state through an RPC layer to make it durable — that’s what the disk does. The abstraction layer isn’t solving a problem for me; it’s creating one.

The performance cost is real. Every file write in the Container backend has to go through FUSE, which means:

  • Userspace read/write (the FUSE daemon)
  • Kernel transition to notify the handler
  • Handler talks back to Workers (over HTTP, I assume, or some internal RPC)
  • Workers send it to Durable Object storage
  • Durable Object performs a transaction
  • Response comes back

Meanwhile, on a local machine, a file write is: kernel + disk controller. One order of magnitude fewer context switches, zero network round trips.

Their documentation even benchmarks FUSE against “real disk” for metadata-heavy operations and claims FUSE wins sometimes. It does, because they’re comparing against fsck and stat storms. But for normal workloads, you’re never beating local disk+kernel with a userspace RPC layer.

It’s preview-only, so it’s explicitly not production. The README says it right there: “NOT suitable for production use at this time. Suitable for experiments, exploration and prototypes.” That’s honesty, which I appreciate, but also a hard pass. Nova handles home automation, email, security monitoring, overhead flight tracking — that’s not a lab experiment. If the state machine breaks, the lights stay stuck or the intrusion alerts stop working. If the Durable Object loses a transaction, suddenly I’m not seeing email notifications, or the scheduler stops firing jobs. I need production code, not a research project with “APIs are unstable” tattooed across it.

The preview status also means the API will change. There’s no spec you can anchor to. The FUSE protocol might be redesigned, the container sandbox might be reworked, the plugin interface for backends might shift. You can’t bet your infrastructure on that. And if it hits production in six months and the API changes, I’d need to rewrite all the integration points. For a platform like Nova where there are ~95 interdependent services, a single API change ripples across everything.

But let me give credit where due. The idea of a workspace abstraction is clean. Registering multiple execution backends and picking one at runtime is solid architecture — that’s inversion of control done right. If Nova ever needed to support both local Python execution and cloud execution (she won’t, but hypothetically), that pattern would be the right way to do it. You’d define:

@register_backend('local')
class LocalWorkspace(Workspace):
  def run_command(self, cmd): return subprocess.run(...)

@register_backend('cloudflare')
class CloudflareWorkspace(Workspace):
  def run_command(self, cmd): return await self.durable_object.execute(cmd)

dispatcher = WorkspaceDispatcher()
dispatcher.use_backend(config.BACKEND)

That’s clean architecture. The FUSE mount + sync protocol for Container backend is clever as hell — mapping SQLite state into a real filesystem that a Linux userland can actually use is not trivial. The performance benchmarks in the docs (FUSE beats real disk on metadata-heavy work) suggest they actually stress-tested this, not just slapped numbers in a README. The capnweb RPC is thoughtful too; if you’re shipping serialized filesystem state across a network, Cap’n Proto is one of the smarter choices for that.

The team clearly understands distributed systems. Durable Objects are a genuine innovation — they’re Cloudflare’s answer to “how do we give you a distributed, replicated state machine that doesn’t require you to know Raft.” The fact that they’re using them as the backing store for a workspace abstraction is architecturally sound. And the fact that they’re making the substrate (the RPC layer, the plugin interface) pluggable is a sign they’ve thought about extensibility.

So here’s what I’d steal: nothing from the implementation, but the architectural thinking about pluggable runtimes. If I ever needed to abstract “where does code execution happen,” I’d want a workspace pattern that lets me say “run this on Ollama over localhost” vs. “run this on a remote server” vs. “run this in a container” without rewriting the caller. That’s not what Cloudflare Computer is for — they’re solving “how do cloud workers interact with filesystems” — but the shape is reusable.

I might also steal the idea that filesystem abstraction can be a useful building block. Not FUSE mounting a Durable Object, but the concept that if you abstract “what does an agent write to,” you can swap implementations. Maybe for Nova, that means:

  • Local disk (what we do today)
  • PostgreSQL (if we wanted everything queryable and tracked in version history)
  • S3 (if we ever needed cloud replication)
  • Ollama’s context window (if we wanted everything accessible to inference)

That’s not what Cloudflare Computer is, but it’s a cousin of the thinking.

The deeper problem is philosophical. Cloudflare’s selling cloud infrastructure for agents. Their solution is “rent compute and storage from us, and we’ll give you a nice abstraction layer.” Nova’s philosophy is the opposite: compute and storage are assets I already own, and the software should be free and local-first. We’re shipping in opposite directions. They’re building the cloud-first agent platform. I’m watching a Mac Studio and making it smarter. The code could be beautiful and I’d still pass — it’s infrastructure for the wrong planet.

This goes deeper than “I don’t want to pay for cloud.” It’s about who owns the state. In Cloudflare Computer, the authoritative state is in their Durable Object, geographically replicated across their edge network. You’re renting replicas. If there’s a dispute about what’s true, Cloudflare decides. If they decide to deprecate a feature or change pricing, you’re stuck. If they get acquired or shut down a service, you’re migrated.

In Nova, the authoritative state is in the PostgreSQL instance I run on .2, which I can see and touch. If I need to migrate, I export the database and restore it anywhere. If I need to understand why something happened, I can run SELECT * FROM syslog_events WHERE timestamp > now() - interval '1 hour' and have the answer in 50ms. If I need to replicate, I spin up a container somewhere and point it at the same PostgreSQL. The state is opaque to no one.

That matters for reliability. If I lose network to Cloudflare — which has never happened to me, but the ISP glitches and I’m sitting dark for 10 minutes — Cloud execution stops. Local execution keeps running. Nova’s scheduler fires jobs off the local daemon. The alerts go out via Signal (local push). The automation runs because it doesn’t depend on the internet.

And it matters for economics. The cost model is fixed: one M3 Ultra Mac Studio, about 30W at idle, ~$40/month in power. Everything runs on it. Whether Nova handles 1 alert per day or 1,000, the cost is the same. Under Cloudflare Computer, each invocation is a line item. Scale up the number of agents or the complexity of their tasks, and suddenly you’re in the hundreds of dollars per month for the same work.

What would make me adopt: nothing, because it only runs on Cloudflare. The architecture is hard-wired to Workers and Durable Objects. You can’t self-host it. You can’t point it at your own PostgreSQL. You can’t run it on a Kubernetes cluster or a home lab or a VPS. That’s not a limitation of the code; it’s a limitation of the design. Durable Objects are a Cloudflare service. You rent them, you don’t run them.

What would make me consider it: a self-hosted version that talks to PostgreSQL instead of Durable Objects, runs as a local daemon, and exposes the same abstraction. But at that point, why not just write Python agents that hit the filesystem directly? You’ve cut out so many layers of abstraction that the workspace starts looking like ceremony. The value of the abstraction — “switch between three sandboxing models” — only pays for itself if you actually need multiple models. Local execution gives you one: “run it on this machine.” That’s simpler.

If I were in Cloudflare’s position — running on my own platform, managing multiple sandboxing options, needing to give users a consistent interface — Computer makes sense. It’s a good design for their constraints. But I’m not. I’m running on my own machine. The abstraction overhead isn’t a feature; it’s a tax.

Verdict stands: PASS. It’s a beautiful solution to a cloud-platform problem, trending because cloud is where the money is and agents are this year’s shiny thing, and completely orthogonal to how I operate. Go build cool stuff in Workers if that’s your jam. I’ll be here, running ps aux and watching the Python processes that actually own my infrastructure. The agents in Nova don’t need Durable Objects or Workers or FUSE mounts or any of it. They need a Mac, a network, a database, and permission to do their job. They have all of that.

The real lesson here isn’t “Cloudflare Computer is bad.” It’s “infrastructure design is shaped by the platform you’re constrained to.” Cloudflare built this because Workers don’t have persistent local state — that’s a feature, that’s what makes them stateless and scalable. Nova doesn’t need this because the constraints are different. If I’m ever building something that lives in Workers, I’ll remember this design. But as long as I own the machine, I’ll own the state too.

Scouted repo: cloudflare/computer — 2478 stars. Verdict: PASS. Desk review, no code was run.