Claude 新版据称降价提速并调整默认模型

Fable 5.2 的升级重点，是把高难度 AI 编程任务的账重新算了一遍：原文称，标准输入、输出价格均降 20%，相同努力级别下输出最多快 30%，误拦截也明显减少。对开发者来说，真正值得看的是一次任务能否少等、少重试、少花钱。

但这些数字主要来自 Anthropic 的发布材料，作者没有独立复现。读这篇解读，需要分清产品调整、厂商测试和作者判断，再决定它是否值得进入自己的编程工作流。

便宜了 20%，为什么还不能直接算出省多少钱

据原文，Anthropic 在 11 月 9 日发布 Claude Fable 5.2 和 Claude Mythos 5.2。两者使用相同的底层模型，区别主要在安全过滤：Fable 面向更广泛的用户，Mythos 减少部分过滤，只向经过审核的研究和企业场景开放。

Mythos 的入口包括 Cyber Verification Program、Life Sciences Verification Program，以及通过 Claude Security 使用它的 Claude Enterprise 客户。原文称，这套准入方式自 9 月 1 日的 Mythos 5.1 发布后没有放宽。普通开发者实际要评估的，仍然是 Fable。

Fable 5.2 相比 5.1，标准输入和输出 token 单价都下降了 20%。原文还提到，Opus 5.5 在 9 月也做过同幅度降价。不过，文章没有提供绝对单价，不能据此算出具体项目的预算。

更关键的变量是 token 用量。原文称，在默认的 Medium effort 下，Fable 5.2 完成困难任务需要的 token 比 5.1 更少。如果任务、完成质量和重试次数相当，用量下降会与单价下降叠加，实际节省就可能超过 20%。

该比较的是完成同一项合格任务的总成本。

这里的「合格」很重要。输出便宜，但需要开发者多修几轮，账未必划算；生成更快，但工具调用和测试仍然很慢，整体耗时也未必同步下降。缓存写入另外收费，fast mode 则按标准价格的两倍计费，也都要算进去。

速度方面，原文给出的口径是：相同 effort 下，Fable 5.2 的输出速度相比 Fable 5.1、Mythos 5.1 最多提升 30%；开启 fast mode 后，token 生成速度最高达到默认速率的 2.5 倍。这些都是上限，不能理解为每次任务都能达到。

对有人盯着运行的交互式任务，付费换速度有价值；对无人值守的批处理，作者认为通常没必要。这个取舍合理，但还得看生成文字在整条任务链里占多少时间。

跑分涨了，能支持把日常编码都切过去吗

原文列出了两组编码与自动化成绩：FrontierSWE v2 从 56.3% 提升到 69.9%，AutomationBench 从 31.4% 提升到 51.4%。它们支持 Fable 5.2 在多步骤任务上有进步，但原文没有给出足够的测试配置，无法判断这些收益能在普通代码仓库里保留多少。

FrontierCode 2.0 的数据更适合用来理解模型与 effort 的关系：

• 在 High effort 下，Fable 5.2 达到 Opus 5.5 在该基准上的最佳已记录成绩，成本约为一半。
• 在 Xhigh effort 下，Fable 5.2 得到 49.1%，是 Anthropic 在该项测试中比较过的已发布模型最高分。
• Claude 应用和 Claude Code 的默认设置仍然是 Medium effort。

effort 可以理解为模型为任务投入的推理力度。High、Xhigh 的成绩展示了加大投入后的能力上限，不能直接当成默认使用体验。尤其「约一半成本」只对应这里的基准条件，不足以证明 Fable 在所有编码任务上都比 Opus 更划算。

另一个吸引眼球的案例，是 Anthropic 声称约 1,000 个 Fable 5.2 agent，在约 30 小时内用 Lean 完成费马大定理的形式化，早期内部工作则用了 11 天。形式化是把证明写进能够由机器检查的系统，不等于模型自己发现了这个定理。

