Nanocoder 与 OpenCode：工作流、模型和总成本

OpenCode 是默认选择，而 Nanocoder 是经过刻意选择的少数派方案：截至 2026 年 9 月 19 日，OpenCode 拥有 208,444 个 GitHub 星标，而 Nanocoder 为 2,487 个；在截至 9 月 16 日的 30 天内，其 npm 软件包下载量为 9,436,914 次，而 Nanocoder 为 6,614 次。 两者都是免费的、采用 MIT 许可的终端编码智能体，都允许你指向自定义 API 端点。在两者之间选择并不是质量排名，而是在功能范围最广、有两个第一方产品争夺你的 token 支出的方案，与功能范围较窄、由不出售任何东西的集体运营的方案之间做选择。

将这些下载量视为数量级，而不是用户数。OpenCode 还可通过 curl 脚本和 Homebrew 安装，CI runner 会放大任何 npm 数字；此外，Nanocoder 也通过 Homebrew 和 Nix 发布，不仅限于 npm。这个比例在方向上可靠，但绝对数量并不可靠。

首先，确保你比较的是正确的两个项目

搜索结果中直接出现了三个与名称相关的冲突，其中两个不仅会让你困惑，还会导致配置失败。

在你按照较旧教程操作前，还需要了解一个变化。许多指南仍称为 sst/opencode 的仓库现在会 301 重定向到 anomalyco/opencode，而 sst GitHub 组织已为空，描述中写着其已迁移到 anomalyco（GitHub API，2026 年 9 月 19 日）。OpenCode 自己的文档也在安装命令中证实了这一点——brew install anomalyco/tap/opencode、ghcr.io/anomalyco/opencode——并且每个文档页面的页脚都标注版权归 Anomaly。产品名称没有改变，改变的只是组织。社交媒体上流传着一个重命名日期；这里无法验证，因此本页面不发布该日期。

应该选择哪一款

从你的默认模型开始，而不是从功能列表开始。如果你的日常工作已经使用托管的前沿模型，本地推理只是偶尔尝试，那么 OpenCode 的定位与你相符。如果你的日常工作依赖 Ollama、llama.cpp、LM Studio、vLLM 或 MLX，而托管 API 只是例外，那么 Nanocoder 的定位更符合你——不过这只是默认设置的差异，而不是能力差异，因为 OpenCode 也记录了 Ollama、LM Studio 和 llama.cpp 的 base URL。

在提供商层，迁移成本是对称且很小的；在其上层则是不对称的。自定义端点在任一客户端中都只是一个 JSON 块，因此跨网关迁移只需几分钟。无法迁移的是你在其上构建的内容：Nanocoder 位于 .nanocoder/skills/ 下的 Skills 包及其生命周期钩子——其中 pre-tool-use 钩子以非零状态退出时会拒绝调用并告知模型原因——没有可粘贴到 OpenCode 的对应位置；而 OpenCode 的逐代理权限块、插件和 LSP 配置也没有 Nanocoder 的对应位置。在统计配置行数之前，先计算这些工作量。

两个客户端实际有何不同

本表的来源，除非另有说明，均于 2026 年 9 月 19 日查阅：GitHub API、npm 注册表、Nanocoder 的配置和功能文档，以及 OpenCode 的配置、权限和CLI页面。

将任一项目指向你自己的 API 端点

两者都记录了自定义端点，因此网关在任一项目中都是受支持的配置。区别在于你可以访问多少种线路格式。

OpenCode 会在提供商块中命名一个 npm 包，而该选择会决定协议：@ai-sdk/openai-compatible使用 /v1/chat/completions，@ai-sdk/openai使用 /v1/responses。Kunavo 同时提供两者，因此这是真正的选择，而不是形式上的选项。

{
  "$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-4-6": {
          "name": "Claude Sonnet 4.6",
          "limit": { "context": 200000, "output": 64000 }
        }
      }
    }
  }
}

提供商页面明确说明了两个对任何尚未识别的端点都很重要的细节。首先，使用 /connect 注册密钥，滚动到 Other，并使用你在文件中使用的同一个 provider id；凭据会写入 ~/.local/share/opencode/auth.json。其次，这里值得设置 limit 块——文档说明标准提供商会自动从 models.dev 获取上下文和输出限制，而 Kunavo 不在其中。上方块中的值是文档自己的示例数字，不是该模型公布的限制；在依赖上下文计量器之前，应根据模型自己的页面设置这些值。

