GPT-5.6 刚刚落地的当口，Anthropic 又给 Claude Fable 5 的使用期按了一次“续命键”。
7 月 19 日，这是付费用户眼下能看到的最后期限。在此之前，Pro、Max、Team 和 Enterprise 高级席位的订阅者，仍可在现有额度内免费调用这款能力最强的 Claude 模型，无需额外付费。
永远够不到的胡萝卜
这已是 Anthropic 第二次调整时间线。最初的活动截止日定在 7 月 7 日，随后被推至 7 月 12 日，如今又在旧节点到来前再度延长一周。
Anthropic 在支持文档中表示：“我们已将这项推广活动延长至 2026 年 7 月 19 日太平洋时间晚上 11 点 59 分 59 秒。”
与此同时，Claude Code 每周使用额度提高 50%的活动，也被延长至同一时间。
在活动期间，付费用户可以使用 Fable 5 消耗最多 50%的每周订阅额度，无需支付额外费用。用户不需要领取或手动激活这项权益，Fable 5 与其他 Claude 模型共用同一个每周使用额度池。不过，Anthropic 也提醒，Fable 5 消耗每周额度的速度会比其他 Claude 模型更快。
但接二连三地延期，很难不让人读出几分挽留的意味。大家很快把这种延期变成了一个“永远够不到的胡萝卜”的梗儿：Fable 5 仍然挂在所有付费计划里，但每当终点临近，胡萝卜就又被往前挪了一截。
而对 Claude 和 Claude Code 的重度用户来说，这种体验已经逐渐变成一种循环：额度耗尽，等待重置；截止日期临近，等待延期；新规则公布后，再重新计算自己还能用多久。
如果联系这段时间的一些动作来看，Anthropic 也许有一个很隐蔽的策略。
在此之前，OpenAI 对 5.6 的发布进行了多次预热。并且过去一个月里，已经有多篇新闻报道讨论各家 AI 厂商之间可能爆发的价格战，以及由此可能带来的后果。
Fable 5 发布后，Anthropic 发言人 Reem Ateyeh 在 7 月 9 日曾表示，只要算力允许，Fable 就会重新回到订阅套餐里，并希望“as quickly as we can”，即“尽可能快地”做到这一点。不过，Anthropic 没有给出具体时间，也没有说明怎样才算“容量足够”。
这给公司留下了充足的解释空间——比如等到 GPT-5.6 正式发布的那一刻，他们可能突然“找到”了足够的算力；又或者等 5.6 抢走了足够多的用户以后，再重新把 Fable 放回订阅套餐。
结合起来看，也许有这么一种可能：Anthropic 可能正在有意推动一种新的行业模式，让未来最先进的 SOTA 模型不再包含在订阅套餐里，而是只通过 API 的方式提供。
这自然也会给 OpenAI 留下同样的操作空间——一旦这种做法成为行业标准，两家公司都能避开价格战，维持更高的利润。双方都在推进可能达到 1 万亿美元估值的 IPO，价格战对谁都没有好处。当然，这终究只是基于公开信息的推演，但无论如何结果都一样——消费者永远是被动的，是唯一没有坐上牌桌的那一方。
Fable 5 的 API 价格，接近 GPT-5.6 的三倍
上周五，OpenAI正式发布了GPT-5.6模型系列——Sol、Terra 和 Luna，进一步拉低了 AI 编程的成本。
OpenAI 表示，他们“训练 GPT-5.6，让它能够从每个 token 中完成更多有用工作”。在 DeepSWE 基准测试中，Sol Max 以每项任务 8.39 美元的成本拿下 73%的最高分。相比之下，Fable 得分为 70%，每项任务成本接近 22 美元。也就是说，Sol Max 不仅得分更高，成本还降低了约 62%。
在 Agents’ Last Exam 上，Sol 创下了 53.6 分的新高。这是一项新近开发的基准测试，用于评估 55 个领域中的长时间专业工作流程。Sol 比采用自适应推理的 Fable 5 高出 13 分。即使只使用 Medium 推理强度，它也比 Fable 5 高出 11 分，而预计成本大约只有后者的四分之一。
这种效率也延伸到了较小的模型上，而较小模型对于让智能变得更普及、更便宜非常重要。GPT-5.6 Terra 和 Luna 在大约十六分之一成本的情况下，性能仍然超过了 Fable 5。
而在 API 成本上，差距进一步拉大。在几乎相同的得分下，Fable 5 花了 3,771.84 美元，GPT-5.6 Sol 仅需约 1,400 美元——Fable 5 的成本接近 Sol 的三倍。
性能、成本和订阅政策三者被摆在一起，很快引来了开发者对 Anthropic 的调侃。开发者 Corey 在评价 GPT-5.6 时写道：“我真的搞不懂 OpenAI 对 GPT-5.6 的策略。我找不到它涨价 50%的日期，也找不到它被移出订阅套餐的日期。更奇怪的是，OpenAI 员工的说法居然还和官方文档一致。很明显，这里面一定有什么问题。”
这段话通篇都是反讽，明显看不惯 Anthropic 近期围绕 Fable 5 设置的一系列复杂安排：先给出限时价格，再预告未来涨价；临近截止日期后，又一次次向后延期。
一名 OpenAI 员工随后回复称，用户可以把自己购买的套餐额度全部用于 GPT-5.6，价格也会维持不变。Corey 接着开玩笑说，OpenAI 应该招聘一位“VP of rug pulling”——专门负责突然收回权益、改变规则的副总裁。
在早期测试阶段，用户体验上也存在差异。中间有一段时间，由于监管问题，Fable 和 GPT-5.6 都被暂时撤回过。后来 Fable 率先恢复了访问权限。原本以为有 Fable 可用已经足够，但一些团队仍然因为用不上 GPT-5.6 而感到沮丧。等到 GPT-5.6 重新开放后，他们几乎立刻得出了结论：在日常工作里，GPT-5.6 就是比 Fable 更好用。
你订阅的钱，烧在了看不见的地方
Fable 5 反复延期，Anthropic 给的解释是“算力不足”。那算力都去哪了？把 Claude Code 和开源替代品 OpenCode 放在同一台机器、同一个模型、同一组任务上对比，会发现一个有意思的事情：Anthropic 自己的工具，是吞 token 最狠的那个。
首先，Anthropic 的工具本身有一层固定开销。 这会让 Claude Code 在处理用户提示之前，已经在烧你的额度了。
一项研究表明，让两个工具都只完成一个最简单的任务，提示词为“Reply with exactly: OK”，只有 22 个字符，没有任何代码需要阅读、没有任何文件需要修改。并隔离了基础开销：使用全新的配置目录，不接入 MCP 服务器，不加载用户设置和记忆；工作区保持为空，不包含任何指令文件；同时绕过权限检查。随后的测试每次只增加一个变量。
测试任务本身只有 22 个字符，但在用户提示词送达模型前，Claude Code 已经加载了约 32,800 个 token，包括系统提示词、27 个工具定义和自动注入的提醒内容。OpenCode 的首轮负载约为 6,900 个 token，只有前者的五分之一左右。
其中，Claude Code 约 24,000 个 token 都花在工具定义上。它提供的 27 个工具，不仅包括核心编程工具，还包含一整套后台智能体和任务编排能力，从 CronCreate、Monitor 到 Task 系列，再到 worktree 管理和推送通知。
即使关闭全部工具，它的系统提示词仍约有 6,500 个 token，是 OpenCode 的三倍以上。
这 32,800 个 token 全部是 Anthropic 自己塞进去的“平台开销”——你为它付了钱，但它没有为你完成任何实际工作。
把模型从 Sonnet 4.5 换成 Fable 5 后，差距缩小到约 3.3 倍——因为 Anthropic 删除了 Fable 5 80%的系统提示词，但同一个模型，Claude Code 就是比开源工具更贵，倍数虽然不同，资源消耗依然很大。
在一个只用一次工具的任务的条件下，如果要求两个 harness 读取一个文件并生成摘要，两者都正确完成了任务。Claude Code 共发出 6 次 HTTP 请求，累计计量输入约 199000 个 token。OpenCode 发出 4 次请求，累计约 41000 个 token，另外还调用了一次 Haiku 模型，用于生成会话标题。
其中大部分 token 属于缓存读取，价格只有普通输入 token 的十分之一。不过，有三类开销始终会随负载规模增长：第一轮的缓存写入、每一轮的缓存读取，以及上下文窗口占用。最后一项不会因为缓存优惠而下降。
33000 个 token 的基础开销意味着，在任何代码进入对话之前，每一轮请求一开始就已经占用了 20 万上下文窗口的大约六分之一。
多步骤任务：差距反而缩小。要求是一套“编写、运行、测试、修复”循环，结果与基础开销给人的直觉正好相反。
Claude Code 把整个任务压缩进了一轮并行工具调用，其中包括两次文件写入和两次脚本执行。
OpenCode 每一轮只调用一个工具，因此一共进行了 9 轮。
基础负载会在每次请求中重新发送，所以请求次数会直接放大基础成本。OpenCode 约 7000 个 token 的基础负载支付了 9 次，Claude Code 约 33000 个 token 的基础负载支付了 3 次，最终两者总量反而接近。
整个任务的输入量，大致可以理解为：基础负载 × 请求次数 + 对话历史增长。因此，一个基础负载很大、但擅长批量调用工具的 harness，和一个基础负载较小、却将工具调用完全串行化的 harness，最终可能花掉差不多的 token。
其中有四个最明显的 token 放大器。
一份 72KB 的 AGENTS.md 或 CLAUDE.md，会让每次请求额外增加约 20000 个 token。OpenCode 的单次计量从 13152 升到 33336，Claude Code 则从 39005 升到 59243。
每接入一个小型 MCP 服务器，每次请求还会增加约 1000 到 1400 个 token。接入 5 个后，Claude Code 增加了 4900 个 token，OpenCode 增加了 6967 个 token，工具数量分别从 27 个增加到 69 个和从 10 个增加到 52 个。
框架模板也会被重复携带。BMAD 这类故事驱动的工作流框架，会把一条斜杠命令展开成大型提示词模板，其中包含角色设定、执行协议和检查清单。一个约 2100 个 token 的模板，如果会话包含 9 次请求，就会被重复发送 9 次，实际成本接近模板大小的 9 倍。因此，框架带来的额外成本，可以粗略理解为“模板大小乘以请求次数”，而且这部分消耗还会叠加在前面所有开销之上。
而子智能体更是成本放大器，是总消耗增长最快的一项。 Hacker News 上一位用户分享了他的经历：给 Claude Code 一个稍大的任务，它立刻启动了 7 个子智能体，预算还没等任何一个子智能体完成工作就烧光了。同样的任务让主智能体顺序执行，完全没问题。
数据也证明了这一点。一个直接完成时消耗 121,000 个 token 的任务，分散给两个子智能体后飙升至 513,000 个 token——4.2 倍。父智能体只会读取每个子智能体返回的结果，真正推高成本的原因在于：每个子智能体都是一个全新的 agent，会在自己的每一轮请求中重新读取启动负载。两个子智能体各自运行多轮后，就会给整个会话额外增加多次完整基线请求。
OpenCode 在这方面的设计明显更轻。它的子智能体请求只携带一个 1379 字符的系统提示词和 5 个工具。
缓存的经济账
提示词缓存可以降低后续读取成本，但不会消除 Claude Code 与 OpenCode 之间的开销差异。
两个 harness 都正确设置了缓存断点。请求负载第一次写入缓存时，5 分钟 TTL 档位按基础价格的 1.25 倍收费；之后再次读取，只需要支付普通输入价格的十分之一。
但仍有三类成本不会消失。
第一是缓存写入。只要停顿超过 TTL，整套前缀就要重新写入。思考五分钟、开个会，或者吃顿午饭回来，都可能重新按写入价格计费。
第二是缓存读取次数。子智能体并行、串行工具调用越多，请求次数越多，缓存读取成本也会随之增加。
第三是上下文窗口占用。缓存只能降低价格，无法减少上下文长度。一个 85000 个 token 的启动负载，每次请求都会占掉 200000 个 token 窗口的 40%以上，留给真实代码的空间随之减少，也会更早触发上下文压缩，再额外消耗 token 生成摘要。
真正决定缓存是否省钱的是前缀稳定性。缓存只有在请求前缀保持稳定时才有效。测试人员因此对数据集中每一次请求的工具数组和系统提示块进行了哈希比对。
OpenCode 在所有请求和所有运行中，都保持了逐字节完全一致的前缀。三次独立会话里的工具内容、系统提示和消息内容完全相同，重复运行时没有再次写入缓存 token，全部直接读取已有缓存。在包含 9 次请求的多步骤编程任务中，也始终使用同一个稳定前缀。
Claude Code 则不同。每个会话都会出现三类请求：预热探测、主会话请求和子智能体请求。每一类请求都有自己的前缀，也要建立独立缓存。即使在同一个工作区里，不同会话之间的系统提示内容也会变化，第一条消息中注入的脚手架也不完全一致。
这种差异最终直接反映在缓存写入量上。
在同一个文件摘要任务中，Claude Code 经过 5 次请求，共写入 53839 个缓存 token，其中一次是在任务进行到一半时，完整重写了约 43000 个 token 的前缀。OpenCode 只写入了 1003 个 token。
测试随后重复运行相同任务，以确认这不是偶发现象。结果显示，大规模中途重写再次出现：第一次重写了 43342 个 token，第二次重写了 36899 个 token。第三次因为缓存已经充分预热，才几乎没有发生新的写入。能够完整计量的所有 Sonnet 会话中，OpenCode 都没有出现过中途重写整个前缀的情况。
换成 Claude Fable 5 后，这种现象仍然存在。Claude Code 再次在任务中途完整重写前缀，这次写入了 50053 个 token，同时缓存读取量为零。与 OpenCode 相比，缓存写入差距达到 52 倍，Sonnet 上的差距则为 54 倍。
Fable 5 上的多步骤任务更夸张，单次中途重写达到 85686 个 token。两个模型家族都出现了同样的模式。OpenCode 在所有 Fable 测试中基本保持逐字节稳定，只出现过一次约 6000 个 token 的写入；Claude Code 则反复重写 37000 到 86000 个 token。
根据缓存是否已经预热，Claude Code 在相同任务中的缓存写入量，是 OpenCode 的 5.9 倍到 54 倍。而缓存写入本身还要支付溢价：5 分钟 TTL 按基础价格的 1.25 倍收费，1 小时 TTL 则按 2 倍收费。
这里仍需保留一个归因上的限制。单次任务中途出现缓存未命中，理论上也可能是本地网关清除了缓存，不一定完全来自 harness 改变缓存断点。但这种现象在多次运行中都能复现，因此更可能是 Claude Code 的系统性行为。更重要的是，它的请求前缀确实不稳定，而且这种变化在进入网关前就能从捕获的原始字节中看到。
如果同一个模型在 Claude Code 里运行时，额度仪表盘快速上涨，而在 OpenCode 里相对平稳，最可能的原因就在这里：Claude Code 的前缀更大，一个会话中存在更多种不同前缀，还会更频繁地重新写入这些前缀。再叠加子智能体并行，消耗还会继续放大。
总的来说，这意味着什么？ 用户花同样的订阅费，用 Claude Code 能完成的实际任务，可能只有 OpenCode 的几分之一。剩下的钱全烧在了 Anthropic 自己塞进去的脚手架、工具定义和重复缓存写入上。
那 Anthropic 会告诉用户这些吗？不会。
用户看到的只是“额度用完了”、“该等重置了”。但额度到底消耗在了哪里？有多少是真正完成任务，有多少是 Anthropic 自己的脚手架和缓存重写在烧钱？这套设计的精妙之处在于：普通用户根本分不清。
最后，关于质量。 一个可能是“花得多是因为做得好”。但测试结果显示：两个工具在所有计分任务上都正确完成，输出质量没有差别。在这个前提下，token 差距就是相同结果的成本差距。
这些 token 被消耗了，但不是为了更好的结果。它们去了 Anthropic 的账单。
参考链接：
https://www.youtube.com/watch?v=IyoTJHLmClo&t=2029s
https://systima.ai/blog/claude-code-vs-opencode-token-overhead
