行业动态Simon Willison03:55
引用 Drew Breunig
Quoting Drew Breunig
引用他人观点而非原创内容，价值有限，但可作行业观察参考。
判断
对自建编码流水线的团队，选型问题从「等下一代模型来兜底」变成「哪类活路由给哪个模型」；代价是省下的调用费要靠上下文工程和路由逻辑的工时去换，换到的是成本可控，不是能力上限。
依据
Drew Breunig 在《Fable & The End of the Free Lunch》里说：Fable 出现前，花时间优化 coding harness（模型之外的脚手架：提示、工具编排、上下文拼装）和 context strategy（上下文策略）显得很傻，因为新一代模型会以同样甚至更低的价钱发布，顺手把这些问题抹平。Fable 落地后确实强，但价格高；而 Opus 以及 5.6、K3、甚至 GLM 对大部分代码已经够用，于是他们开始追问「哪类活该交给哪个模型」。这正是免费午餐结束的机制：模型换代不再同时压价和补短板，工程投入第一次有了正回报，路由从可选优化变成必须维护的资产。Simon Willison 只是转录这段话，没有附自己的测试或价格数据；页面标签计数（llm-pricing 91、claude-mythos-fable 41、drew-breunig 21）只反映话题热度，不构成任何价格对照，所以这条只能当从业者观察读。
没写清 材料未给出 Fable 与 Opus、5.6、K3、GLM 的实际单价和调用量，也没有 Breunig 团队的分流比例，因此省下多少钱、路由本身要花多少维护成本，都无法核算。
下一步 查 Fable 与 Opus 的官方每百万 token 报价表，确认 Breunig 说的「贵」是贵几倍，再决定这条是否还成立。