Nanocoder 的对应配置位于 nanocoder.providers 下。注意小写的 baseUrl，它不同于 OpenCode 的 baseURL；字符串字段会递归应用 ${VAR} 替换。

{
  "nanocoder": {
    "providers": [
      {
        "name": "Kunavo",
        "sdkProvider": "openai-compatible",
        "baseUrl": "https://api.kunavo.com/v1",
        "apiKey": "${KUNAVO_API_KEY}",
        "models": ["claude-sonnet-4-6"],
        "contextWindow": 200000
      }
    ]
  }
}

在粘贴配置前，值得先了解三个 Nanocoder 特有的陷阱。sdkProvider 联合类型在 source/types/config.ts 中固定为五个值——openai-compatible、google、anthropic、chatgpt-codex 和 github-copilot——第四个值绑定到针对 ChatGPT 自有 Codex 端点的浏览器登录，而不是任意 base URL，因此没有可声明的通用 Responses 选项。如果你改为将 sdkProvider: "anthropic" 指向 Anthropic 兼容端点，Nanocoder 自己的提供商文档会警告，@ai-sdk/anthropic 会根据模型 ID推导输出上限；对于无法识别为 Claude 模型的任何模型，它会回退到 4096 个令牌，导致长回复在句中被截断且不报错；解决方法是在提供商条目中明确设置 maxOutputTokens。此外，由于设置按块解析，定义了 nanocoder.providers 的项目级文件会提供整个块——全局配置中的同级条目不会被合并进来。nanocoder config diff 是查看实际解析结果的文档记录方式。

这两个代码片段都未经针对 Kunavo 端点的运行时测试。Kunavo 发布了一个 OpenCode 设置指南，它是配置参考，而不是兼容性测试；Kunavo 没有为 Nanocoder 发布指南。将两个配置块都视为起点，运行一个有界任务，并读取你的账户实际记录的内容。

一个共同缺口：两个客户端都不了解你的网关模型元数据

两个客户端都依赖 models.dev 获取上下文限制、输出上限和每令牌成本。该文件截至 2026 年 9 月 19 日检查时列出了 222 个提供商，Kunavo 不在其中——本页面无法确定缺失的原因。其后果在两个客户端中略有不同，但同样适用于两者，因此这不是偏好其中一个的理由。

在 OpenCode 中，按模型声明 limit.context 和 limit.output，否则剩余上下文指示器会根据一个并非你的模型实际值的默认值进行计算。在 Nanocoder 中，设置 contextWindow 或按模型设置 contextWindows；其每次响应的页脚会显示令牌计数和根据 models.dev 定价估算的费用，文档谨慎说明：没有可用定价时会省略费用部分，因此缺少数字表示未知，而不是零。无论哪种情况，客户端显示的数字都是基于报告令牌数自行计算的结果——应与你的提供商账本核对，而不是与页脚核对。

每个项目会让你承担什么成本

两个客户端都是免费的。差异在于它们背后的内容。

Nanocoder 没有账户、层级、托管服务，也没有可升级的项目——其 README 表示没有付费层级限制实用功能，项目也将自己描述为由赞助者而非用户提供资金。这里有一项披露：Atlas Cloud 是列出的赞助者，同时也出现在 Nanocoder 自己的受支持提供商列表中，并销售编码方案。在一个原本没有供应商的项目中，这构成了非中立的激励；你应该了解这一点，而不是对此一无所知。

OpenCode 同样免费，但同一供应商销售两个产品，而它们正好争夺网关希望使用的那部分支出。两者都不是必需的：文档将两者都描述为可选项，而 Zen 的目标页面承诺让你在 OpenCode 中使用任何其他提供商。