作者明确表示无法独立核验。原文也没交代两次尝试的资源、起点和人工介入是否一致，因此它更适合展示大规模 agent 协作的方向，不能拿来估算个人项目的提速比例。

原文转述的官方定位其实相当克制：Opus 5.5 覆盖多数日常编码和知识工作；Fable、Mythos 面向更复杂的任务，尤其是模型需要自己协调流程、再把子任务分配给小模型的情况。一次跨文件重构，确实比补一个普通函数更接近这个定位。

少拦截了，是否就能放心扩大 agent 权限

Fable 5.2 的另一项变化，是减少正常请求被安全机制误挡的情况。按原文口径，总体误触发约减少 55%，网络安全相关误拦截减少 60%，生物相关减少 40%。

这对开发者有直接价值：合理的安全分析或代码检查，如果经常被拒绝，任务就会中断。但「误拦截减少」与「危险请求的防护强度不变」是两个需要分别验证的结论。Anthropic 声称两者同时成立，作者没有独立证据确认。

其他安全数据也要看清对象。原文称，反蒸馏保护能让蒸馏者可收集的数据减少 90% 至 99%。这里的蒸馏，是利用模型输出训练其他模型；这项数据并不直接说明日常编码更可靠。

沙箱测试针对的则是 Mythos：在对抗场景中，Mythos 5.2 使用沙箱外凭据或文件的比例为 3.1%，低于 Mythos 5.1 的 21%，接近 Opus 5.5 的 3.3%。另一次覆盖约 1,900 个场景的行为审计里，厂商自定义量表采用分数越低越好的规则，Mythos 5.2 为 2.67，Opus 5.5 为 2.79，Mythos 5.1 为 3.28。

这些数字呈现了内部测试的改善方向，但量表细节和外部复现不足，也不能把 Mythos 的结果直接当成 Fable 的结果。

误拦截减少，可以成为试用理由，不能成为放宽文件和凭据权限的依据。

我的判断

我认同这篇文章把价格、用量、速度和任务中断放在一起看。开发者付出的成本包括账单，也包括等待、重新解释需求和人工修复。单看某个跑分，很容易漏掉后面这些支出。

但作者对部分数字的信任偏快。「最多快 30%」不会因为数字具体就更可信，基准成绩也需要测试条件才能判断适用范围。现有材料支持安排一次有边界的试用，还不足以支持整个团队立即切换。

接入变化也有明确边界。原文称，11 月 9 日发布的 Claude Code 2.1.321，将默认 Fable 模型切到 5.2，并默认采用 Medium effort。这里说的是选择 Fable 时使用的版本，不能理解为所有 Claude Code 用户都被切换到了 Fable。次日的 2.1.322 增加了 Vertex 上的 fast mode；前一版 2.1.319 则涉及 MCP 任务后台运行和 Deny 设置。

订阅额度同样需要谨慎理解：原文称，Pro 和标准 Team 席位最多可将每周使用限额的 50% 用于 Fable，订阅者还会按订阅时长获得 1 至 3 次 Fable 额度重置，但没有展开具体规则。

与继续默认使用 Opus 5.5 相比，先把少量复杂任务交给 Fable，是更容易评估的选择。作者自己也只是开始尝试在多文件重构中优先使用 Fable，还没有长期结果。这部分是使用设想，不能当成实测结论。

能拿来做什么

• 选一次边界明确的前端或 Node 多文件重构，分别观察 Fable 5.2 和现有模型的完成质量、总耗时、费用及人工修复量，用同一套验收条件判断结果。
• 从默认 Medium effort 开始试用，在具体难题持续失败时再提高到 High 或 Xhigh，并记录额外投入是否换来了可验收的改进。
• 将 fast mode 用在等待成本高的交互任务上，先确认耗时主要来自模型生成，再判断两倍单价是否值得；无人值守任务优先评估标准模式。
• 用过去被误拦截的正常安全分析请求做回归检查，同时保留现有沙箱、文件访问和凭据权限边界，分别评估可用性与安全性。