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

VT Code 和 OpenCode 都是免费的终端编码代理：客户端不收费，并且都接受你自己的 OpenAI 兼容端点，因此这不是价格比较。真正的差异在于：各自允许你在哪里声明该端点、权限默认值分别倾向于哪一方，以及你是否希望在同一个工具中加入每月 $10 的订阅。 VT Code 是一个来自独立项目的单一 Rust 二进制程序，由一名维护者主导。OpenCode 是 Anomaly 公司推出的 TypeScript 代理，提供桌面应用、编辑器扩展，以及自带的两个第一方钱包。

首先必须澄清两个名称陷阱，因为任何一个弄错，都会使后面的所有内容失效。“VT Code”不是 Visual Studio Code，而且 VT Code 令人困惑地还提供了自己的 VS Code 配套扩展，使用单独的版本系列。而且，有三种不同的东西都叫 OpenCode——本比较中只涉及其中一种。

你实际比较的是什么

仓库元数据、发布版本和 dist-tag 于 2026 年 9 月 21 日从 GitHub API、npm 和 crates.io 读取。第四个名称冲突是：“OpenCode Go”也是 Anomaly 每月 $10 的订阅方案名称，与 Go 语言或已归档的 Go CLI 毫无关系；而 VT Code 将其内置提供商键之一命名为 opencode-go，使情况更加混乱。还要注意 VT Code 的版本变化有多快：0.164.0、0.164.2 和 0.165.0 都在 9 月 20 日至 21 日的大约 27 小时内发布，因此请阅读 tag，不要相信任何页面上打印的版本号，包括本页面。

应该选择哪一款

关于迁移成本。 容易迁移的一半是 AGENTS.md：两个工具都会从项目根目录读取它，因此描述你约定的文件在任一方向迁移时都能原样保留。昂贵的一半是其他所有内容。两种配置格式完全不同——一种是带有表数组的 TOML，另一种是为每个提供商指定 npm 包的 JSON——而且没有转换器，因此项目本地配置需要手动重写。MCP 定义、技能、插件、自定义代理或会话历史是否能迁移，是本页面无法确定的事项，因此除了这次重写之外，不估算迁移时间。

唯一值得影响决策的不对称性：端点可以存放在哪里

这是通用模板都不会提到的差异，而且它会颠覆通常的 monorepo 直觉。OpenCode 将自定义提供商视为普通项目数据：提交一个 opencode.json 即可生效，这样团队就能通过一个经过审查的文件，将所有人统一到同一个网关。VT Code 则有意拒绝这种做法。

VT Code 的配置字段参考在字段本身中明确写道：“来自由仓库控制的工作区/项目层的非空值会被拒绝；请在受信任的系统/用户配置中，或在显式选定的配置中定义提供商端点。”在 custom_providers[].base_url、custom_providers[].auth.command，以及 provider_overrides.*.base_url 和 .api_key_env 上也重复了同样的拒绝规则。其安全模型将这一理由命名为独立的一层——加载器会记录每个合并字段的获胜来源，将工作区根目录文件、工作区 .vtcode/ 文件和项目配置文件视为由仓库控制，并在提供商验证之前采取默认拒绝；文档称这可以防止仓库引入自定义提供商的可执行 auth.command，或通过被覆盖的基础 URL 重定向请求。

因此，实际后果是：使用 OpenCode，一个合并后的拉取请求就能将整个团队指向某个网关。使用 VT Code，同样的更改需要在每台机器的用户配置或系统配置中安装，或在启动时传入一个 --config 路径。这是真实的权衡——一方是部署便利性，另一方是供应链控制——无论你偏好哪一方，选择这里的客户端时，这都比任何功能列表更有说服力。两项事实均于 2026 年 9 月 21 日从 main 读取。

权限、自主性以及各自提供的界面

来源：VT Code 的配置字段参考、安全模型和提供商指南；OpenCode 的权限、提供商、服务器和 ACP 文档。全部于 2026 年 9 月 21 日读取，且描述的都是默认值——任一客户端都可以重新配置为另一种方向。两者都支持 ACP，也都支持 MCP，因此编辑器接入能力大体相当，而不是区分两者的因素。

钱流向的是钱包，而不是客户端

OpenCode 自带两种产品。VT Code 什么都不出售，而这本身就是一个决策输入：它发送的每个 token 都由你配置的服务计费，而且没有可退而使用的第一方方案。

价格和配额于 2026 年 9 月 21 日从 OpenCode 自己的文档读取。在与它们比较之前，有两点值得了解。Go 公布的按模型划分的数据条款并不统一——大多数行写明不用于模型训练且零日保留，但少数行注明保留 30 天，另有两个贡献者模型标记为用于训练且不属于零保留——因此请查看你打算长期使用的模型对应的那一行。Zen 会公布带日期的弃用信息，因此，以某个模型 ID 为基准的比较可能比页面本身更快过时。OpenCode Enterprise 仅提供联系表单，未公布价格，本页面也未引用其价格。

在你自己的端点上运行一次会话的成本

以下数字是用于说明的 token 算术，不是实测任务成本，也不是账单上限。假设一次代理会话发送 200,000 个未缓存输入 token，并接收 15,000 个输出 token——这是用于比较的假设，不是对你仓库的测量。费率是实时的Kunavo 目录每百万 token 价格；最后一列只是进行除法计算，因此会继承前面所有假设。

