Oh My Pi 与 OpenCode：工作流、模型和总成本

两个客户端都是免费的 MIT 软件，因此选择并不取决于价格，而在于你是否希望模型账单来自与客户端相同的账户。OpenCode 直接销售模型：每月 $10 的订阅 OpenCode Go，以及按量付费的网关 OpenCode Zen。Oh My Pi 完全不销售任何内容，而是要求你自带密钥。如果你已经知道从哪里购买代币，并希望对代币进行深度路由控制，请选择 Oh My Pi；如果你希望获得更广泛的使用界面——终端、IDE、服务器和 SDK——并且可以不离开客户端直接购买模型，请选择 OpenCode。

在这些信息发挥作用之前，必须先解决三个名称冲突，因为其中两个会将你引向错误的文档。

哪个项目对应哪个名称

仓库、版本和软件包信息于 2026 年 9 月 19 日从 GitHub 和 npm API 读取。Oh My Pi 明确是一个分支：其 README 称“omp 是 Mario Zechner 的 Pi 分支，重写为以编码为先的界面”，仓库中仍保留着将更改从上游移植过来的检查清单。OpenCode 的迁移是公司重新命名，而不是所有者变更——sst 组织现在显示“我们已迁移到 https://github.com/anomalyco”，而anomalyco 组织的名称为 Anomaly。本页不对该更名的日期作出断言，因为公开证据无法相互印证。

应该选哪一个

工作流。Oh My Pi 是一个以终端为先的代理，并具有异常明确的路由层：其 README 描述了九个按意图路由工作的角色——普通轮次使用 default，廉价的子代理分发使用 smol，深度推理使用 slow，此外还有 plan、commit、vision、task、advisor 和 tiny——每个角色都可以指定不同的模型；当主模型遇到配额限制时，则使用 retry.fallbackChains 下的回退链。OpenCode 则沿水平方向扩展：内置两个可通过 Tab 切换的代理，并提供跨 IDE、Web 界面、服务器、SDK 和插件的文档化集成。如果你的痛点是“我想让廉价模型处理廉价部分”，那是 omp 的内置形态。如果你的痛点是“我希望从更多地方访问这个代理”，那是 OpenCode 的形态。

权限与执行。默认情况下，两者都不是谨慎型客户端。omp 的批准模式文档将 yolo列为默认模式：自动批准 read、write 和 exec，且不会提示任何内容；always-ask和write是更严格的设置。它确实会识别一小组关键的 bash 模式——rm -rf /、fork bomb、远程获取后执行等——但在依赖这一点之前，请仔细阅读 omp 的批准模式页面：同一文档称，在 yolo 中，单独的关键覆盖会被忽略，只有明确的工具或用户 prompt/deny 策略仍会强制停止。OpenCode 的权限页面称，大多数权限默认为 "allow"，doom_loop 和 external_directory 默认为 "ask"，而读取 .env 文件则被拒绝。两者的结构也不同，这一点在迁移策略时很重要：omp 为每个工具声明 read/write/exec 层级，并通过 tools.approval.<toolName>覆盖；OpenCode 则评估模式规则，最后一个匹配规则优先。

方案与协议限制。这里唯一类似方案的限制，方向与人们预期的不同。两个客户端都不会要求通过方案才能使用自带密钥。但 OpenCode Go 对使用它的客户端有要求：它称该方案面向 OpenCode 及其他能够生成类似请求的编码代理设计，并表示“流量会受到滥用监控”；你的客户端“应”发送典型的编码代理流量，“使用自身的 user agent 标识自己”，并在每次对话中“在 x-opencode-session 中发送稳定的会话 ID”。omp 为其 opencode-go provider 实现了这套完整的通信机制。OpenCode 的已验证客户端表中有一行仅名为“Pi”，无法区分上游项目和该分支，因此无法从该页面确定它是否涵盖 Oh My Pi——本指南不声称 Oh My Pi 是已验证的 OpenCode Go 客户端。

每个产品的费用

