📰 AI 资讯

Fable 5 访问权限再延一周，但Anthropic 的“黑心账本”越来越藏不住了

2026-07-14 11:03

GPT-5.6 刚刚落地的当口，Anthropic 又给 Claude Fable 5 的使用期按了一次“续命键”。7 月 19 日，这是付费用户眼下能看到的最后期限。在此之前，Pro、Max、Team 和 Enterprise 高级席位的订阅者，仍可在现有额度内免费调用这款能力最强的 Claude 模型，无需额外付费。<h2 data-type="heading" data-id="heading0">永远够不到的胡萝卜</h2>这已是 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，价格战对谁都没有好处。当然，这终究只是基于公开信息的推演，但无论如何结果都一样——消费者永远是被动的，是唯一没有坐上牌桌的那一方。<h2 data-type="heading" data-id="heading1">Fable 5 的 API 价格，接近 GPT-5.6 的三倍</h2><a href="https://mp.weixin.qq.com/s/b0iYCLc--GRBNj7AEblF9A" title data-type="link">上周五，OpenAI正式发布了GPT-5.6模型系列</a>——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 更好用。<h2 data-type="heading" data-id="heading2">你订阅的钱，烧在了看不见的地方</h2>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 <a href="https://mp.weixin.qq.com/s/yMUrsZ6ha1BBtQyIcaroCw" title data-type="link">80%的系统提示词</a>，但同一个模型，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 个工具。<h3 data-type="heading" data-id="heading3">缓存的经济账</h3>提示词缓存可以降低后续读取成本，但不会消除 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，第二次重写了 368

🔗 查看原文 ↗

← 返回资讯列表