Oh My Pi 与 Pi 对比：分叉、差异以及该运行哪个

Oh My Pi 是 Pi 的硬分支，而不是在旁边成长起来的竞争者——代码流向是 Pi → Oh My Pi，两个项目如今都仍在活跃开发，并且现在针对的是相反的目标。 Pi 是一个刻意保持简洁、可用 TypeScript 扩展的终端工具框架。Oh My Pi 则沿着同一血统重建为开箱即用的编码界面，内置 LSP、调试器、子代理和浏览器工具。两者都采用 MIT 许可，安装成本均为 $0，因此决定因素是工作流、执行模型和配置格式，而不是许可费用。

先说名称，因为其中有三个会产生混淆。这里的 Pi 指的是 pi.dev 上的代理工具框架，由 Earendil Works 从 earendil-works/pi 发布。它不是 Inflection AI 的 Pi（pi.ai）、Pi Network 的代币，也不是 Raspberry Pi。Oh My Pi 指的是来自 can1357/oh-my-pi、位于 omp.sh 的代理，其可执行文件是 omp——不是搜索该短语时占主导地位的馅饼烘焙店，也不是 Oh My Zsh 或 Oh My Posh，尽管名称听起来相似。而 pi-mono 不是第三个产品：它是 Pi 以前的仓库名称。github.com/badlogic/pi-mono 现在会返回 301 到 earendil-works/pi，但第三方文档仍使用旧路径——DeepSeek 的官方 Pi 集成页面确实位于 /agent_integrations/pi_mono/。

值得明确分支方向，因为搜索会在两个方向上进行，而答案并不对称。Oh My Pi 的 README 在自己的标题中写明它是“由 @mariozechner 开发的 Pi 的分支”，并链接到更名之前的 URL。GitHub 对它报告 fork: false 和 parent: null，因为这是源代码分支，而不是通过 fork 按钮创建的分支——因此 API 不会告诉你。该仓库仍保留 docs/porting-from-pi-mono.md，这是一份合并检查清单，其中记录的 Last Sync Point 是提交 b21b42d，日期为 2026 年 3 月 22 日。这个标记是外部可获得的唯一分歧证据；是否发生过更晚但未记录的同步，不是本页面能够确认的。

Oh My Pi 与 Pi：应该选哪个？

无论你从哪个方向开始，五个维度决定结果，其中只有一个与功能有关。

• 工作流。 如果你想要一个小型核心，并打算自己编写缺失部分，请选择 Pi。在 2026 年 9 月 22 日文档刷新之前，其自己的使用文档称它“有意不包含内置 MCP、子代理、权限弹窗、计划模式、待办事项或后台 bash”，并建议使用扩展、软件包、容器和 tmux。刷新删除了这句话，随后 v0.99.0 将 MCP 变为默认加载的内置扩展；子代理、计划模式、待办事项和审批提示在 v0.99.2 中仍是扩展。如果你希望这些内容第一天就开箱即用，并且不想维护扩展，请选择 Oh My Pi。
• 权限与执行模型。 两者的默认设置都不是安全选项，因此应根据你能够接受哪种故障模式来选择。Pi 没有权限系统，并明确说明了这一点。Oh My Pi 有真正的三级权限系统，默认设置为 yolo。如果你需要按工具显示提示，Oh My Pi 只需添加一行配置即可提供；Pi 完全无法提供，除非使用扩展。
• 协议与套餐限制。 如果你的模型路由是第三方 OpenAI 或 Anthropic 兼容端点，两者都可以访问，但 Oh My Pi 记录了九种通信协议变体，而 Pi 在 2026 年 9 月 22 日文档刷新之前记录了四种，并且 Oh My Pi 还增加了 Pi 没有的环境变量路由。代码中的协议变体差距比纸面上的更小：v0.99.2 的 Pi 源代码会将自定义提供商的 api 分派给十种内置实现中的任意一种，其中六种从未被文档记录为可用于此目的。如果你的路由是 OAuth 订阅——Claude Pro/Max、Codex、GitHub Copilot——两个客户端都通过 /login 接入该订阅并存储供应商令牌，而中间的网关会拒绝这种令牌；Oh My Pi 自己的提供商文档正是以此解释为什么 models.yml 密钥会有意优先于已存储的 OAuth。不要把中国的编程套餐归入这一组：Pi 在其 API 密钥表中列出 ZAI/GLM、Kimi For Coding 和 Qwen Token Plans（ZAI_API_KEY、KIMI_API_KEY、QWEN_TOKEN_PLAN_API_KEY），Oh My Pi 将它们标记为 plan 而不是 oauth，因此它们在两者中都是普通的密钥型提供商。
• 成本路径。 两边的客户端都免费，且都不会改变你的每令牌费率。不同之处在于，Pi 有一个集成到自身 /login 中的第一方付费网关（由同一家公司运营），而 Oh My Pi 不销售任何托管路由——它实际运营的唯一服务器是 /collab 会话链接背后的中继，并且不收取任何费用。
• 迁移成本。 大致就是重新输入一个提供商配置块。配置格式和目录不同——JSON 位于 ~/.pi 下，YAML 位于 ~/.omp 下——而且两个仓库都没有记录导入工具。少数环境变量名称相同，但有下文所述的注意事项。