检查日期为 2026 年 9 月 19 日。Oh My Pi 不销售任何内容的证据是间接但有力的：其网站地图发布了 36 个 URL，即主页加 35 个文档页面，其中没有定价、账单、结账或注册路径；仓库采用 MIT 许可证。其唯一的托管服务是一个会话协作中继，默认使用 wss://my.omp.sh，并在每个会话载荷到达 socket 之前将其加密封装；没有附带价格，也没有注册方式。系统接受自定义中继 URL，但同一页面说明生产中继目前不提供自托管分发。

$10 的方案是上限，而不是可用额度

OpenCode Go 值得准确理解，因为第三方对它的总结一贯错误。官方页面称“使用量限制按每月美元金额定义”，而不是按请求数量定义。每个模型都有自己的月度美元上限——根据模型不同为 $15、$30 或 $60——较短时间窗口则是同一模型上限的百分比：5 小时窗口为其 20%，每周窗口为其 50%。因此，广泛传播的“每 5 小时 $12”这一数字，只有在模型的月度上限为 $60 时才成立。另有两条规则会改变计算方式：“每个工作区只能有一名成员订阅 OpenCode Go”，而达到上限并不会硬性停止——页面称你仍可继续使用免费模型，或启用余额回退，让请求改用 Zen 余额，而不是被阻止。请直接阅读页面上的模型名单表格，而不是任何摘要。页面称该名单可能变化，而它变化得比指南能够跟踪的速度更快：在一次时间受限的促销倍数显示在某个模型上时，相隔一天的两次检查中，该模型的上限读数就不同，因此应将任何地方引用的上限——包括此处的上限——视为一种结构，而不是当前数字。

Zen 是同一账户中按量计费的一侧。其文档称，每次请求的费用会从账户余额中扣除；当余额低于 $5 时会自动充值 $20，除非你更改或禁用该设置；银行卡费用按成本转嫁，报价为每笔交易 4.4% 加 $0.30。其明确立场是：“以成本价销售，将任何降价传递给用户；因此唯一的加价只是用于支付我们的处理费用。”其中有两点明确是临时性的，之后可能失效：标价为 $0 的模型均被描述为“限时”免费，其中大多数还注明团队利用这段时间收集反馈并改进模型；团队工作区仅作为 beta 的一部分免费。免费模型的数量会变化——请在页面上自行计数，而不要相信此处的任何数字。这两项说明于 2026 年 9 月 19 日仍显示在页面上，在据此制定预算之前应重新阅读。关于 Go 和 Zen 的完整费率表，OpenCode 定价已经进行了跟踪。

同口径的代币估算

这是基于词元数量的计算，而不是实测任务成本，也不是账单上限。假设一次会话包含200,000 个未缓存输入词元和 15,000 个输出词元，并且只比较两个价格表中都出现的两个模型名称。Kunavo 费率来自实时目录；Zen 费率读取自其自身文档，日期为 2026 年 9 月 19 日。

请严格按此范围理解。在这些假设下，两个价格表对 Claude Sonnet 5 得出相同估算，对 Claude Opus 5 得出不同估算；这说明的是某一天公布的两组费率，而不是笼统声称哪个网关更便宜。Zen 公布了 Kunavo 不销售的模型费率，而 Kunavo 的目录也包含 Zen 未列出的模型，因此两张费率表的大部分内容都没有可比较的对应项。列出的最低费率和完成任务的最低成本也是两个不同的问题——需要尝试三次的便宜模型，成本可能高于一次完成任务的昂贵模型。

这两个 10 美元的数字也不可比较，尽管看起来像是可比的。OpenCode Go 的 10 美元是按月循环订阅，价值取决于你是否实际使用到每个模型的上限。Kunavo 的 $10 最低金额是预付额度充值——是资金门槛，不是月费，也不是任务价格。Kunavo 目录中的金额是计费下限，而不是上限：当上游报告其费用时，账单金额取目录成本与上游成本乘以适用加价率两者中的较高者。缓存费用和外部工具不在本例范围内；请参阅 计费详情。

