同一编程智能体下，两款模型成本差多少

两个模型都把任务做对了，选型差距还能有多大？作者把 Kimi K3.1 Pro 和 Claude Opus 5.5 接入同一款编程 Agent，跑了 24 次任务：隐藏测试全部通过，但 Kimi 平均耗时约为 Opus 的 5 倍，单次费用约为 2.3 倍。

这组测试有用的地方，是把比较从跑分拉回了程序员每天面对的问题：等多久、花多少、结果能不能验收。不过，它测的是特定平台和 Agent 默认配置下的小型 Python 任务，不能直接当成复杂项目的能力排名。

都通过测试，为什么还是优先选 Opus

作者使用 OpenCode 1.19.4，以非交互命令 opencode run --auto 执行任务，通过 OpenAI-compatible provider 接入 QuickSilver Pro。配置没有 MCP servers、插件或额外 skills，其余保留默认设置。

六类任务覆盖双文件商店模块修复、时长解析器、保持行为不变的重构、注册校验、支持引用与循环检测的配置解析器，以及 Mustache 模板渲染器。对应隐藏测试数量分别为 18、84、317、84、57、136。

每个任务、每个模型各跑两次，共 24 次。两个模型分别在自己的 12 次运行中通过了全部 1,392 项隐藏测试。

差距出现在交付效率上：

指标	Kimi K3.1 Pro	Claude Opus 5.5
平均每任务耗时	409 秒	82 秒
平均每任务费用	$0.221	$0.094
12 次运行总耗时	82 分钟	16 分钟
平均每任务请求数	15.8 次	7.9 次

Kimi 在每类任务上都慢了 4 至 6.6 倍，不只是平均值被个别任务拉高。

在这组已经全部做对的任务里，Opus 的优势是更快、更便宜地完成验收。

但「质量打平」只能解释为测试结果相同。测试没有比较代码可读性、架构取舍或后续维护成本，也没有找到能让任何一方失败的任务，因此无法判断谁更擅长困难工作。

Kimi 多花的钱，主要花在输出和思考上

QuickSilver Pro 给出的每百万输入／输出 tokens 价格，Kimi 是 $2.00／$10.00，Opus 是 $1.00／$5.00。这是该平台的计价，不能直接套到其他渠道。

Kimi 平均每个任务输出 12,800 tokens，其中 64% 被记录为 reasoning tokens，也就是模型内部推理产生、不会直接成为代码的内容。它的输出量为 Opus 的 1.6 倍，输出单价又是两倍，最终仅输出部分的费用就超过了 Opus 一次完整运行。

输入缓存并没有失效。Kimi 的输入有 90% 命中缓存，未缓存输入的成本与 Opus 大致相当。真正拉开账单的是输出量和价格。

耗时还有另一层原因：Kimi 平均发出 15.8 次请求，Opus 为 7.9 次。作者将较长耗时归因于更多步骤，以及每一步开始前的推理。不过，文章没有把服务端推理、网络等待和工具执行逐项拆开，这仍是基于运行记录的解释。

其中一次 Mustache 任务，Kimi 启动了子 Agent，发出 41 次请求，耗时 18 分钟，费用 $0.65。去掉这次异常运行，剩余 11 次平均仍需 348 秒、$0.182，分别约为 Opus 的 4.3 倍和 1.9 倍。

更快的端点能缓解等待。Kimi K3.1 Pro Highspeed 使用相同模型，平均耗时降至 166 秒，约为 Opus 的两倍，但单次费用升至 $0.328。对于有人盯着屏幕等待的交互任务，这个取舍有意义；无人等待的后台任务，标准版成本更低。

默认配置的结果，不能当成模型能力上限

这次测试没有发送 reasoning-effort 设置。OpenCode 对自定义 OpenAI-compatible provider 不发送 reasoning 参数，Opus 报告的 reasoning tokens 为零，Kimi 则默认推理。