真正不应用来决定的是版本号。Oh My Pi 在分支时重新编号，因此它的 18.2.7 与 Pi 的 0.86.1 是不同的编号体系，并不代表多出了十八个版本的成熟度。

两者实际有哪些不同

2026 年 9 月 19 日从两个仓库自己的文档中读取：Pi 的 概览、安全和 模型页面，以及 Oh My Pi 的 README、审批模式和 提供商页面。Pi 的设计说明、MCP、权限模型和方言行于 2026 年 10 月 1 日根据其更新后的文档、README 和 v0.99.2 源代码重新核对。Oh My Pi 行中的功能数量是该项目自己的声明；项目没有公布相关方法，其 README 中的基准测试表同样是供应商声明，本页面不予复现。

两者都仍在活跃。任何单一指标都无法确定“哪个更大”

关于这对项目最常见的错误，是把其中一个当作已废弃或已被取代。检查当天两者都推送了代码。

仓库、发布版本和星标数据来自 GitHub API，读取时间为 2026 年 9 月 21 日；下载量来自截至 2026 年 9 月 16 日当周的 npm downloads API。不要将任一列转化为采用情况结论。 尤其是 npm 比较并非同类比较：Pi 自己的文档以 npm install -g 开头，而 Oh My Pi 的 README 记录了 curl-to-shell、Homebrew、Bun、Nix、PowerShell 和 mise，却完全没有给出 npm 命令，因此 npm 会在无法从此处测量的程度上实质性低估它。星标数量有利于 Pi；发布节奏有利于 Oh My Pi；任何只依据单一指标评价受欢迎程度的句子，至少会在一个方向上出错。

如果你希望获得不依赖指标、表明两者都仍未过时的中立第三方证据：Ollama 为 Oh My Pi 和 Pi 都发布了集成页面，DeepSeek 也分别为两者发布了代理集成指南——其中 Pi 的指南仍归档在旧的 pi_mono 路径下。四个页面都在 2026 年 9 月 21 日正常响应。

将任一工具指向你自己的端点

分支差异在这里最明显，而错误的 /v1 会让你浪费一个下午。两个客户端都可以访问第三方 OpenAI 或 Anthropic 兼容端点，但使用的机制不同，URL 约定也相反。

Oh My Pi 有一条 Pi 没有的环境变量路径。 它的 Anthropic 提供商通过 normalizeAnthropicBaseUrl($env.ANTHROPIC_BASE_URL) 解析基础 URL，优先于官方默认值；该规范化器会去掉末尾的 /v1，因此 https://api.kunavo.com 和 https://api.kunavo.com/v1 都会指向同一个主机。2026 年 9 月 19 日从 packages/ai/src/providers/anthropic-state.ts 读取，其中定义了 resolveDirectAnthropicBaseUrl() 和规范化器；信息来自源代码，而不是来自我们发出的请求。

# Oh My Pi honours ANTHROPIC_BASE_URL for its built-in anthropic provider.
# normalizeAnthropicBaseUrl() strips a trailing /v1, so both forms resolve
# to the same host here. Pi ships no equivalent gateway base-URL variable.
export ANTHROPIC_API_KEY="$KUNAVO_API_KEY"
export ANTHROPIC_BASE_URL="https://api.kunavo.com"
omp

这条路径还存在一个优先级陷阱。Oh My Pi 的记录顺序将 models.yml apiKey 放在第 2 位，将其置于第 3 位的已存储 OAuth 之上，但提供商环境变量位于第 5 位，在它之下。因此，如果你已经通过 /login 登录 Anthropic，订阅令牌会优先于 ANTHROPIC_API_KEY，你的网关密钥永远不会被使用。请在配置中固定该密钥，或先退出该提供商。

对于命名提供商，Oh My Pi 使用 YAML——而这里 /v1 会重新加上，因为其 OpenAI 路径会将 /chat/completions 原样附加到去除尾部内容的基础 URL 上。

providers:
  kunavo:
    baseUrl: https://api.kunavo.com/v1   # /v1 REQUIRED: omp appends /chat/completions
    api: openai-completions              # use anthropic-messages, and then drop /v1
    apiKey: KUNAVO_API_KEY               # env var name, a literal, or "!cmd"
    authHeader: true                     # send Authorization: Bearer <key>
    models:
      - id: claude-sonnet-5
        contextWindow: 200000
        maxTokens: 64000

