Anthropic的编程模型Fable发布后，好用是真的好用，贵也是真的贵。开发者Drew Breunig在他的新文章里说了一句大实话：以前没人愿意花时间优化编码工具链，因为新模型总会以更低价格补齐旧模型的短板——直到Fable出现，这套假设第一次不成立了。
发生了什么：智能到顶，便宜没跟上
过去几年，AI编程模型的迭代逻辑近似摩尔定律：等一等，下一代模型又快又便宜，工程团队不必自己动手优化。
Fable打破了这个节奏。它确实强，但成本高到不划算全量使用。与此同时，Opus、GPT-5.6（Breunig原文里写作"5.6"，容易被误读成Claude系列，其实是OpenAI家族的型号）、Kimi K3、GLM这些非顶配模型，对大多数常规代码需求已经"够用"。
Anthropic自己的成本研究给出过一个对照：在SWE-bench Pro的某个子集上，Opus 5只用约六成的Fable成本，跑出了91.7%对91.3%的接近成绩。差距小到可以忽略，价格差距却不小。
Kimi K3的情况更微妙——它在部分前端编码测评里一度反超Fable和GPT-5.6，但Moonshot自己的研究仍把它整体排在两者之后。便宜模型不是全面碾压，是局部够用。
- 结论.贵模型的胜负手，正在从"能不能做"变成"划不划算"。
Fable 5 的API定价是每百万输入token 10美元、输出token 50美元，支持1M上下文窗口，最高128k输出token——这是它昂贵的直接来源，也是团队开始"精打细算"的起点。
三层杠杆：模型、上下文、Harness
Breunig把编码系统拆成三个能各自优化的部件：模型本身的智能水平、上下文（喂给模型的任务信息）、harness（负责选上下文、调工具、分配任务、校验结果的那套系统）。
以前大家只调第一个旋钮，等它自动变强变便宜。现在三个旋钮都要拧。
Breunig给出的实际工作流很直白：用Fable负责需求澄清和设计定型，把想清楚的详细brief交给便宜得多的GLM 5.2去做常规实现。贵模型管思考，便宜模型管干活。
这套分工听起来简单，落地却是体力活——要建立路由规则、要写verification体系、要维护多套prompt适配层。免费的时候没人愿意做这些，现在不做不行。
路由体系自己也压在一个"顶层模型"上
这里有个被原文那句引言完全遮住的张力。Breunig更早的文章里提过，Fable曾出现过静默降级——把任务偷偷委派给旧模型却不告知用户，这件事在研究圈引发过不满；企业客户也因为数据留存合规问题对它心存顾虑；Fable一度下线，直接暴露了"依赖单一模型"的风险。
问题就在这儿：路由体系的顶层，往往还是要靠一个足够强的模型做需求澄清和设计定型。如果这个顶层模型本身会静默降级、会掉线，路由体系的地基就不算稳。
Breunig把当下的编码agent比作"高轮自行车时代"——车轮本身很炫，配套的路、维修点、骑行规范都还没跟上。这个类比不完全贴切，但方向对：技术领先，组织能力滞后，是每一轮新技术扩张期都会重复的旧剧本，个人电脑普及初期的企业IT架构也是这么被拖着走的。
智能已经溢出，制度还没跟上。
"按任务算成本"也有软肋
支持路由化的一个论据是：应该按完成一个任务的总成本来比较模型，而不是单纯比token价格。这个思路成立，但它自己也承认一个漏洞——便宜模型如果需要更多轮修正、更长的推理链、更多次agent调用，省下的钱会被磨掉一部分。
- 风险.价格洼地不等于真实成本洼地，路由到便宜模型未必真的划算，得看返工率。
这也是为什么"路由"这件事目前更像是头部团队的能力，而不是标准答案。它需要足够的工程投入去验证每个模型在每类任务上的真实性价比，普通开发者和小团队很难有这个余力。
免费午餐没了，账要自己算
回到开头那句大实话：以前等等党永远是对的，现在等等党要先学会记账。Fable证明了智能可以再往上顶一截，但也证明了"更强=更该用"这个等式已经不成立。
对企业工程团队来说，值得投入路由体系的门槛，是任务量足够大、返工成本足够高；对独立开发者，继续用一个够好的模型可能仍是最省心的选择。这条分水岭，接下来会由谁先把路由体系做成标准产品来决定——Anthropic会不会官方化这套路由逻辑，是下一个值得盯的变量。