阅读于 2026 年 9 月 19 日。本表有两点需要特别说明。Zen 的目标页面表示，计划通过按成本销售来传递降价，溢价仅用于支付处理费。其公布的三种 Claude 费率确实与Anthropic 自己公布的费率一致——Opus 5 为 $5 / $25，Sonnet 5 为 $2 / $10，Haiku 4.5 为 $1 / $5——因此，至少对这三种模型而言，与 Zen 的比较就是与模型供应商费率表的比较。这一核对仅针对这三种模型，并于 2026 年 9 月 19 日完成，不能说明 Zen 产品架上其余模型的情况。此外，Zen 的免费模型带有同一页面上印出的数据使用说明，从免费期间使用数据改进模型，到仅限试用且告知你不要提交机密数据的端点。附带训练权利的免费层，与不附带训练权利的免费层，是不同的产品。

任一客户端下方令牌账单的计算示例

这是说明性的令牌计算，不是实测任务成本，也不是账单上限。假设某个会话发送 200,000 个未缓存输入令牌，并接收 15,000 个输出令牌。费率来自实时的Kunavo 目录，按每百万令牌计价；你的实际会话会因仓库大小、工具输出以及代理重新读取文件的频率而不同。

这里人们真正想比较的是 OpenCode Go 每月 $10 的价格，而这并不是同类比较。Go 提供的是固定产品架，按模型设置 $15 至 $60 的月度上限：其自身的使用限制表中没有 Claude 模型，也没有 Gemini 模型；唯一的 GPT 条目是 GPT 5.6 Luna，Grok 4.6 也在其中——因此文档中的“开放编码模型”并不意味着仅限开放权重模型（截至 2026 年 9 月 19 日检查）。上面的模型属于完全不同的产品架。在这些假设下，$10 的预付 Kunavo 额度大约可以在 Claude Haiku 4.5 上支持 51 个此类会话，每次费用为 $0.192；在 Claude Opus 5 上则约为 10 个。这可以帮助确定预算规模；但不能告诉你哪个模型在你的仓库上产出更好的结果，而且标价最低并不等同于完成任务的成本最低——需要尝试三次的更便宜模型，成本可能高于只需一次尝试的模型。

真正同类的比较是 Zen 的按用量付费产品架，因为同一个模型会出现在两边。Zen 将 Claude Opus 5 的价格公布为每百万输入令牌 $5.00、每百万输出令牌 $25.00；Kunavo 的目录当前显示同一模型的价格为 $3.50 和 $17.50。这才是值得进行的比较，而且值得仔细阅读：Zen 的 $5.00 / $25.00 是 Anthropic 为该模型公布的自身费率，因此这是两个目录对同一模型采用不同定价，而不是加价转售商被压价。调整预算前，请在结账时确认两者，因为任一目录都可能重新定价。

Kunavo 的目录价格是计费下限而非上限：上游报告其费用时，账单金额取目录价格与上游成本乘以适用加价率两者中的较高值。缓存费用和外部工具费用不包含在此示例中。最低充值额为 $10 的预付余额，这是资金最低要求，而非任务费用或订阅费用。

设置你选择的方案

如果你选择了 OpenCode，上面的配置块就是完整的集成方式，而 OpenCode 集成指南详细介绍了两种线路格式；准备为密钥充值时，请创建 Kunavo 账户。如果你选择了 Nanocoder，请通过其 openai-compatible 提供商使用相同的基础 URL，并在试用期间保留一条可用线路——这里未对 Nanocoder 到 Kunavo 进行运行时测试。

还在犹豫？OpenCode 替代方案将选择范围扩展到这两者之外，OpenCode 的最佳 API专门比较适用于该客户端的提供商线路，OpenCode 定价深入介绍 Zen 和 Go，而智能体 API 目录记录了这一领域中的每个客户端如何处理自定义基础 URL。如果提供商配置块已经无法运行，找不到 OpenCode 提供商介绍了通常原因，OpenAI 兼容 API则解释了这一说法能保证什么、不能保证什么。

常见问题

仓库、发布和下载数据于 2026 年 9 月 19 日从 GitHub API 和 npm 注册表查阅获取；行为和价格声明于同日从两个项目各自的文档中查阅获取，models.dev 提供商列表也在同日核查。两个客户端均未针对 Kunavo 的端点进行运行时测试，也未进行性能或兼容性测试；本页中 Kunavo 的所有美元金额均为基于实时目录的示例性令牌费用计算，而非实测任务成本。