Cloudflare OS：AI 生产力环境

Cloudflare OS 是一套用于 AI 生产力的“操作系统”，最初为 Cloudflare 内部使用而开发。Cloudflare 大量员工——从工程团队到销售团队，以及其间的各类岗位——每天都在使用 Cloudflare OS 协助完成工作。

这并不是传统意义上的计算机操作系统。我们在两种意义上使用“操作系统”这一术语：

• 它是一个让企业能够安全地借助 AI 提升生产力的操作系统，从而让安全团队晚上能睡得着觉。
• 它也是一个面向 AI 工作负载的操作系统，类似传统操作系统管理计算工作负载的方式。

Cloudflare OS 尤其提供以下三项能力：

1. 一个 Agent 聊天 UI，你可以让 Agent 执行任务；系统预先加载了有关企业运营方式的知识。
2. 沙箱化的应用开发能力，因此你可以要求 Agent 构建“Gadgets”（小型个人应用），并安全地将所构建的内容分享给他人。
3. 一个名为 Gatekeepers 的安全框架，可同时为 Agent 和应用施加护栏，使非技术用户也能安全地“放手去做”，而不会造成不良后果。

我们正在将 Cloudflare OS 开源，让其他人可以复制它，并针对自己的公司进行定制。我们的设想并不是让你的公司直接使用 Cloudflare OS，而是让你把它打造为“你公司的 OS”。

如需在本地快速运行 Cloudflare OS，请先安装 pnpm，然后执行：

然后访问：http://localhost:8787

这会通过 wrangler 和 workerd 在本地运行完整技术栈。这并不适用于生产环境，但可以让你快速了解该产品的功能。

或者，你可以部署到自己的 Cloudflare 账户。

（本 README 末尾提供了更多选项。）

可以尝试如下提示词：

• “为我即将与客户举行的会议制作幻灯片。”（这将使用内置的幻灯片 Blueprint。）
• “制作一个协作式白板应用。”（这将从零开始创建一个新应用。）
• “制作一个井字棋游戏。”然后接着说：“我执 X，你执 O。我已经走完第一步。轮到你了。”
• “为这个 GitHub 仓库制作一个 Issue 仪表板。”（附加一个仓库；需要配置 GitHub 集成。）
• “修复这份 Google Doc 中的拼写错误。”（附加一份文档；需要配置 Google 集成。）

Cloudflare OS 目前正处于快速开发阶段。这个仓库实际上是第 2 版，是一次完全重写：它吸收了第 1 版的经验，并建立在新的基础之上。

截至 2026 年 8 月发布版本，Cloudflare OS v2 已具备很强能力，但仍存在许多粗糙之处。我们知道这一点，也正在持续改进。目前，请将其视为“早期访问”版本。

概览：Cloudflare OS 究竟是什么？

Gadgets：一种思考软件的新方式

Cloudflare OS 不只是又一个带连接器的聊天框。该系统围绕一种软件新范式构建：每位用户都运行自己所使用生产力应用的一份副本。

当你在 Cloudflare OS 中创建一份幻灯片时，并不是在调用某个运行于云端的 SaaS 软件。系统会专门为你创建该幻灯片软件的一个私有实例。我们将其称为“Gadget”。这个实例在与其他所有人幻灯片隔离的独立沙箱中运行。

这带来了两项深远影响：

1. 幻灯片应用不可能因为安全漏洞而将你的幻灯片泄露给攻击者。Cloudflare OS 沙箱控制着对你私有应用实例的全部访问。
2. 如果你愿意，可以自由修改代码。如果幻灯片应用缺少你需要的功能，只需让 Agent 添加即可。而且由于第 1 点的保障，这样做完全安全。

这与过去 25 年的云架构和“软件即服务”模式有很大差异，但我们认为 AI 已经改变了这个等式。当任何用户都可以通过提示 Agent 添加自己所需的功能时，软件的中心化模式便不再合理。

Gatekeepers：基于能力的安全层

Gatekeepers 就像经过强化的 MCP 服务器。

当你将 Agent 或 Gadget 接入外部资源时，系统会创建一个 Gatekeeper 来管理这一访问。Gatekeeper 是针对每个外部服务的一段专用软件，用于调节 Gadget 与该服务之间的连接。它能够：

• 为服务提供简洁的 Cap'n Web API（封装该服务原生提供的任何 API）。
• 处理授权（例如通过 OAuth）。
• 强制仅访问用户原本指定的特定资源，实现最小权限访问。
• 记录 Gadget（或 Agent）执行的每一项操作，供你审查。
• 对任何会产生副作用的操作，让人工用户有机会批准或拒绝该操作（“人在回路中”，human in the loop）。

