Anthropic 这次发布了两款模型，名字很拗口：Claude Fable 5.1 和 Claude Mythos 5.1。官方说它们是编码和知识工作领域最先进的模型，但真正让开发者圈子躁起来的，是作者 Thariq 在实测里透露的一个细节——切换 effort 不再破坏 prompt cache。这句话如果翻译成人话，就是：你可以随时调整模型的工作强度，但不用再为缓存清空额外买单。在 AI 成本越来越敏感的今天，这个变化比“最强”两个字实在得多。
新模型上桌：不只是参数升级
编码与知识工作，两条腿走路
Claude Fable 5.1 和 Claude Mythos 5.1 不是同一个模型的两种变体，而是两个明确分化的产品方向。前者为编码场景专门打磨，后者为知识工作场景深度优化。Anthropic 没有追求一个“全能王”，而是把问题拆开：写代码和做分析，本来就不该用同一套权重。
这种策略跟过去“一个模型吃天下”的思路完全不同。你不需要在代码能力和推理能力之间做无谓的取舍。选对型号，等于直接跳过了试错阶段。Thariq 在花了大把时间深入研究后，给出了一句干脆的评价：模型很好。这不算长文评测，但足以说明第一观感是正面的。这次发布的时机也很有意思——正值各家厂商在年中密集更新模型，Anthropic 选择用双模型应战，明显是想在细分领域占住位置。
“最先进”这句话，得看场景
Anthropic 这次把“最先进”三个字摆在了宣传页上，气魄不小。但 Thariq 的实测提醒我们，先进与否要看任务怎么匹配。在编码场景里，Fable 5.1 处理代码生成、重构、Debug 的能力确实惊艳；在知识工作场景里，Mythos 5.1 面对长文档理解、复杂推理和结构化的信息提取，也表现出了扎实的功底。
换句话说，没有普遍适用的最强模型，只有准确匹配的合适模型。你非要用 Mythos 5.1 去写脚本，或者把 Fable 5.1 扔给一堆合同做解读，结果大概率不会好看。Anthropic 这么做，其实是在替用户提前做了一道选择题，帮你避开那种“什么都会一点，但什么都不精”的尴尬。
Effort 旋钮：这次真的能拧了
低 effort 适合什么活？
Thariq 给了一条很实操的建议：对于需要较少验证、边缘用例也不多的任务，直接上低 effort。这个建议背后是模型的运行机制——低 effort 模式下，模型会减少对输出的自我检查和回溯，只保留最基本的推理链条，从而在保证结果正确的同时大幅压低 token 消耗。
什么样的任务算“边缘用例少”？一个简单的 API 参数校验函数，一段格式固定的周报摘要，或者把一段 JSON 转换成另一种结构。这些任务都有明确的对错标准，也不需要模型发挥天马行空的创造力。这时候用高 effort，模型反而容易多想，输出更慢，费用更高。
Claude 系列里的 effort 参数并不是新东西，但这次它的使用体验变得更平滑了。以前，调档位要小心谨慎，因为缓存可能说没就没；现在，你可以大胆地试。别把模型当成一个只有最大档位的电钻，学会根据任务难度调档，才是精打细算的玩法。
Prompt cache 不再被“重来”击穿
这大概是整个实测里最值钱的一条信息。以往的很多模型，在切换 effort 等级时，prompt cache 会直接失效。缓存失效的后果很直接：相同前缀需要重新计算一遍，成本瞬间回到原价，甚至更高。对于反复调试 prompt 的人来说，这就像每次改一个参数，就要为整个前缀重新付一次钱。
而 Claude Fable 5.1 和 Claude Mythos 5.1 解决了这个问题。Thariq 明确说，切换 effort 不再破坏 prompt cache。这就给了开发者极大的操作自由度：你可以根据任务紧急程度、token 预算临时调整 effort，而不用担心缓存重建带来的隐性成本。
这背后是更聪明的缓存管理策略，也暗示模型对上下文复用有了更深层的兼容。对高频调用 API 的开发者来说，这是一项实打实的优化，甚至比模型本身的分数提升更让人心动。毕竟，省下来的都是真金白银。
实测之外：算账与选型
成本控制的现实账
切换 effort 不再破坏 prompt cache，这个改变的直接收益就是成本。举个简单的例子，你有一个长期运行的自动化流程，prompt 前缀基本不变，只是偶尔需要根据任务难度切换 effort。以前，每切换一次，缓存就作废一次，相当于每次都要为同样的前缀付两遍钱。现在，这笔钱省了下来。
对于把模型 API 嵌入业务系统的团队，这可能是每个月都能在账单上看到差距的事。再加上低 effort 模式本身就能减少 token 消耗，两个优化叠加，单个请求的成本可以降得相当明显。这也是为什么 Thariq 的这条建议会被反复转发——它不涉及玄学，直接关乎预算。
工作流里怎么选？
如果你已经用 Claude 模型搭了整套工作流，现在多了两个选择：Fable 5.1 负责代码相关任务，Mythos 5.1 负责知识处理。这不是让你把原来的 prompt 原样搬过去，而是建议你重新审视任务与模型的匹配度。代码评审、bug 修复、单元测试生成，这些可以交给 Fable 5.1；合同分析、研究摘要、企业内部知识库问答，Mythos 5.1 会更擅长。
调整的时候，记得利用这次新加的自由度——在不同 effort 之间来回切换，不用再担心缓存被击穿。比如白天跑批处理任务用低 effort 省钱，晚上做复杂推理时再切回高 effort，整个流程可以无缝衔接。这种灵活性，在之前的版本里是想都不敢想的。
长评测未至，先看风向
作者 Thariq 的初步判断
Thariq 花了很多时间深入研究这两款模型，但他自己说，长文评测还在后面。这意味着现有的建议只是第一轮实测的“速写”，不是最终结论。不过，即使只是速写，也比那些冷冷地贴出 benchmark 对比的官方公告更有温度。
他特别强调了 effort 和 cache 这两个操作层面的变化，这些都是日常使用中绕不开的细节。如果你正在犹豫要不要接入新模型，他的观察可以作为很好的起点——尤其是那些已经在上一个版本上构建了工作流的人，最需要知道切换成本到底高不高。从目前的信息来看，切换成本确实降下来了。
模型矩阵背后的战略意图
Anthropic 没有做一个全才，而是拆出了两个专才。这背后的战略意图很清晰：编码和知识工作，是目前企业级应用里需求最密集、付费能力最强的两块市场。与其用一个均匀分布的模型去同时满足两者，不如各自针对场景做深度优化，让每一分算力都花在刀刃上。
当然，这也是市场竞争的必然结果。OpenAI 有 GPT 系列打底，Google 有 Gemini 压阵，Anthropic 需要拿出更锐利的产品线来留住开发者。随着这两款模型在 OpenRouter 等平台陆续上架，它们很快会从发布公告走向真实的工程环境。到时候，谁更“先进”，谁更“顺手”，自然会有更明确的答案。
