GLM-5.2 在 45 个 terminal-bench 编码代理任务上与 Claude Opus 持平，成本不到一半（内含完整方法及失败日志）

我们想知道开放权重模型是否真的能胜任前沿的编码代理工作，因此我们将 GLM-5.2 与 Claude Opus 进行了直接对比，采用代理实际运行的方式——不是在静态评估上，而是在真实的编码代理（Claude Code）中，针对 terminal-bench 任务，在真实 shell 环境中运行，并由每个任务自身的隐藏测试进行评分。通过/不通过二选一，无部分分数，无模型作为评判者。两次运行的设置完全相同：相同的代理、提示、工具、40 轮预算和 45 个任务。唯一不同是每轮回答的模型。我们的发现：质量相同——每个模型都恰好解决了 45 个任务中的 25 个。答案相同——它们在 43/45 的任务上结果一致（24 个两者都通过，19 个两者都失败），其余两个各赢一个。没有哪个类别中一方系统性更强。失败模式相同——两者都因自信地错误而失败，即在隐藏测试拒绝的工作上声明 "已修复 / 所有测试通过 / 已验证"。每个干净的 GLM 失败日志都以此结束，Opus 也产生了相同的模式。成本：启用提示缓存后，GLM 的支出约为 Opus 的 46%（约 15 美元对 32.67 美元），结果相同。即使不缓存，也已便宜约 10%。明确说明注意事项：45 个任务有意义但有限，且模型是非确定性的，因此我们更看重 43/45 的一致性，而非 25=25。GLM 的 token 效率也较低，它需要多运行约 37% 的轮次（760 对 554）才能得到相同答案，这是成本差距没有更大的唯一原因。我们还不得不排除一些早期的 GLM 失败，这些失败实际上是上游 502/429 速率限制所致，而非模型本身——值得任何通过提供商 API 对开放模型进行基准测试的人注意。完整报告包含轮次分布、token 分解和逐字失败日志：https://entelligence.ai/blogs/glm-5-2-vs-claude-opus-coding-benchmark