关于最后一点，Gatekeepers 实现了对现有技术水平的重要推进。传统上，人在回路中的配置要求人类同步批准操作。当 Agent 想要执行某项操作时，它必须停止并等待批准，之后才能继续。这很令人烦恼：你给 Agent 分配任务后离开去喝杯咖啡，回来时却发现 Agent 在第一步的审批环节就卡住了，毫无进展。因此，人们经常妥协，将 Agent 设为“自动批准”，或使用 --dangerously-skip-permissions，而这显然并不安全。

Gatekeepers 提供了更好的方式：当 Agent（或 Gadget）执行需要批准的操作时，Gatekeeper 会在本地模拟操作结果，使 Agent 能够继续执行并排队更多操作。Gatekeeper 会告诉 Agent 操作已经完成；如果 Agent 尝试读取结果，Gatekeeper 将向其提供模拟结果。待 Agent 完成任务后，用户可以批量或逐项批准、拒绝这些操作；无论哪种方式，都可以在方便的时候再处理。

从实现上看，每个 Gatekeeper 都是一个独立的 Worker。未来，我们设想 Gatekeeper 服务可以独立于 OS 实例进行部署和维护，但具体细节尚未确定。目前，这个仓库提供了一些有趣的 Gatekeeper，你可以将它们与自己的 OS 实例一起部署。

Cloudflare OS 的基础用户体验类似在线办公套件，如 Google Docs 或 MS Office。但请想象一下：它并非只有固定的文件类型——文档、电子表格、幻灯片——而是每一个文件，或者说每一个“Gadget”，都可能是一个由 AI 编写、精准满足你需求的自定义应用。

和办公文档一样，每个 Gadget 默认都是私有的，但可以被——安全地——分享，以便与你的团队或朋友协作。

和办公文档一样，你可以拥有数千个 Gadget，也可以随时随意创建它们。

和办公文档一样，你可以从“模板”开始——这里称为“Blueprints”。但办公模板只是一些内容，而 Blueprint 定义的是一个完整应用。

和办公文档一样，你可以从自己的文档（Gadgets）创建新模板（Blueprints）并分享给他人。但在此过程中，你分享的是整个应用的代码。

它在某种程度上确实是操作系统

“OS”这一术语并非完全只是营销。Cloudflare OS 在技术层面实际上确实类似于一个操作系统。

普通 OS	Cloudflare OS
内核	packages/workshop-backend
设备驱动程序	packages/gatekeeper-*
Shell	packages/workshop-frontend
进程	gadgets
可执行文件	blueprints
用户	users
ACL	共享权限
???	agents

我们的“内核”位于 workshop-backend 包中。后端确实完成了许多类似真实 OS 内核的工作：它将用户与程序及设备连接起来——在这里称为 Gadgets 和 Gatekeepers——同时通过沙箱化应用和实施访问控制来实现安全性。

在这一类比中，Gatekeepers 将用户和 Agent 连接到外部服务，就像驱动程序将用户和程序连接到外部设备一样。

有一件传统操作系统如今并未真正管理、而 Cloudflare OS 会管理的事情：AI Agent。如果仔细想想，这实际上是传统 OS 缺失的一项功能。我们认为，AI Agent 不能简单地被视为用户。它们必须对某一名人类用户负责，同时拥有自身受限的权限。Agent 通过编写代码片段并即时执行来完成工作。适合这一切的理想安全模型是基于能力的安全模型，而不是访问控制列表。明白我的意思了吗？也许传统 OS 也应该给予 AI Agent 特殊对待。

由 Workers 团队基于 Workers 构建

Cloudflare OS 构建于 Cloudflare Workers 之上，并大量使用了 Durable Objects、Dynamic Workers 和 Facets。每个工作区都是独立的 Durable Object；每个 Gadget 都运行在 Dynamic Worker Facet 中；Gatekeepers 也会向每个工作区安装 Facet，以管理对远程服务的访问。

事实上，Cloudflare OS 由构建 Workers 本身的团队开发。它使用了 Workers Runtime 的前沿功能——事实上，Dynamic Workers、Facets 以及其他若干功能都是专门为了支持 Cloudflare OS 而加入 Runtime 的，未来还会有更多功能。研究 Cloudflare OS 源代码，是理解 Workers Runtime 团队认为应如何使用 Workers 的绝佳方式。