让任一客户端使用你自己的密钥

这是两个客户端差异最大的地方，也是迁移真正需要花费时间的地方。两者都接受自定义的 OpenAI 兼容端点，且不受任何套餐限制。差异在于配置文件、各自支持的通信格式，以及一个自动检测陷阱。

上面的两个表格均取自项目自己的文档，读取日期为 2026 年 9 月 19 日——omp 的 docs/models.md 和 OpenCode 的提供商页面。

Oh My Pi 及其发现陷阱

# Derived from omp's documented schema in docs/models.md.
# Not runtime-tested by Kunavo against a running omp.
providers:
  # OpenAI wire. baseUrl ENDS IN /v1 here.
  kunavo:
    baseUrl: https://api.kunavo.com/v1
    apiKey: KUNAVO_API_KEY      # an env var name, or a literal key
    api: openai-completions     # required whenever discovery is set
    authHeader: true            # sends Authorization: Bearer <key>
    discovery:
      type: openai-models-list  # reads /v1/models, picks up context_length

  # Anthropic wire. Written without /v1, matching omp's own proxy examples;
  # omp's docs say its Anthropic SDK strips a trailing /v1 either way.
  kunavo-anthropic:
    baseUrl: https://api.kunavo.com
    apiKey: KUNAVO_API_KEY
    api: anthropic-messages
    authHeader: true
    # disableStrictTools: true  # only if strict tool schemas are rejected
    models:
      - id: claude-sonnet-5
        name: Claude Sonnet 5

有一个细节值得单独用一整节说明。omp 文档记录了一种 discovery.type: proxy 模式，专为在同一主机后同时暴露 /v1/messages 和 /v1/chat/completions 的网关设计——这正是 Kunavo 的结构。但它会从 GET /v1/models 中的 supported_endpoint_types 字段推导每个模型的通信格式；对于没有该字段的模型，则“如果已设置，则回退到提供商级别的 api，否则丢弃”。Kunavo 的 /v1/models 不会输出该字段，因此单独使用 discovery.type: proxy 会丢弃整个目录。上面的代码片段避开了这一点：discovery.type: openai-models-list 会先读取 max_model_len，然后读取 context_length，而 Kunavo 确实发布了 context_length。omp 自身的验证规则规定，只要设置了发现，就必须设置提供商级别的 api:，但 proxy 模式除外。

omp 的另一个行为在使用网关时也很有用：其记录的密钥解析顺序会将 models.yml 中的 apiKey 置于已存储的 OAuth 之上，并明确表示这是有意为之，“这样，为自定义 baseUrl 或网关提供的密钥就会被采用，而不会转发代理会拒绝的上游 OAuth 令牌”。这会在网关身份验证失败发生之前，消除其中最常见的一类问题。

OpenCode 及 Anthropic 的特殊情况

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "kunavo": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "Kunavo",
      "options": {
        "baseURL": "https://api.kunavo.com/v1",
        "apiKey": "{env:KUNAVO_API_KEY}"
      },
      "models": {
        "claude-sonnet-5": {
          "name": "Claude Sonnet 5",
          "limit": { "context": 1000000, "output": 128000 }
        }
      }
    }
  },
  "model": "kunavo/claude-sonnet-5"
}

上面的聊天补全路径直接遵循 OpenCode 记录的自定义提供商结构。Anthropic 兼容路径则没有对应结构：OpenCode 记录的是通过覆盖 内置 提供商来访问 Anthropic 端点——“你可以通过设置 baseURL 选项来自定义任何提供商的基础 URL”——这意味着你会继承该提供商的模型 ID，并在同一配置中放弃从供应商自有主机提供的模型。根据 OpenCode 的 已发布 JSON schema，声明 "npm": "@ai-sdk/anthropic" 的自定义提供商是允许的，其中 npm 是不受约束的字符串；但提供商文档中完全没有提到它——请将该路径视为未经验证。

