Eh? Why do you feel it's inaccurate to call it a successor to sandstorm.io?
20,255 karma · joined December 12, 2011
Also created: capnproto.org, sandstorm.io, lanparty.house
I disagree. In fact, I find people who think of themselves as highly rational seem to be particularly prone to rationalization. Because being rational is integral to their whole identity, they are much more eager to accept their own rationalizations as sound and resist admitting that they are guided by instinct.
What makes you so sure your own brain doesn't work the same way?
We often make a decision based on a gut feeling, and then backfill a logical reason supporting our feeling, without even realizing we're doing it -- rationalization.
But also, the Cloudflare Workers Runtime is open source, so you could deploy it or your own machines, too, if you want:
I think I missed that and assumed it wasn't because it performed similarly to the dense models. Interesting!
I'm finding that the Mixture-of-Experts (MoE) models (Qwen 3.6-35B, and Nemotron 3.5 Lightning) are, well, terrible at this. They just couldn't get the job done at all. Went way off the rails. They are really fast though!
Whereas ~30B dense models (not MoE) are pretty decent. I tried Muse Glimmer, Gemma 4-31B, Qwen 3.6-27B, and Laguna XS[0]. They were all able to build a working collaborative whiteboard app, without any guidance (other than feeding back error logs to the model). I also asked each to then draw a monkey by calling the API of the whiteboard it has just built. Laguna drew random scribbles but the rest all managed to produce something monkey-like.
(Frontier models in comparison will write the app in one shot with no errors at all.)
Note that both Qwen 3.6 and Gemma 4 each have both MoE and dense variants. I find this very confusing, because e.g. ollama's model index typically only distinguishes variants by their size, but MoE vs. dense makes a huge difference in how they actually perform. IMO they should use a suffix, like Qwen 3.6-moe vs. Qwen 3.6-dense, or maybe Qwen 3.6-fast vs. Qwen 3.6-smart...
[0] EDIT: Turns out Laguna XS is MoE, I misunderstood. It performed similarly to the dense models. But maybe this explains why it couldn't write code and think about monkey shapes at the same time!
What would we have done differently in that case?
Didn't need it yet on day one. :)
We aren't that clever about naming at Cloudflare.
Do you know how we named Wrangler, our local dev tool for Workers?
Literally, the person that created it said: "I named this Wrangler because I wanted to give it a name so dumb that we definitely won't release it under that name and will come up with something better."
We didn't come up with something better later.
Honestly Cloudflare OS is kinda same thing. We brainstormed names last week trying to come up with something better but nobody could agree on anything so it just went out as Cloudflare OS, which is what we'd been calling it internally for no particularly good reason.
But I'm certainly not claiming that this alone is sufficient to comply with regulations. I have no idea.
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.)
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
The product name and logo are configurable in the admin settings.
Yeah it's a little cheesy. Sorry.
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.