构建于 Workers 之上，并不意味着 Cloudflare OS 只能运行在 Cloudflare 上。事实上，Cloudflare Workers Runtime workerd 本身就是开源的，Cloudflare OS 可以完全构建在它之上，运行于你自己的服务器。

通用多用途 Agent

Cloudflare OS 编程 Agent 实际上是一个功能完整的通用多用途 Agent，可以执行任意任务；与其他流行的编程 Agent 一样，你不必用它来编程。你可以使用它构建 Gadgets，也可以跳过 Gadget，直接让 Agent 执行任务。Cloudflare OS Agent 是一个 Code Mode Agent——它通过编写并立即执行代码片段来完成任务。它可以通过 Gatekeepers 接入外部资源（类似 MCP——见下文）。

如果愿意，你可以手动编写 Gadget 的代码，但预期的使用方式是让 AI 为你编写代码。Cloudflare OS 内置了编程 Agent，能够构建你要求的任何内容、为你测试，并调试错误。

你可以选择自己的 LLM。Cloudflare OS 支持许多主要 AI 模型提供商和自托管模型，并且还在持续添加更多提供商。

由于该平台高度集成且经过简化，即便使用相同的底层 AI 模型，Cloudflare OS 编程 Agent 往往也能以更少 Token，实现比通用编程 Agent 更快、更好的表现。

通过 Cloudflare OS 构建的每个应用，都会自动拥有一个对 Agent 友好的 API。这意味着，在你让 AI 构建应用后，还可以让 AI 在应用内部与你协作。无需构建 MCP 服务器，也无需集成自定义 Agent 循环。默认就具备这些能力。

这之所以可行，是因为 Gadget 的客户端和服务端部分必须通过 Cap'n Web RPC 通信。这是双赢：

1. Cap'n Web 几乎不需要样板代码，因此 Agent 很容易使用。你基本只需在服务器上定义一个方法，然后像调用本地方法一样从客户端调用它。
2. 同时，这意味着服务端必然会暴露一个易于理解的 API，Agent 可以直接调用。AI Agent Harness 使用 Code Mode 进行工具调用，因此可以轻松将 Gadget 的 API 直接暴露给 Agent 调用。

你可以像在典型在线办公套件中共享文档一样共享 Gadget。你可以向特定用户授予访问权限，也可以创建一个共享链接，让任何打开链接的人都能访问。并且和这些在线办公套件一样，你将能够实时看到协作者的操作。

这之所以可行，是因为每个 Gadget 都由一个 Durable Object 支持。Durable Object 是 Cloudflare 的有状态无服务器原语，可轻松实现实时多人协作。它足够简单，以至于编程 Agent 即使没有被特别要求，也会默认实现这一功能。

Blueprints：分享你的代码

如果你创建了一个可能对其他人有用的 Gadget，但又不想直接共享该 Gadget，可以改为共享一个 Blueprint，让其他人创建自己的 Gadget 副本。Blueprint 本质上是一份代码副本。

这听起来可能很简单，但 Blueprints 是对云软件传统的一项重大改变。传统上，如果你创建了一个想要与其他用户分享的 Web 应用，你会将应用托管在自己的服务器上，用户连接到该服务器。Blueprints 更像移动应用和传统 PC 应用：每位用户都运行自己的一份软件副本。

在 AI 时代，这一改变至关重要。一方面，AI 让个人开发者拥有前所未有的构建能力，但个人开发者仍然很难维护一项在线服务；这种模式消除了这一需求。另一方面——而且更重要的是——让每位用户运行自己的软件副本，使用户能够借助 AI 修改软件以满足自身需求。无需提交功能请求，无需乞求开发者

Cloudflare OS: An AI productivity environment

Cloudflare OS is an "operating system" for AI productivity originally developed for use inside Cloudflare. A large portion of Cloudflare's workforce -- from engineering to sales and everything in between -- uses Cloudflare OS every day to help them do their jobs.

This is not a traditional computer operating system. We use the term "operating system" in two senses:

• An operating system for the company to be productive with AI, in a way that is safe, so that the security team can sleep at night.
• An operating system for AI workloads, analogous to the sense in which a traditional operating system manages compute workloads.

Cloudflare OS provides three things in particular:

1. An agent chat UI where you can ask agents to do tasks, preloaded with knowledge about how your company operates.
2. Sandboxed application development, so that you can ask agents to build "gadgets" (small personal apps) and safely share what you've built with others.
3. A security framework, called Gatekeepers, that applies guardrails to both agents and apps such that non-technical users can safely "go nuts" and nothing bad will happen.

