Fable 5.1降价了，额度却更不够用

发表于 2026-09-02 分类于 AI

Anthropic 发布 Fable 5.1 时，首先吸引我注意力的，并不是密密麻麻的各项指标提升，而是这样一句话：缓存读取价格降低 75%。

我当时的第一反应是：这样一来，我的每周额度是不是终于能多撑几天了？

因为自从开始使用 Fable 之后，我每周 $200 Max 套餐的额度就变得完全不够用了。这点上我的感受很明确 - 以前只有 Opus 4.8 的时候，同样的工作强度基本能够撑过一周；开始用 Fable 处理复杂任务后，周额度开始稳定见底。我也试过把 Opus 5 设为默认模型，结果情况反而进一步恶化：回复更长、过程更啰嗦，额度消耗得也更快。

我现在只能主动给不同模型分工。复杂任务前期的 brainstorming、spec 和 plan，用 Fable medium；相对简单的任务，以及 plan 已经确定后的执行阶段，全部切回 Opus 4.8 high。

但这次仔细研究之后才发现，“缓存读取价格降低 75%”和“订阅用户可以多用 75%”完全是两回事。更有意思的是，同一个 Fable 5.1，既可能比上一代贵 20%，也可能便宜三分之二。

区别在于你怎么用它。

同一个 5.1，既可以更贵，也可以便宜三分之二

Artificial Analysis 测试了 Fable 5.1：在同为 max effort 的情况下，Fable 5.1 完成一个 Intelligence Index 测试任务的成本是 3.76 美元，Fable 5 则是 3.14 美元。新模型即使已经享受缓存读取降价，仍然贵了约 20%。

主要原因不是单价。Fable 5.1 的 input 和 output 标价都没有变化，依然是每百万 token 10 美元和 50 美元。问题在于它生成了大约 1.7 倍的 output tokens，其中包括推理和最终回复。

模型变强了，也变得更能想、更能写。如果习惯性地把 effort 拉到最高，75% 的缓存折扣依然抵不过输出量的增长。

但 Lance Martin 分享的另一组数据，给出了完全不同的答案。

在 CursorBench 3.2 中，Fable 5.1 low 的得分是 66.2%，平均每个任务成本 2.90 美元；Fable 5 high 得分 66.5%，每任务成本 8.77 美元。两者表现接近，前者成本只有后者的三分之一左右。

下面这张图把不同模型、不同 effort 的位置放在了一起。横轴是反过来的，越往右越便宜，越往上分数越高。

CursorBench 3.2 不同模型与 effort 等级的分数及平均任务成本

图里还有一组对我更有现实意义的对比：

模型	CursorBench 分数	平均任务成本
Fable 5.1 low	66.2%	$2.90
Opus 4.8 max	62.3%	$5.77
Opus 4.8 high	58.0%	$3.15

在这组测试中，Fable 5.1 low 比 Opus 4.8 max 高 3.9 个百分点，成本却低约 50%；与 Opus 4.8 high 相比，它高出 8.2 个百分点，成本还略低。

当然，一张 benchmark 不能证明 Fable 5.1 low 可以全面替代 Opus 4.8。CursorBench 测试的是来自真实 Cursor 会话的模糊、多文件编程任务，换成写作、产品讨论或其他类型的任务，结果可能不同。Cursor 官方也明确提醒，小幅分数差异未必具有统计意义。

但它至少推翻了一个很自然的使用习惯：最强的模型必须搭配最高的 effort 才值得用。

Fable 5.1 真正值得研究的成本变化，也许不是缓存便宜了多少，而是以前需要 high 甚至 max 才能完成的任务，现在能否用 medium 或 low 完成。

缓存降价，不等于 Max 额度增加

这次官方宣布的 75% 降价，是很具体的一项 API 价格调整：Fable 5 的 cache read 是每百万 token 1 美元，Fable 5.1 降到了 0.25 美元。Input、output 和 cache write 的价格都没有变化。

它对 API 用户很重要。Agent 每次调用工具后，都要重新读取 system prompt、工具定义和前面的对话。一段长任务可能反复读取同一批上下文几十次，因此 cache read 往往是 agent loop 中最大的成本之一。

但 Max 套餐走的不是同一套公开计价方式。

Claude Code 负责人 Boris Cherny 在一条回复中说：

We actually didn’t roll this out for Pro, Max, and Teams because subscriptions already have discounted cache reads.

也就是说，这次调整没有给 Pro、Max 和 Team 订阅额外增加一轮缓存优惠，因为套餐里的 cache read 原本就已经按折扣处理（但是具体的折扣细节并未披露）。

Anthropic 的套餐帮助文档也写得很清楚：Fable 5 和 5.1 在 Max 中共用同一套规则，最多可以占每周总额度的 50%，并且会比其他 Claude 模型更快消耗套餐额度。达到 Fable 上限后，要么切换模型，要么开始使用额外的 usage credits。