注意基础 URL 的拼写，但应分别检查每个客户端自身的规则，不要把一种约定套用到两者上。OpenAI 兼容接口在两种情况下都需要 https://api.kunavo.com/v1。对于 Anthropic 通信格式，两者记录的处理方式不同：omp 文档称其 Anthropic SDK 会“在追加 /v1/messages 之前，从 baseUrl 中去除末尾的 /v1”，而 omp 自己的 Anthropic 代理示例使用不带 /v1 的基础 URL；OpenCode 则记录通过覆盖内置提供商的 baseURL 来使用 Anthropic 路径，其覆盖示例以 /v1 结尾。仅包含源站的形式——https://api.kunavo.com，由客户端追加 /v1/messages——是 ANTHROPIC_BASE_URL 本身的规则；此时末尾的 /v1 确实会生成 /v1/v1/messages；请参阅 基础 URL 参考。Kunavo 同时接受 Authorization: Bearer 和 x-api-key，因此 omp 的 authHeader: true 以及 AI SDK 自身的默认值都有有效路径。

迁移实际需要付出什么代价

在这两个客户端之间切换是重写配置，而不是复制配置。omp 的上下文文件发现注册表确实包含一个 opencode 来源，但其文档将该来源限定为单个用户级文件 ~/.config/opencode/AGENTS.md，没有项目级对应项——因此，只有当项目指令已经存放在两个客户端都会发现的文件中（例如仓库根目录下的 AGENTS.md）时，它们才会迁移。omp 的文档没有读取 opencode.json 提供商块，因此基础 URL、密钥、模型条目和上下文限制都必须从头重新声明。

有一个差异值得认真决策，而不是耸耸肩带过。OpenCode 的提供商页面提醒说，旧版本曾捆绑用于 Claude Pro 或 Max 订阅的插件，并且“自 1.3.0 起已不再如此”，理由是供应商禁止这种做法；同一页面仍列出 ChatGPT Plus、GitHub Copilot 和 GitLab Duo，称这些订阅无需设置即可使用。相比之下，omp 仍为多个编码计划提供商提供带多账户轮换功能的 OAuth 登录。如果你打算通过订阅而不是按令牌密钥付费，这一差异就会替你决定客户端——而这属于政策问题，因此应查看订阅本身当前的条款，而不是依赖任一客户端的文档。还需注意，OpenCode 自己的 Anthropic 部分在已发布内容中存在不一致：描述 Pro/Max 登录选项的正文位于删除该选项的提醒上方；本指南引用该提醒，因为它是有日期且具体的陈述。

最后，如果你只是要更换购买令牌的地方，而不是更换客户端，请先做这件事——这是成本更低的实验。可通过 适用于 OpenCode 的最佳 API 比较提供商；如果网关概念本身是新增内容，也可以阅读 LLM 网关的工作方式。如果你正在全面权衡其他客户端，OpenCode 替代方案 会介绍更广泛的选择。

先在一项范围明确的任务上试用

Kunavo 已发布 OpenCode 设置指南，但尚未发布 Oh My Pi 指南；而已发布的配置参考并不等于兼容性测试：这里尚未在运行时针对 Kunavo 端点测试过任何一个客户端，上面的 omp 代码片段是 Kunavo 发布的第一个片段，依据 omp 的文档化 schema 编写。尝试任一客户端时，请保留一条可用路径，运行一项范围明确的任务，然后查看账户实际记录的费用。从 OpenCode 集成指南 开始，准备为密钥充值时再创建 Kunavo 账户。

常见问题

仓库、版本发布和软件包事实已于 2026 年 9 月 19 日通过 GitHub 和 npm API 核查；OpenCode 的 Go、Zen、权限、提供商和企业页面，以及 Oh My Pi 的 docs/ 目录和站点地图也于同日查阅。Oh My Pi 允许的 api 值已于 2026 年 10 月 1 日根据其 v18.4.8 版本的 docs/models.md 和 models.yml schema 重新核查。两个客户端均未针对 Kunavo 进行运行时测试。Kunavo 的令牌费率来自实时目录，本页面中的所有美元数字均为说明性的令牌算术，而不是经过测量的任务成本。