OpenAI 在 2026 年 10 月 8 日发布客户案例称，LegalOn 在保持开发速度的同时，将预估日均 Codex 成本降低 65%。同一材料的标题使用了“砍半”的表述。摘要给出的方法只有两句：把 Astra、Sol、Luna 匹配到任务上，以及战略性地管理预算。材料未提供更细的基线、统计窗口或速度指标，因此本文只按已披露口径记录，不做额外推断。
两个成本口径
标题写 halves，摘要写将预估日均 Codex 成本降低 65%。两者都指向日成本明显下降，且摘要标明这是预估数字。材料没有解释两个口径为何不一致，也没有列出计入范围，例如 token、请求次数、失败重试或席位费用。速度一侧只有“保持开发速度”这一句定性判断，不见周期、吞吐或返工率。对厂商案例，更稳妥的读法是承认成本有大幅下降的对外表述，但不把百分比当成可复现的财务结论。
材料真正写到的做法
目前能落地的事实很少。LegalOn 并未用单一配置覆盖全部开发任务；Astra、Sol、Luna 被当作可按任务切换的选项；预算被主动管理。材料没有定义这三个名称对应何种模型、尺寸或模式，也没有给出匹配规则，更没有公开预算阈值或熔断条件。因此不宜把自动路由、按难度降级写成已证实机制。原文只支持两句话：任务与选项被对齐，预算有策略。
我的判断
案例的价值在问题意识：代码智能体一旦进入日常开发，账单就会变成运营问题，速度和成本必须一起管。按任务匹配不同选项、给预算设策略，这个方向对已铺开 Codex 的团队有对照意义。适用边界很窄。这是单家客户的预估日成本宣传，缺少对照、缺少代码质量与缺陷数据；65% 与“砍半”并存，说明对外数字经过简化。材料信息不足，不能读成通用省钱公式，也不能假设换几个模型名就能复制结果。对读者更有用的，是把“任务匹配加预算策略”当成待验证假设，用自己的任务分布和账单去量，而不是直接套用案例里的百分比。