排行榜上最不重要的一列
JetBrains 发布了 Kotlin Benchmark，用 SWE-bench 的方法论给编码智能体打分：数据集是 105 个来自活跃开源 Kotlin 仓库的工程任务，智能体拿到真实 issue 描述，要在项目里自行导航并产出可用补丁，解算结果在容器环境中用仓库自身的测试验证，不接受自报。JetBrains 把数据集、测试框架、方法论页与 GitHub 仓库一并公开，基础设施建立在开源项目 Multi-SWE-bench 之上。
榜单头名是 Claude Code 搭配 Opus 4.7 xhigh，解算率 85.7%，是榜单上超过 85% 的那个配置；JetBrains 自家的 Junie 与 OpenAI 的 Codex 紧随其后，均为 81.9%。
但如果只按榜单本身的排序读，会错过这一页上最有信息量的一列。把公开榜单按「每解一题消耗的 Token 数」重新排一遍，前二十个配置的跨度从约 6.6 万到 77.7 万，相差 12 倍；而同一批配置的解算率差距只有约 20 个百分点。更刺眼的是，一些花得更多的配置，解出来的题比只花十分之一代价的配置还少。
这个基准到底在测什么
Kotlin 值得单独一个基准，有三个理由：它已经是安卓开发的默认语言，在服务端也是 JVM 体系里的一等公民，而它此前长期被通用基准忽略。JetBrains 本来就维护 Kotlin_HumanEval 这类面向模型的评测，但那类评测回答的是「模型懂不懂语法」。Kotlin Benchmark 测的是上一层：智能体能不能在一个既有项目里完成一个可被验证的工程任务——也就是团队真实工作的样子。
验收方式的差异决定了这个基准的可信度。任务只有在补丁通过仓库自身测试时才计为解出，没有自报，也没有主观判断。这既抬高了评测成本，也让它比问答式的编码评测更接近采购决策真正关心的问题。
把榜单按成本重排之后
按每解一题 Token 数排列，画面完全不同。
效率最优的是 Claude Code 搭配 Opus 4.7 medium：解出 80 题，累计 531 万 Token，每任务约 6.6 万，总耗时 4 小时 54 分。它的 Token 消耗只有榜首配置的一半，解算量却达到了榜首的 89%。
Junie 搭配 Opus 4.6 解出 81 题，745 万 Token，每任务约 9.2 万，耗时 8 小时 36 分。Codex 搭配 GPT 5.3 Codex xHigh 解出 82 题，856 万 Token，每任务约 10.4 万。
榜首组合 Claude Code 搭配 Opus 4.7 xhigh 解出 90 题，消耗 1059 万 Token，每任务约 11.8 万，耗时 10 小时 37 分。
代价侧的例子更能说明问题。Junie 搭配 Opus 4.7 max 解出 86 题，烧掉 1998 万 Token，每任务约 23.2 万，耗时接近 20 小时。Codex 搭配 GPT 5.5 xHigh 同样解出 86 题，却用了 3878 万 Token，每任务约 45.1 万，耗时 8 小时 30 分。同样解出 86 题，两者 Token 相差 3.7 倍——而差别不在模型本身，在智能体外壳的调度方式。
底部同样值得看。Junie 搭配 Gemini 3 Flash 解出 64 题，4017 万 Token，每任务约 62.8 万；Gemini CLI 搭配 Gemini 3 Flash 解出 47 题，3653 万 Token，每任务约 77.7 万。两个 Flash 配置都落在效率表底部。
四个反直觉的结论
把这些数字放在一起，能读出四条对工程决策直接有用的判断。
推理档位的边际收益很差。 medium 档用一半 Token 解出了 xhigh 档 90 题里的 80 题。多出来的 10 题，代价是 528 万 Token，折算下来每多解一题约 52.8 万 Token，约为 medium 档平均单题成本的 8 倍。如果团队的日常任务大多落在偏易的一端，把推理档位拉满，主要是在为 medium 已经便宜解决的问题付溢价。
同一个模型换外壳，账单能差 3.7 倍。 这是「你选的不是模型，是循环」这句话到目前为止样本量最大的公开证据。外壳的调度效率——上下文怎么组织、工具怎么调用、失败怎么重试——已经和底座模型同等重要。
Flash 档不等于便宜。 每 Token 单价低，和每解一题成本低，是两件事。弱模型失败率更高，而每一次失败都要把整段上下文重烧一遍，等验证步骤说「不行」的时候，Token 已经花掉了。真正的成本单位不是 Token，是解出来的任务。
时间预算是另一本账。 Junie 搭配 Opus 4.7 max 跑完这套题花了接近 20 小时，Claude Code medium 不到 5 小时。对在代码评审间隙等智能体回话的开发者来说，4 倍的墙钟时间本身就是成本，即使 Token 数完全相同。
另外两组独立测量指向同一件事
把视角从 Kotlin 挪开，这个结论并不孤立。
Composio 团队做过一组对照实验：同一个模型 Kimi K3，分别放进 Claude Code、Hermes 与 Kimi Code 三种外壳跑 28 个完全相同的任务。成功率差不多——22、21、20 题；Token 消耗却拉开了代际：中位数分别约 6.1 万、6.7 万与 34 万，最省与最贵之间接近 6 倍，而在个别任务上差距可以放大到 30 倍。按 Kimi K3 每百万输入 Token 3 美元计，平均单任务成本约 0.22、0.28 与 2 美元。速度也不重合：中位耗时 Hermes 最快 179 秒，Kimi Code 297 秒，Claude Code 348 秒。最省的与最快的并不是同一个。
Artificial Analysis 在 DeepSWE 与 Terminal-Bench v2.1 上跟踪了 326 个任务，每任务平均跑三次，同时记录成本、Token 与时间。它把差异归因到一个很具体的量上：启动税。在完成任何有用工作之前，外壳会先把自己的系统提示、工具描述与环境配置发出去。Aider 这部分开销约 700 Token，OpenClaw 约 26000 Token，相差约 40 倍。启动税只付一次还能忍，问题在于它会随轮次反复重发：一个 26000 Token 的地板，跑十五轮就是 39 万 Token 仅用于结构本身。缓存命中率是另一个杠杆：Claude Code 的输入 Token 里只有约 1.5% 来自缓存，Codex 约 70%，而新鲜输入的价格约为缓存输入的五倍。缓存折扣取决于网关与端点，不只是一个外壳内部的实现细节。
两组测量的口径各不相同，但结论一致：外壳架构对成本的影响，量级上大于模型选择。
落到选型上怎么用
这组数字最实用的地方，是它把质量与成本这两列在同一张表里分开了。
建议把度量单位从 Token 换成每解一题——更准确地说，是每完成一个通过验证的任务。一个以回滚补丁收尾的会话，Token 是全额付掉的。团队内部真正该盯的指标是每合并一个任务的 Token 数。
其次，把缓存命中率纳入评估清单，和上下文窗口、模型支持放在同一档。同样一个模型，走不同路由，缓存命中率可能差出几十个百分点。验证方式应该是读用量字段，而不是看宣传页。
第三，把墙钟时间和 Token 分开评估。20 小时的配置和 5 小时的配置，在分数接近时其实是两种不同的产品，适配不同的工作节奏。
第四，不要只看榜单前两名。更有信息量的做法是在成本表的两个极端各挑一个配置，用团队自己仓库里的十张真实工单跑一遍对照，数解出来的任务，而不是数跑完的次数。
需要克制的地方
其一，榜单里的 Token 数来自官方排行榜，而每解一题这一列是二次计算的结果，不是官方口径；不同来源的汇总数字个别处存在出入，引用时应回到方法论页核对。其二，105 个任务全部来自公开开源仓库，这些仓库很可能已经进入模型的预训练暴露面，任务描述也通常自带足够上下文，因此 85.7% 这个高分不能直接外推到私有代码库——另有一组在私有企业代码库上进行的评测，最好成绩为 38.8%。JetBrains 自己在公告里也写明，分数是信号，不是对某个具体代码库的保证。其三，这套基准目前只覆盖 Kotlin，向 Java、Python 等语言迁移时结论是否稳定，尚无公开数据。
结语
这份榜单真正推动的，是一次度量口径的更换。过去两年行业比的是模型在基准上的分数，而企业账本上记的是每交付一个任务的成本。当同一模型在不同外壳下的 Token 消耗能差 3.7 倍、启动开销能差约 40 倍、缓存命中率能差几十倍时，采购清单不该再从模型名字开始。