要让 Pi 指向网关，你只有一条路径：~/.pi/agent/models.json。 Pi 不读取 ANTHROPIC_BASE_URL——2026 年 9 月 19 日对整个仓库进行代码搜索后，该精确字符串只出现两次，且都不是覆盖设置（一次是 Cloudflare AI Gateway 常量，另一次是模型生成脚本）——并且也不存在裸的 OPENAI_BASE_URL。确实存在一个基础 URL 变量，但它不是通用逃生舱：AZURE_OPENAI_BASE_URL 在 Pi 的提供商文档中列出，用于将 Azure OpenAI 提供商指向你自己的 Azure 资源，仅此而已。

{
  "providers": {
    "kunavo": {
      "baseUrl": "https://api.kunavo.com",
      "api": "anthropic-messages",
      "apiKey": "$KUNAVO_API_KEY",
      "models": [
        {
          "id": "claude-sonnet-5",
          "contextWindow": 200000,
          "maxTokens": 64000
        }
      ]
    }
  }
}

关于后缀，Pi 自己的文档从未明确统一过，你应当了解这一点，而不是盲信某个示例。在 2026 年 9 月 22 日文档刷新之前，其模型页面在一处将 anthropic-messages 代理显示为 https://proxy.example.com/v1，在另一处则显示为不带后缀的 https://proxy.example.com；刷新后删除了这两处内容，但仍未明确统一规范。应遵循无后缀形式，其理由来自源代码，而非运行时测试：Pi 在 anthropic-messages 路径上没有类似 Oh My Pi 的、会去掉 /v1 的规范化器——其文档描述的唯一规范化是 Azure 专属的：Azure 自有域名下的资源根 URL“会被规范化为 OpenAI API 路径”——其内置 Anthropic 默认值是没有 /v1 的 https://api.anthropic.com，而 OpenAI 默认值是 https://api.openai.com/v1；对于 anthropic-messages，它会将 model.baseUrl 直接交给官方 Anthropic SDK，由 SDK 自行追加 /v1/messages。在那里添加 /v1 会产生 /v1/v1/messages。Kunavo 在其基础 URL 页面上记录了相同约定：Anthropic 风格客户端只使用源站，OpenAI 风格客户端使用 /v1。

还有两个值得提前规划的边界。在 2026 年 9 月 22 日刷新文档前，Pi 的文档表格列出了 自定义 提供商的四种方言，尽管仓库中还提供了额外处理器；刷新后该表格被删除，且未指定替代列表，因此这四种仍是 Pi 为自定义提供商记录的唯一接口。不过，额外处理器并非仅保留给内置提供商：Pi v0.99.2 的源代码将 models.json 中的 api 字段定义为自由字符串，并将其分派给十个已注册实现中匹配的那个（BUILTIN_APIS 位于 packages/ai/src/compat.ts 中），因此自定义提供商可以指定 bedrock-converse-stream 或 google-vertex——但这两者是否能用于第三方端点，尚无文档说明，也未在此测试。至于 Oh My Pi，disabledProviders 会在检查凭据之前进行检查——被该列表拦截的提供商 ID 会静默消失，无论你提供什么密钥——而设置数组会被更高优先级的层整体替换，而不是合并，因此项目级列表会悄然丢弃全局列表。两个项目还提供了你在网关上可能确实需要的兼容性变通选项：Oh My Pi 的 disableStrictTools、Pi 的 supportsEagerToolInputStreaming 和 allowEmptySignature。Kunavo 是否接受任一客户端的默认严格模式、缓存标记或提前流式传输的工具输入，在此尚未测试。

切换的实际成本

这比版本号差距所暗示的成本低，但又不只是复制文件。两个仓库的文档树中都没有记录导入命令、会话转换器或配置迁移器，因此请计划以另一种格式重新录入提供商配置块——从 JSON 到 YAML，或反之。凭据也不会迁移：Pi 将其存储在 ~/.pi/agent/auth.json，而 Oh My Pi 将 SQLite 身份验证存储保存在 ~/.omp/agent/agent.db。

环境变量的通用程度并没有两者共同的起源所暗示的那么高，因此请仔细阅读这一部分。Oh My Pi 确实仍会读取以 PI_ 为前缀的变量名，其中包括 PI_CONFIG_DIR 和 PI_CODING_AGENT_DIR，但这些变量改变的是 Oh My Pi 的目录位置，因此，在与 Pi 共用的 shell 配置文件中导出其中一个变量，会让两个客户端指向同一路径，而不是让配置可以跨客户端使用。其环境变量参考文档中描述的从 OMP_ 到 PI_ 的映射规则，适用范围还要更窄：该文档指出，这条规则适用于每个被解析的 .env 文件内部，并明确表示“不适用于从父进程继承的任意变量”。完全无法直接通用的，则是任何针对运行框架构建的内容：Pi TypeScript 扩展是基于 Pi 的 API 编写的，而自 2026 年 3 月 22 日这一同步标记以来，两者各自独立维护和开发了大约六个月，API 正是在这段时间里逐渐产生差异。请测试扩展，而不要假定它可以直接移植。

