Databricks在一篇技术博客里公开了自己控制AI编程工具支出的做法。打开AI Gateway的智能路由后,单次任务平均成本能降超过30%;调整工具链和缓存策略后,生成的token数量和相关费用降幅接近50%。这两个数字都写在Databricks自己的博客和图表里，但网络上流传的"AI编程支出降70%"这个说法，在原文中找不到对应出处，更像是不同环节数字被叠加或转述走样后的版本。
这次披露真正值得看的,不是数字大小，是思路变化:企业管理AI编程成本，正从"卡预算、限用量"转向给模型、任务和上下文做系统调度。这套经验来自Databricks自身部署，也参考了Stripe、Coinbase、Uber、Ramp等公司的非正式交流——文中明说这是方向性数字，不是经过独立审计的行业基准。别的公司照搬,未必管用。
钱花在哪:不是那句话本身
开发者输入的指令通常就几个字，比如"帮我修一下这个bug"。但代理接到指令后要做很多动作:搜代码库、调用工具、拉取系统提示和技能配置。真正送进模型推理的内容里，开发者最初打的那几个字只占很小比例。
这解释了为什么"少提问"这种直觉解法基本不管用——省不到关键的钱。真正的成本大头是代理自动拉取的上下文和工具调用，不是开发者主动输入的内容。
Databricks反过来压缩上下文本身:更频繁做压缩(compaction)、换用更省话的harness、审查常用工具的输出冗余度，配合手动调优的prompt缓存命中率。仅这一项调优，就让token生成量和相关成本降了近50%。
模型换着用,但别信榜单
Databricks说模型迁移是最大的省钱杠杆。前提是企业得自己评测——公开榜单基本判断不出真实编码表现。它跑了针对内部多百万行代码库的评测，发现GLM系列性价比不错，已经推给内部开发者用。
但这条路不是单向乐观的:
| 测试方 | 对比对象 | 结果 |
|---|---|---|
| Databricks内部评测 | GLM系列 vs 主流模型 | 性价比更优,已推给内部开发者 |
| Stripe内部测试 | Opus 4.7 vs Opus 4.6 | 质量没明显提升,成本更高,未内部上线 |
| Databricks自测 | Opus 5.0 vs Opus 4.8 | 出现成本倒退 |
真正的省钱杠杆在效率前沿，不在盲目追最强模型。但换模型要拿自己代码库测，不能只看公开基准分数——同一个模型,在别人的评测里领先，在你的真实任务里未必划算。
要频繁换模型，开发者不能被绑死在某个harness上。这是Unity AI Gateway和meta-harness(Omnigent)存在的理由:开发者继续用惯的Claude Code、Codex或Cursor，系统在后台把请求路由到更便宜的模型或工具链，不用逼人天天换习惯。
预算怎么管:分级,不是一刀切
Databricks的说法和多数直觉相反:硬性断供几乎所有公司都只当最后手段。原因很简单——一刀切断掉高消费开发者的权限,公司和员工都不想看到这个结果。其中一部分"烧钱大户"恰恰是靠AI拿到了成倍产出的人，断供等于误伤真正在用工具赚回成本的人。
取而代之的是分级响应:先给可见的实时花费看板,超线后弹出可自行清除的预警,再往上要走审批,最后才是降档到便宜模型或彻底暂停。
这套逻辑对两类人的落点不一样。
企业里负责开发工具、AI基础设施和云成本的技术管理者,第一步不是设月度硬顶，是先把AI Gateway这类网关接进现有工具链,看清楚钱到底花在路由、上下文还是工具调用上,再谈分级降档怎么设线。
评估要不要引入或扩大AI编程工具的开发团队和采购决策者,别只比模型标价——GLM便宜不代表在你的代码库里跑得动，Opus贵也不代表值回票价。真正该做的,是拿自己的代码库和真实任务跑一遍评测,再决定迁移还是扩量,这一步目前没有现成的通用答案。