提到 Anthropic 家的套餐，还有一个让我必须再次吐槽的点：

我昨天才注意到，$200 Max 套餐所说的 20x，并不是承诺整周额度都是 Pro 套餐的 20 倍。Anthropic 的正式表述是 20 times more usage per session，而这个倍数明确限定在每五小时的 session 上。周额度属于另一套独立 cap，官方也没有公开 Max 5x 与 Max 20x 的固定周额度比例。

我看到的用户测算和实际反馈是，$200 套餐的五小时额度大约是$100 套餐的 4 倍，但每周总量可能只有约 2 倍，甚至略低。这个精确比例不是 Anthropic 公布的固定规则，所以不能当作官方数字。不过，仅仅看官方文字已经足够确认一件事：20x 不是整周 20x。

对于像我这样很少撞到五小时 session 上限、却经常提前耗尽周额度的重度用户，$200 套餐多出来的瞬时吞吐量并不能解决真正的瓶颈。有点像水龙头变粗了，但水箱并没有同比变大。

我现在怎样分配模型

在弄清楚这些区别之前，我已经被额度逼着形成了一套模型分工：

复杂任务的 brainstorm、spec 和 plan，用 Fable medium。这个阶段需要模型理解模糊问题、发现遗漏和做关键取舍，能力差一点可能导致后面整条路径走错；
相对简单的任务，以及已经有明确 plan 的执行阶段，用 Opus 4.8 high。执行时目标、边界和验证方式都已经确定，不一定需要最强模型重新思考一遍；
暂时不用 Opus 5 做默认模型。至少在我的任务里，它增加的输出和过程描述没有转化成同等价值，额度消耗反而更严重；

这套分工的逻辑是：把贵模型留给高杠杆决策，把执行交给便宜、稳定且我已经熟悉的模型。

CursorBench 的数据让我准备再增加一组测试：拿几类原本交给 Opus 4.8 high 的执行任务，改用 Fable 5.1 low，比较完成质量、返工次数和额度消耗。

当然，这里不能只比较一次回复用了多少 token。便宜的模型如果需要反复纠正三次，最终成本未必低；更贵的模型如果一次就把任务做对，按“每个完成任务的成本”计算可能反而更便宜。

Anthropic 最新的成本与智能优化指南也一直强调这个口径：不要只看每百万 token 的价目表，要看 cost per completed task。

先调 effort，再考虑换模型

Fable 5.1 的 effort 是控制能力、延迟和成本最直接的参数。官方默认值是 high，建议先用自己的任务测试 low、medium、high、xhigh 和 max，而不是沿用 Fable 5 时期的经验，因为同名档位在两代模型上并不对应相同的思考量。

官方给出的方向很明确：Fable 5.1 在 medium 下大致可以用更低成本达到 Fable 5 的表现；low 在一些任务中也能以更低的每任务成本超过 Opus 或 Sonnet。

我的建议不会是所有任务一律改成 low，而是按错误代价分配 effort：

任务边界清晰、结果容易检查时，从 low 或 medium 开始；
需要做架构取舍、复杂规划或跨领域判断时，用 high；
只有自己的测试证明 xhigh 或 max 能明显减少失败、返工或人工检查的特定场景时，才长期使用；
如果任务有自动测试或明确 verifier，可以先用 low 执行，失败后再用 high 重跑。Anthropic 的测试中，这种做法在维持近似通过率的同时，把成本降到了约一半。

Fable 5.1 还有一个很实用的变化：可以在同一段对话中途切换 effort，而不会破坏 prompt cache。一次复杂任务不必从头到尾保持 xhigh。规划阶段升高，批量执行时降低，遇到真正困难的节点再升回来。

不过 low effort 下有一个明确风险：官方发现它比 Fable 5 更不愿意主动调用搜索和检索工具，更容易凭记忆回答。涉及最新事实、必须核对来源或陌生技术时，要明确要求搜索，或者只把那一个 turn 临时升到更高 effort。

Prompt 技术债，以及那些无谓的消耗

Lance 给出的另一条建议是简化 prompt，删除验证流程、强调用语、草稿辅助框架、过时的少样本示例和互相矛盾的规则。

这件事对我很有触动。

2024 年，我写过几篇关于 prompt engineering 的文章。那时候大家还在研究怎样写 Mega-Prompt、怎样要求模型一步一步思考。很多做法在当时确实有效。模型能力有限，我们只能在 prompt 里搭脚手架，提醒它规划、检查和修正。

两年后的官方建议正在发生反转。

新模型已经把不少旧技巧训练进了自身能力。Prompt 里继续保留“检查两遍”“尽可能详尽”“严格执行下面六个步骤”之类的要求，模型可能真的逐字执行：多调用几轮工具，多写一遍总结，再做一次没有必要的复查。质量没有提高，额度却被认真地花掉了。

