一家公司把自己数百万行、覆盖十几种语言的真实代码库拿出来，让Opus 4.8、Sonnet 5、GLM 5.2这些模型和Claude Code、Codex、Pi这几种调用工具真刀真枪跑了一遍编码任务。Databricks这份内部基准测试最扎眼的结论不是哪个模型分数最高，而是两件颠覆常识的事：开源的GLM 5.2已经能在质量上追平Opus 4.8，成本却便宜三成；而真正决定一次任务花多少钱的，往往不是模型贵不贵，是外面那层负责喂给模型多少上下文的"harness"。
这份基准没有公开数据集，测试的是Databricks工程师过去合并的真实PR，人工核对过任务描述和测试用例，官方称之为对SWE-bench一类公开榜单"题目已泄入训练集、场景与企业代码库脱节"的回应。
GLM 5.2挤进了本该属于闭源模型的位置
过去一年，行业默认的认知是开源模型主打性价比，真正啃得动复杂任务的还是Opus、GPT这类闭源旗舰。Databricks的数据把这条默认认知松动了一角：GLM 5.2在最高能力档位上和Opus 4.8统计持平，单任务成本却只要$1.28，比Opus的$1.94便宜近三成。
对企业客户来说，这意味着模型选型清单里第一次有了一个理由充分的开源选项，不再只是"便宜但凑合用"，而是"在同一档位里更便宜"。当然这份结论建立在Databricks自己偏后端、偏Scala/Go/Rust的代码库上，前端或移动端能否复现，目前看不清。
每token价格是个会骗人的指标
更反直觉的是Sonnet 5的例子。它的每token价格比Opus 4.8便宜约1.7倍，按常理算账应该更省钱。但实测下来，Sonnet完成同样任务反而要花$2.09，比Opus的$1.94还贵，完成率也低了六个百分点（81%对87%）。原因很简单：Sonnet为了做完任务读得更多、想得更久，消耗的token量是Opus的1.9倍，单价优势被数量劣势吃掉了。
省钱靠比单价，是个已经过时的心智模型
这个例子提醒的是工程管理者一类人：选模型不能只看官网标价，得看它在真实任务里到底要跑多少轮、读多少上下文才能收工。单价便宜的模型如果效率低，账单反而更贵。
上下文管理，被低估的成本开关
比模型选择更隐蔽的变量，是调用模型的harness。Databricks拿同一个模型、同样的思考强度，分别通过Claude Code/Codex和一个叫Pi的简单harness跑，质量基本没差，但单任务成本能差出两倍以上。
Pi每轮喂给模型的上下文只有Claude Code/Codex的三分之一左右，靠的是把工作集控制得更紧、更少来回折腾就把任务做完。Databricks的结论是，模型选择只是拼图的一块，harness怎么裁剪上下文同样决定成本——这也是它投资Omnigent这个"模型/harness切换层"产品的理由。
这里有个需要提醒的地方：这份基准出自一家正在推广自家harness切换工具的公司之手，客观上也是在为自己的产品逻辑背书。它不是一份独立第三方评测，方法论也没有公开数据集供外部复现，读者可以参考结论，但没必要当成中立学术研究照单全收。
- 结论.省钱的第一步不是换更便宜的模型，是搞清楚现在用的harness到底喂了多少上下文给模型。
- 风险.基准非公开、自评自测，且发布方同时在卖harness切换产品，结论存在利益关联，尚无独立第三方复现。
对每天要为AI编码工具付账单的工程团队来说，这份数据至少给了一个可操作的检查清单：先看token单价还是先看端到端任务成本，先纠结模型还是先审计harness。答案已经很清楚了。