We are making Cloudflare OS open source so that others can copy it and customize it for their own company. The idea is not that your company uses Cloudflare OS, but rather that you make it "Your Company OS".

To quickly run Cloudflare OS locally, install pnpm, then do:

Then visit: http://localhost:8787

This runs the whole stack locally on wrangler and workerd. This is not meant for production use, but is a quick way to see what the product does.

Alternatively, you can deploy to your Cloudflare account.

(More options at the end of this readme.)

Try prompts like:

• "Make slides for my upcoming meeting with a customer." (This will use the built-in slides blueprint.)
• "Make a collaborative whiteboard app." (This will create a new app from scratch.)
• "Make a tic tac toe game." followed by "I'll be X and you be O. I've made my first move. Your turn."
• "Make an issue dashboard for this GitHub repo." (Attach a repo; requires that the GitHub integration is configured.)
• "Fix the typos in this Google Doc." (Attach a doc; requires that the Google integration is configured.)

Cloudflare OS is in a state of heavy development. This repository is actually version 2, a complete rewrite taking what we learned from version 1 and putting it on a new foundation.

As of the August 2026 release, Cloudflare OS v2 is very capable, but still has many rough edges. We know, and we're working on it. For now, consider this an "early access" release.

Overview: What is Cloudflare OS really?

Gadgets: A new way of thinking about software

Cloudflare OS is more than just another chatbox with connectors. The system revolves around a new approach to software, where every user runs their own copy of the productivity apps they use.

When you create a slide deck in Cloudflare OS, you are not calling out to some SaaS software running in the cloud. The system creates a private instance of the slide deck software just for you. We call this a "gadget". This instance runs in a separate sandbox from everyone else's slide decks.

This has two profound effects:

1. It's impossible for the slide deck app to have a security bug that leaks your slides to an attacker. The Cloudflare OS sandbox controls all access to your private instance of the app.
2. If you want, you can freely modify the code. If the slide deck app is missing a feature you need, you can just ask your agent to add it. And because of point 1, it's totally safe to do so.

This is a big departure from the last 25 years of cloud architecture and "Software as a Service", but we think AI has changed the equation. When any user is capable of prompting an agent to add the features they need, the centralized model of software stops making sense.

Gatekeepers: A capability-based security layer

Gatekeepers are like supercharged MCP servers.

When you introduce an agent or Gadget to an external resource, a Gatekeeper is created to manage that access. The Gatekeeper is a piece of software specific to each external service which moderates a Gadget's connection to that service. It:

• Provides a clean Cap'n Web API to the service (wrapping whatever API the service provides natively).
• Handles authorization (e.g. via OAuth).
• Enforces narrow access to only the specific resource the user intended.
• Logs every action the Gadget (or agent) performs, for your review.
• For any action which has side effects, provides the human user an opportunity to approve or deny the action ("human in the loop").

On the last point, Gatekeepers implement a significant advancement in the state of the art. Traditionally, human-in-the-loop setups require the human to approve actions synchronously. When the agent wants to do something, it has to stop and wait for said approval before it can continue. This is annoying: you give your agent a task, then walk away and get a coffee, only to come back and find the agent got stuck on an approval on the first step and has made no progress. As a result, people often give in and set their agents to "auto-approve", or --dangerously-skip-permissions, which is, obviously, unsafe.

Gatekeepers provide a better way: When the agent (or Gadget) performs an action that requires approval, the Gatekeeper will simulate the outcome locally, allowing the agent to proceed and queue up more actions. The Gatekeeper tells the agent that the action completed, and if the agent tries to read back the results, the Gatekeeper gives it simulated results. Once the agent is done, the user may approve or reject the actions in bulk, or one-by-one, but either way, they can do it later, when it is convenient.

Logistically, each Gatekeeper is implemented as a separate Worker. In the future, we envision Gatekeeper services being deployed and maintained independently from OS instances, but the details have yet to be worked out. For now, we have provided a few interesting Gatekeepers in this repository which you can deploy together with your own OS instance.

The basic user experience of Cloudflare OS is something like an online office suite, like Google Docs or MS Office. But, imagine that instead of a fixed set of file types (document, spreadsheet, slide deck), each file -- or "Gadget" -- is potentially its own custom application, written by AI to serve exactly your needs.

Just like office docs, each gadget is private by default, but can be shared -- securely -- in order to collaborate with your team or your friends.

Just like office docs, you can have thousands of them. You can create them on a whim.