Anthropic 对一组客服任务做过测试。为旧模型编写的 prompt 用在新模型上，准确率没有变化，每个任务的成本却高了 36%。运行 prompt audit 后，成本比未经审计的版本下降 14%，准确率还从 92% 提高到了 97%。另一组模型迁移测试也节省了 14%。

Claude Code 内置的 Claude API skill 提供了一个命令：

1	/claude-api prompt-audit

它会检查项目中的 prompts、skills 和请求代码，找出为旧模型遗留的设置、重复流程和冲突规则，并以 diff 形式提出修改，而不是直接重写全部内容。

这也是我现在对 prompt engineering 的新理解：Prompt 不是写完就永久有效的资产。它依赖具体模型，也会随着模型升级积累技术债。每次更换主力模型，都应该重新审计一次。

少写、少绕、少重做

除了 effort 和 prompt audit，Fable 5.1 的官方 prompting 指南里还有几项很朴素的省钱方法。

要求更短的输出。 Anthropic 的一组测试中，明确要求更短的回答减少了 39% 的 output tokens，总成本下降 14%，没有测到质量损失。Fable 的 output 价格是每百万 token 50 美元，少写无用过程比在 input 上抠几句提示词更直接。

小修改不要重写整份文件。 Fable 5.1 比 Fable 5 更容易为了一个局部改动重写全文。可以直接告诉它，在不影响结果时优先采用小修改。对于代码和长文，这同时减少输出 token、等待时间和无意义 diff。

把互不依赖的工具调用并行执行。 在 coding 和 computer-use loop 中，Fable 5.1 有时会把本可并行的动作拆成多个 turn。每多一个 turn，都会重新携带对话上下文，也增加一次模型输出。官方建议明确要求它先判断哪些信息彼此独立，再在同一轮全部请求。

不要在推理时完整起草一次，再在最终回复里重写一次。 xhigh 和 max 尤其容易在长文或大段代码任务中这样做。Reasoning 应该用来理解、检查资料和确定结构，最终交付物只需要完整写一次。

保持对话历史仅追加写入。 不要在每次请求前修改旧消息、替换 system prompt 或重写 tools。这样的变化会让 prompt cache 从修改点重新开始，也可能使 Fable 5.1 的 thinking blocks 失效。现在 effort 可以在对话中途单独调整，更没有必要为了改档位重建历史。

这些方法对 API 用户的节省可以直接算成美元。对于 Max 用户，Anthropic 没有公开“多少 token 等于 1% 周额度”的完整公式，不能宣称每项优化都会按同样比例增加可用时间。但 effort、输出长度、工具轮数和返工次数都在减少模型实际完成的工作量，至少比期待一次 API cache 降价自动扩大周额度更可控。

API 用户还能多做几步

如果使用 Claude API，缓存仍然是这次降价后最大的优化空间。

Anthropic 公布的生产数据中，agent loop 的 input 有 84% 来自 cache read，中位以上的优秀实现可以达到 94%。低于约 80% 时，通常应该检查是不是 system prompt、工具定义或早期消息在不同请求之间发生了变化。

官方测试里，prompt caching 让不同 agent loop 的成本降低到原来的约 1/2.7 至 1/5.3；一组小型任务分流测试节省了 83%。这才是“缓存读取降低 75%”真正能产生作用的场景：同一段长上下文在几十轮工具调用里反复被读取。

还可以进一步做几件事：

在 Claude Console 观察 prompt cache hit rate；
实时 agent loop 保持默认 5 分钟 cache；大量人工停顿集中在 5 分钟到 1 小时时，再评估 1 小时 cache 是否划算；
不要求即时返回的任务使用 Batch API，input、output 和 cached tokens 都可以再打五折；
用 /claude-api migrate 检查模型 ID、参数和 effort 迁移问题；
Lance 还建议运行 /claude-api cost-optimize 诊断缓存配置；

所以，如果你和我一样，真正的瓶颈是 Max 周额度，而不是五小时 session，那么把所有任务换成 Fable 5.1 并不会自动解决问题。我的下一步会是：

保留 Fable medium 处理 brainstorm、spec 和 plan；
从几类结果容易验证的执行任务开始，测试 Fable 5.1 low 能否替代 Opus 4.8 high；
只有测试证明能明显减少错误或返工的任务，才使用 high、xhigh 或 max；
清理 prompts 和 skills 里为旧模型添加的重复验证、手工草稿区与冲突规则；
对长输出明确限制篇幅，对局部修改明确要求定向修改，对独立工具调用要求并行；
一周后比较的不是“用了多少 Fable”，而是每类任务的完成质量、返工次数，以及周额度实际消耗；

Fable 5.1 确实更强，也确实可以更便宜。但前提是别再用 Fable 5 的 effort、旧模型的 prompt，以及“最难的模型就该开最高档”这套习惯去使用它。

否则，缓存读取省下来的钱，很可能又被更多 reasoning、更多输出和更多工具轮次花回去了。