The goal of this new design is to scale to a cluster while being operationally very easy to set up. Ideal for self-hosting.

NFSv4 is an easy first step, convenient because it's broadly understood, has many implementations, and requires no client libraries. I could imagine a follow-up to support LiteFS instead of NFS could make a lot of sense, though it'll get more complicated.

But yes, celld is definitely ahead of us here. No doubt about that.

If we open sourced Cloudflare's production scheduler, nobody would be able to use it because it is explicitly designed for HUGE, globe-spanning scale. Well, nobody except our direct competitors.

But the goal with workerd is actually that it should be pretty easy to run, about as easy as Node. Stateless workloads should scale trivially (just add more instances and load balance). For Durable Objects (statefull), currently it doesn't scale well at all, but I'm working on changes[0] so that it scales nicely across a cluster. I intentionally chose a design here that is operationally easy to set up. (Basically: just connect all the nodes to NFSv4.)

[0] https://github.com/cloudflare/workerd/pull/6780

The project is indeed in early stages. That's mentioned in the readme as well.

The reason I had to tell the agent this explicitly is because Fable's original plan called for an overly careful process involving a 2-3 day "spike" to test and derisk. It also wanted to write an elaborate test harness that would run every message through both the old and new paths and compare the results to ensure feature parity. It was way too cautious. I knew that the conversion would actually work fine. And, in fact, it did: the conversion actually fixed more bugs than it introduced.

I tweeted about this at the time: https://x.com/KentonVarda/status/2084293600142135365

It additionally optionally supports sending all requests through Cloudflare AI Gateway as a proxy. The same set of providers is supported either way, but when you configure AI Gateway, we assume you intend to install side-wide API keys into the gateway. The idea here is that you're setting up the gateway for your entire company, and you want all users to use the same keys. So we no longer let individual users configure their own keys in this mode -- instead they can choose from among the providers you have configured site-wide.

We will expand the provider list soon.

Cloudflare OS uses pi-agent-core, but not pi-coding-agent. pi-agent-core, at least the way CFOS uses it right now, is more of an LLM API compatibility layer than a full harness. All the tools and things like compaction are implemented by CFOS itself.

The code was actually using ai-sdk (from Vercel) up until a few days ago, when I switched it over to pi-agent-core.

Why doesn't it use Think? Mostly because Think actually didn't exist yet when I started writing this, and the designs diverged in a way that made retrofitting hard. The CFOS harness does a few unusual things, like tracking the entire state of the filesystem as the conversation progresses using Yjs (a CRDT), so we can actually rewind the state to see what the agent saw at any particular point in time.

I would actually like to delegate more to Pi, because I don't think CFOS should be in the business of thinking about how to implement compaction or to optimize editor tools for each agent. But I'm not really sure if it'll be possible without giving up some cool things about the CFOS harness, so we'll see.

https://github.com/cloudflare/workerd/pull/6780

But honestly I love that there are multiple implementations now.

There is ollama (local LLM) support in there.

But we'll probably expand it to everything pi-agent-core supports, just need some UI work.

But workerd can be used directly without wrangler, and is production-capable in that format.

Unfortunately we did not have time to put together example configs for this before launch (I wish we could have delayed, it was out of my hands), but we will be doing so soon.

Mentioned in the readme here:

https://github.com/cloudflare/cloudflare-os#deploy-to-your-o...

It absolutely does.

> doesn’t deal with physical memory,

Well it sort of does. It allocates sandboxes and schedules apps in them. It handles loading code from storage and turning it into running programs with state.

> it doesn’t initialize hardware or interface with it on a low level.

Instead of devices it manages interfacing with external services (Gatekeepers are like drivers).

I didn't choose the name but I do think there's a fair analogy here even on a technical level.

E.g. if you're using a slide editor app, each slide deck you create is its own instance of the app, whose code can be independently modified.

The slide content and the code are kept together and sandboxed together.

Adding HIPPA data to the app is no different to adding it to the slide content. I suppose whether or not that is OK depends on a lot of things, but the same things apply to traditional PowerPoint. The fact that the code is modifiable doesn't change the situation, since those modifications are sandboxed and constrained to that one slide deck.

Workers is my startup-within-Cloudflare. It won't make me a billionaire, but it has still made me more money than I actually know what to do with, while being able to delegate all the stuff I don't like doing to other parts of the company that already do it quite well.

I have a lot of influence here. The CEO and CTO listen to me. E.g. I made my argument this all needed to be open source and self hostable, and they agreed enthusiastically.

I don't think I could build this better as a separate company.

It's, I suppose, possible that the agent added secrets to the code itself. Not, like, API keys -- the agent never sees those. But it could have extracted sensitive info and put it into code, perhaps?

We can implement restrictions on exporting blueprints from workspaces that have seen sensitive secrets, though this might be more annoying than useful. It's a tricky balance.

Sometimes you just can't advance the state of the art while also maintaining broad compatibility.

It's all open source, though. You can run the whole stack on your own machine.