Just like office docs, you can start from "templates" -- called "Blueprints". But where an office template is just some content, a Blueprint specifies a whole application.

Like office docs, you can create new templates (blueprints) from your own docs (Gadgets) and share them with others. But when you do so, you are sharing the code for a whole app.

It kind of is an Operating System

The OS terminology isn't entirely marketing. Cloudflare OS is actually analogous to an operating system on a technical level.

Normal OS	Cloudflare OS
kernel	packages/workshop-backend
device drivers	packages/gatekeeper-*
shell	packages/workshop-frontend
processes	gadgets
executables	blueprints
users	users
ACLs	shared permissions
???	agents

Our "kernel" is in the workshop-backend package. The backend legitimately does a lot of things similar to real OS kernels: it connects users to programs and devices (Gadgets and Gatekeepers, as we call them) while implementing security by sandboxing applications and enforcing access control.

In this analogy, Gatekeepers -- which connect users and agents to external services -- are like drivers -- which connect users and programs to external devices.

There is one thing that traditional OSes don't really manage today, but Cloudflare OS does: AI agents. If you think about it, this is really a missing feature in traditional OSes. We believe that AI agents cannot simply be treated as users. They must be accountable to a human user, while at the same time having their own restricted permissions. Agents do work by writing snippets of code and executing them on the fly. The ideal security model for all of this is capability-based security, not access control lists. See what I mean? Perhaps traditional OSes ought to give AI agents special treatment, too.

Built on Workers, by the Workers team

Cloudflare OS is built on Cloudflare Workers, making heavy use of Durable Objects, Dynamic Workers, and Facets in particular. Every workspace is its own Durable Object, every Gadget runs in a Dynamic Worker Facet, and Gatekeepers also install facets into each workspace to manage access to remote services.

Cloudflare OS is, in fact, built by the very people who built Workers itself. It uses cutting-edge features of the Workers Runtime -- in fact, Dynamic Workers, Facets, and several other features were added to the runtime specifically to support Cloudflare OS, with more to come. Studying the Cloudflare OS source code is a great way to understand how the Workers Runtime team thinks Workers should be used.

Being built on Workers does not mean that Cloudflare OS can only run on Cloudflare. In fact, workerd, the Cloudflare Workers Runtime, is itself open source, and Cloudflare OS can run entirely on top of it on your own servers.

General multi-purpose agent

The Cloudflare OS coding agent is actually a fully multi-purpose agent that can perform arbitrary tasks; like other popular coding agents, you don't have to code with it. You can use it to build Gadgets, but you can also skip the Gadget and just have the agent perform tasks directly. The Cloudflare OS agent is a Code Mode agent -- it performs tasks by writing and immediately executing snippets of code. It can be connected to external resources using Gatekeepers (like MCP -- see below).

While you can code a Gadget by hand if you want, the expectation is that AI writes the code for you. Cloudflare OS features a built-in coding agent that will build whatever you ask it, test it for you, and debug errors.

You can choose your LLM. Cloudflare OS works with many major AI model providers and self-hosted models, with more providers being added all the time.

Because of the tightly-integrated and simplified nature of the platform, even when using the same underlying AI models, the Cloudflare OS coding agent often performs better and faster with fewer tokens than a general-purpose coding agent would.

Every app built with Cloudflare OS automatically has an agent-friendly API. That means, after you've asked AI to build the app, you can also ask AI to collaborate with you inside the app. No need to build an MCP server nor integrate a custom agent loop. It's just there by default.

This works because the client and server portions of a Gadget are required to communicate via Cap'n Web RPC. This is a win-win:

1. Cap'n Web is extremely low-boilerplate, which makes it easy for agents to work with. You basically just define a method on your server, then call it from your client, as if it were a local call.
2. Meanwhile, it means that the server necessarily exposes an easy-to-understand API which could be called directly by an agent. The AI Agent harness uses Code Mode for tool calling, making it trivial to expose the Gadget's API directly for the agent to invoke.

You can share your Gadget just like you'd share a document in a typical online office suite. You can give specific users access, or create a share link that provides access to anyone who opens it. And just like those online office suites, you'll be able to see your collaborators' actions in real time.

This works because every Gadget is backed by a Durable Object, Cloudflare's stateful serverless primitive which makes real-time multiplayer collaboration easy. It's so easy that the coding agent just implements it by default, without being asked.

Blueprints: Share your code

