测试 harness 包括：Pi、Exo、Claude Code、Codex、DeepSeek Harness（4款）、Hermes、OpenCode、Oh My Pi、Kimi Code
测试模型：Kimi K3（选择K3，而不是 GPT、Claude，是因为测试者不想偏向 Codex 和 Claude Code)
任务类型： 21 项终端基准测试任务和 9 项深度软件工程任务
要点总结：
- 一共 360个任务，12款 harness。209 次成功，151 次失败。整体通过率为 58.1%。
- 完成率最高的是 Codex，66.7%（20个完成）；其次是DSH Creator 和 Claude Code，63.3%（19个完成），但 CC 单次通过的花费却高出 5.6 倍，同时也是耗时最长的。
- CC 的平均花费更高，是因为在其 19个成功案例中，有 3 个测试的 token 使用量占比高达 88%，其中最大的任务消耗了 24.6M token（占了 68%的用量），但缓存命中率只有 15.7%。分析认为一个重要原因在于测试框架与模型的适配问题。Claude Code 专为 Anthropic 模型设计，依赖其显式缓存控制语义。而 K3 平台暴露的是行为机制不同的隐式前缀缓存系统，原有的缓存策略可能无法无缝迁移。这种现象源于测试框架与模型的整体配置特性，未必是 Claude Code 本身的缺陷。
- 完成率最差的是 OpenCode和 Hermes，50%（15个完成）。
- 与模型出自同源的 Kimi Code，在完成率上并列第七（56.7%），成本效益则处于中游水平。
- 当同一任务需要反复执行且令牌消耗累积时，Pi 模型则是更优选择。
- Exo 在每个完成任务上成本最低（1.05 美元），部分原因在于其提前终止机制：面对最困难任务时，它在达到 51 步上限后以 1.46 美元成本终止，而其他框架仍在持续消耗资源。
- DSH 的对比揭示了预设配置的重要性。在同一模型和运行时下，其四套预设配置的通过率相差 6.6 个百分点，成本差异达 1.4 倍。
- 成本差异主要源于框架与模型的配对组合。缓存策略、工具循环和提示词设计都属于配对特性，而非框架固有属性；为某系列缓存机制优化的框架在此场景可能表现高效，在其他环境中却会显得昂贵。
链接：runta.com/blog/introducing-frontierharness-eval