两边的费用相同

两个客户端都不会向你收费，因此在它们之间切换不会改变模型支出。变量在于你通过哪条路径购买令牌，而两者在这一点上有一个差异：Pi 有官方付费网关，而 Oh My Pi 没有。Radius 由 Earendil 运营，采用闭源代码，通过 Pi 自己的 /login 访问；其 FAQ 说明，它会在标价之外收取“我们与支付处理商之间的费用”——具体百分比未公开，因此无法从外部计算 Radius 的总费用。Oh My Pi 唯一的网关是 omp auth-gateway serve，由你自行托管，传输安全则由运营方负责。

在将其纳入预算前，有一件事必须先排除：登录任一框架的 Claude Pro 或 Max 订阅并不意味着免费使用。在 2026 年 9 月 22 日刷新文档并删除该句子之前，Pi 的提供商文档写道，第三方框架的使用“会消耗额外用量并按令牌计费，而不是计入 Claude 计划限额”；Anthropic 模型使用订阅身份验证时，Pi 打印的警告仍写道，它“会消耗额外用量并按令牌计费，而不是计入你的 Claude 计划限额”（来源，v0.99.2）。在 Oh My Pi 的文档中没有找到等效声明，因此不要假定它的行为不同——请检查你自己的账户。

对于网关路径，下面计算的是工作负载的费用，而不是客户端的费用。假设一个月持续进行代理工作：5 百万个未缓存输入令牌和 400 千个输出令牌，无缓存读取或写入，不计图像或工具费用。费率采用实时的Kunavo 目录价格，按每百万令牌计费。

这些是基于上述假设的说明性令牌估算，不是实际测得的任务成本，也不是账单上限。两种客户端的这一列相同，因为客户端不是定价变量——但工作负载可能不同：Oh My Pi 的 task 工具会并行扩展子代理，而并行代理各自携带自己的上下文，这是任何表格都无法替你估算的输入令牌倍数。在扩大估算前，请先对一次有明确边界的变更进行测量。

两个 Kunavo 方面的注意事项应计入同一个数字。目录金额是计费下限而非上限：当上游报告其费用时，账单取目录成本与上游成本乘以适用加价两者中的较高者，正如计费指南所说明。最低充值金额是$10 的预付余额——这是为账户提供资金所需的现金，不是任务费用或订阅费用。

Kunavo 为每个客户端都发布了设置指南——Pi 和 Oh My Pi——但尚未对任一客户端连接其端点进行运行时测试；设置指南是配置参考，而不是兼容性测试。上述两种配置均依据已发布的文档和源代码编写，应在你自己的机器上验证。尝试其中一个时，请保留一条可用的路由。当你想为真实任务而不是模型定价时，请创建 Kunavo 账户、充值，然后针对你选定的模型执行一次有明确边界的变更。如果你仍在选择框架而不是提供商，Pi 编程代理定价会拆解 Pi 的四种计费路径，而 Pi 与 OpenCode 对比则将 Pi 与另一个发布了 Kunavo 设置指南的客户端进行比较。

常见问题

两个仓库的文档树和 npm 包于 2026 年 9 月 19 日进行了检查；基础 URL 和凭据顺序的声明于同日从文中指定的源文件中读取；仓库指标和发布历史于 2026 年 9 月 21 日重新读取。Pi 于 2026 年 9 月 22 日刷新文档后，其 anthropic-messages 基础 URL 示例、Azure 规范化说明、文档列出的 api 值和凭据顺序于 2026 年 10 月 1 日根据刷新后的文档及 v0.99.2 源代码重新核对。同日，在 Pi v0.99.0 发布内置 MCP 后，根据其使用、MCP、设置和安全页面、README、源代码分派的 api 值以及本网站自身的集成索引，重新核对了其未包含的功能列表、项目信任措辞和所述设计；额外用量说明则根据该源代码中的终端警告重新核对。同样在 2026 年 10 月 1 日，Oh My Pi 文档列出的 api 值根据其 v18.4.8 的 docs/models.md 和 models.yml 模式重新核对。Kunavo 费率从实时目录渲染，本页所有美元金额均为示例性的令牌费用计算。两个客户端均未针对 Kunavo 进行运行时测试，也不暗示两个项目之间存在性能或基准比较——不存在本页面可以引用的此类比较。