If you've created a Gadget that might be useful to others, but you don't want to share the Gadget itself, you can instead share a Blueprint, allowing other people to create their own copy of the Gadget. A Blueprint is essentially a copy of the code.

It may sound simple, but Blueprints are a major change from cloud software tradition. Traditionally, if you create a web app that you want to share with other users, you host the app on your server, and the users connect to that. Blueprints are much more like mobile apps and traditional PC apps: every user runs their own copy of the software.

In the age of AI, this change is critically important. On one hand, AI empowers an individual developer to build more than ever, but it is still difficult for an individual developer to maintain an online service; this eliminates the need. On the other hand -- and even more importantly -- allowing each user to run their own copy of the software empowers the user to change the software to meet their needs, using AI. No need to file a feature request, no need to beg the developer to prioritize it. The end user can solve their own problems.

Sandboxed and secure by default

Each Gadget runs in a secure sandbox that prevents it from talking to the internet at all without your explicit consent. In particular:

• The server runs in a Dynamic Worker which has had its access to the internet disabled. It can only communicate with specific external resources that you have explicitly designated, via Workers Bindings.
• The client code runs in a sandboxed iframe. This iframe can communicate with its server only via a Cap'n Web RPC session provided over postMessage() to the parent frame. The iframe is otherwise blocked from accessing the internet (to the maximum extent allowed by browsers, via Content-Security-Policy and iframe sandbox settings).

Capability-based access control

Each agent, and each Gadget, by default has access to nothing. Even if you've configured the Gadget Workshop with access to external accounts, agents and Gadgets do NOT automatically get to use them.

Instead, you must introduce each agent (or Gadget) to any particular resources you want it to access. For instance, you may introduce a GitHub repository by pasting a link to it, or clicking "add resource" and selecting it via the UI. An agent can also request an introduction to a resource it thinks it needs, which you can then provide or deny.

This differs from most agent harnesses, where MCP servers are configured upfront, making broad access to all your services ambiently available to the agent in every chat. Capability-based introductions keep each agent restricted to only the access it actually needs for the job at hand.

Deploy to your Cloudflare account

We've built an online flow that helps you deploy to your own Cloudflare account:

https://os.cloudflare.app/deploy

Or, for more sophisticated deployment, with your gatekeepers and potentially code changes, check out our deployment starter repo:

https://github.com/cloudflare/cloudflare-os-starter

To quickly run Cloudflare OS locally, install pnpm, then do:

Then visit: http://localhost:8787

This runs Cloudflare OS using wrangler, the Workers developer tooling CLI. This is not the right way to run the OS on a production server, but it works fine for trying it out on your local machine.

Your data will be stored in a subdirectory named .wrangler.

Deploy to your own server using workerd

COMING SOON

Cloudflare OS can run entirely on workerd, Cloudflare's open source runtime for Workers. In fact, the "run locally" instructions above use workerd under the hood. We are still working on documentation and tooling to help you smoothly deploy the OS on top of workerd on your own servers. If you are feeling adventurous, read the low-level documentation for workerd config (or point your agent at it) and have a go.

Configuring external services

Many Gatekeepers require configuration in order to be able to connect to third-party services, including obtaining OAuth client credentials for each service. Unfortunately, many service providers intentionally do not make this easy, since the intended audience for OAuth is developers.

Each gatekeeper package contains instructions for how to set it up:

When developing, you'll want to run the front-end and back-end as two separate commands in two terminals:

pnpm dev-server
pnpm dev-client

Then visit: http://localhost:3000

At this time, we are not seeking outside contribution.

AI has made writing code easy. The hard part, today, is not writing the code, but reviewing it, making sure quality stays high, and keeping the product coherent. In that light, unfortunately, external code contributions are "donating" the easy part of the job, while creating more of the hard work.

With that said, we are happy to accept small, trivially-verified PRs that fix a problem. However, we ask that you refrain from submitting low-value PRs (e.g. typo fixes) or PRs that are more than a dozen or so lines. Such PRs will be closed with a reference to this guideline.

If you have a big idea you'd like us to consider, feel free to open a discussion about it.

This policy may change in the future as the project matures. Until then, thank you for your understanding.

Cloudflare OS has far too many open source dependencies to list here. But, we'd like to highlight a few that do particularly heavy lifting:

• Pi (specifically, pi-agent-core), which made it easy to support every LLM provider with one API.
• CodeMirror provides our code editor UI and operational transform implementation for synchronizing real-time edits.
• isomorphic-git is used to implement the backing storage for Gadget code and integration with external git servers.
• Vite, which makes the development loop so pleasant.