将最后一列与 OpenCode Go 每月 $10 的费用对照，但先别急着下结论。两者采用的并不是同一种计量单位：Go 的额度上限以使用其模型列表中的模型所产生的用量金额计价，而不是以你实际支付的金额计价；两者提供的模型也只有部分重合——GPT 5.6 Luna 在 Go 公布的列表中，而上表中的 Claude 和 Gemini 模型则不在其中。订阅买到的还有费用的可预测性，而不只是一个费率。这张表确实厘清了该如何看待这个问题：如果你的工作是每周使用低价模型进行几次长时间会话，按 token 用量计费会更早体现出成本优势；如果你整天高强度使用 Go 实际提供的模型，固定费用套餐就不再明显处于劣势。选择之前，请衡量你自己的会话用量，因为一个模型若需要再尝试一次，就会立刻抵消费率上的优势。

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

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

VT Code 这一侧是一个 [[custom_providers]] 块，而上文中的位置规则才是人们最容易弄错的部分：

# This block is rejected if it arrives from a repository-controlled
# layer. Put it in your user config, in the Unix system layer
# (/etc/vtcode/vtcode.toml), or pass it with --config / VTCODE_CONFIG_PATH.
[[custom_providers]]
name = "kunavo"
display_name = "Kunavo"
base_url = "https://api.kunavo.com/v1"
api_key_env = "KUNAVO_API_KEY"
api_format = "openai-chat"
model = "claude-sonnet-5"
models = ["claude-sonnet-5", "claude-haiku-4-5"]
context_window = 1000000   # omit this and VT Code assumes 128000

关于该块，有四点说明，全部来自提供商指南和字段参考。密钥从 api_key_env 中指定的环境变量读取，配置文档明确警告绝不要将 API 密钥放入 vtcode.toml。api_format 接受 auto、openai-chat、openai-responses 或 anthropic-messages——显式值会被遵循，而不是静默回退——Anthropic 路由值得单独关注，因为两种基础 URL 约定不同，基础 URL 参考对此有说明。设置 context_window 很重要：省略它时，提供商会被视为使用 128,000 个 token，这会在更大的上下文中悄悄限制压缩和预检检查。此外，VT Code 也会对自定义端点应用基于名称的 OpenAI 采样限制——例如，匹配 gpt-6-astra 的模型 ID 永远不会接收 temperature 或 top_p——指南本身的建议是：“如果需要在这类名称上固定值，请在网关上优先使用中性的模型 ID。”

OpenCode 的对应配置是一个数据文件，其中 npm 字段用于选择线路格式——对于提供 /v1/chat/completions 的端点使用 @ai-sdk/openai-compatible，对于 /v1/responses 使用 @ai-sdk/openai：

{
  "$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 }
        }
      }
    }
  }
}

OpenCode 还可以覆盖内置提供商的 baseURL，而不是声明一个自定义提供商；其文档说明，已知提供商的模型元数据来自 Models.dev——因此，手动声明的提供商必须提供自己的 limit——通过 /connect 命令添加的密钥会写入 ~/.local/share/opencode/auth.json。Kunavo 为该客户端发布了设置页面：OpenCode 集成指南。这里没有 VT Code 集成页面，而上面的 TOML 块是根据 VT Code 已记录的字段定义整理出的配置参考——两个客户端都未针对 Kunavo 进行运行时测试，也没有对任一客户端作出兼容性声明。请保留一条可用的路由，运行一个有边界的任务，并在切换日常使用的主力工具之前读取账户记录的费用。准备为密钥充值时，请创建 Kunavo 账户。

一项确实会耗费时间的安装警告。名为 vtcode 的公开 npm 包并不是当前版本的 VT Code：其 dist-tag latest 为 0.52.8，发布于 2025 年 12 月 24 日，而 crates.io 上的版本在 2026 年 9 月 21 日已为 0.165.0。VT Code 的安装文档列出了另一个 npm 安装路径——npm install -g @vinhnx/vtcode --registry=https://npm.pkg.github.com——以及 cargo install vtcode 和一个 Homebrew tap，后者需要先执行 brew trust vinhnx/tap，再执行 brew install vinhnx/tap/vtcode。同一份文档还提醒，Windows 构建产物仅尽力提供，可能并非每个版本都会提供；而 OpenCode 自己的安装页面则建议在 Windows 上使用 WSL——因此，仅依据它们各自的文档，两者都算不上为 Windows 提供一等支持的工具。

想进一步比较其他工具？Crush 与 OpenCode 对比将同一个 OpenCode 与 Charm 的 agent 进行比较，OpenCode 定价会深入介绍 Zen 和 Go，而OpenAI 兼容 API 参考涵盖了两个客户端所依赖的端点约定。

常见问题

核查时间为 2026 年 9 月 21 日：三个仓库的 GitHub API，以及 VT Code 的发布列表；opencode-ai、@opencode/cli和 vtcode 的 npm dist-tags；vtcode 的 crates.io 记录；VT Code 在 main 上的 README、安全模型、供应商指南、配置字段参考、安装文档和 VS Code 扩展清单；以及 OpenCode 的权限、供应商、服务器、Zen、Go 和下载页面。Kunavo 的 token 费率来自实时目录。本页面未安装、运行任何一个客户端，也未将其指向 Kunavo 端点；未进行任何基准测试或性能比较，也未声称存在此类比较；文中的所有美元金额都只是示例性的 token 算术，而不是实测任务成本。