因此，作者比较的是两种模型接入后直接运行的表现。它没有限制 Kimi 的推理，也没有开启 Opus 的 extended thinking。OpenCode 还会按模型家族选择系统提示词和工具，所以「同一个 Agent」也不等于两边收到完全相同的系统上下文。

运行日期同样不同：Opus 在 2026-10-27 测试，Kimi 在 2026-11-02 测试。耗时包含客户端到 QuickSilver Pro、再到供应商的网络时间；Kimi 同一任务的两次运行，耗时最多相差 2.5 倍。速度差距可以参考，具体倍数需要在自己的环境中复测。

作者提供了可复现的 opencode.json，用同一个 provider 配置注册两个模型：

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "quicksilverpro": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "QuickSilver Pro",
      "options": {
        "baseURL": "https://api.quicksilverpro.io/v1",
        "apiKey": "{env:QSP_API_KEY}"
      },
      "models": {
        "kimi-k3.1-pro": { "name": "Kimi K3.1 Pro", "limit": { "context": 1000000, "output": 64000 } },
        "claude-opus-5-5": { "name": "Claude Opus 5.5", "limit": { "context": 1000000, "output": 64000 } }
      }
    }
  }
}

要留意 limit：这里配置的 context 为 1000000、output 为 64000，文章没有验证接近这些上限时的表现。

随后用相同提示分别执行：

export QSP_API_KEY=YOUR_QSP_KEY

opencode run --auto -m quicksilverpro/kimi-k3.1-pro "Fix the failing test in tests/"
opencode run --auto -m quicksilverpro/claude-opus-5-5 "Fix the failing test in tests/"

要留意 --auto：它会自动批准文件修改和 shell 命令，应当在可以重置的项目中使用。OpenCode 对自定义 provider 显示费用为 0，真实账单需要查看 QuickSilver Pro dashboard；作者的统计则来自每次响应 usage 块返回的费用，并逐次累加。

我的判断

我认可作者用「完成任务的成本」做比较。只看 token 单价，会漏掉输出长度、请求次数和异常执行路径；只看测试通过率，又会把 82 秒和 409 秒当成同一种体验。

但这份结果更适合帮助选择默认执行模型，证据还不足以排出通用能力高低。每个模型每类任务只有两次运行，仓库小而独立，单次耗时从半分钟到 18 分钟，没有覆盖大型代码库里持续数小时的修改。

Mustache 的成绩还要单独看。四次运行都下载并执行了官方 spec 测试，而隐藏测试用的是同一批文件，所以这项分数不具备独立验收的性质。另外五套隐藏测试由作者编写，虽然预先用参考实现检查过，覆盖范围仍取决于他们对规格的理解。

还有一个计费细节：Opus 每次请求固定缓存 8,028 tokens，大致对应系统提示词和工具定义，其余会话按完整输入价格计费。作者指出，更充分的缓存会进一步降低 Opus 成本。这能解释账单，却不能代替其他平台的实测。

作者建议用不同实验室的模型复核修改，这个思路可以采用；但文章没有展示复核效果，也没有证明 Kimi 能补上 Opus 的哪些盲点。它目前属于使用建议。

能拿来做什么

• 给自己的 AI 编程流程准备一组可重置的小任务，覆盖修复、解析和保持行为不变的重构，同时记录验收结果、总耗时和总费用，再决定默认模型。
• 如果你的日常任务接近文中的小型 Python 修复与规则实现，可以优先试 Opus 5.5；涉及前端页面或大型 Node 项目时，补测自己的任务后再沿用结论。
• 排查 Agent 账单时，把输入缓存、输出 tokens、reasoning tokens 和请求次数一起看，尤其检查是否出现子 Agent 带来的异常开销。
• 已经决定使用 Kimi 时，可以按是否有人等待来比较标准版与 Highspeed，并从平台账单核对费用，避免被 OpenCode 显示的 0 成本误导。