Fable 5 开始按量计费：每个浪费的 token 都成了账单项

7 月 13 日起，Claude Fable 5 从套餐额度切换到按量计费：每百万 token 输入 $10、输出 $50。最烧钱的习惯？代理本该读 4 个文件，却读了 20 个。

你能租到的最强编程模型，马上要开始按 token 收费了。Claude Fable 5——6 月 9 日发布，随后因出口管制审查下线三周，7 月 1 日重新全球部署——目前包含在 Pro、Max 和 Team 套餐里，上限为每周用量的 50%。截至发稿，这段包含期将于 7 月 12 日结束。从 7 月 13 日起，Fable 5 通过用量额度按 API 费率计费：每百万输入 token $10，每百万输出 token $50——是 Opus 4.8 的两倍，也是 Anthropic 有史以来对公众开放的最贵模型。额度是同一个池子，Claude.ai 和 Claude Code 共享。

所以这周每个在 Claude Code 里跑 Fable 5 的团队面对的问题不是”值不值”——按多数评测它是当前最强的软件工程模型。问题是：你付的钱里，多少花在了真正的工作上，多少花在了代理读那些根本不需要的文件上？

我们三周前写过：上下文膨胀烧的是配额。换到 Fable 5，同样的膨胀烧的是美元——而且是市面上最高的单价。

Fable 5 惩罚臃肿上下文的三种方式

费率本身

每百万输入 token $10，意味着代理塞进上下文的每个 token 都按 Opus 4.8 的 2 倍、Sonnet 5 首发价的 5 倍计费。不是模型变低效了——是你的习惯变贵了。grep 一个词然后把所有匹配都读一遍的代理从来都浪费；在 Fable 5 上，这份浪费的价签多了一个零。

Tokenizer 税

Fable 5 用的是 Anthropic 较新的 tokenizer（与 Opus 4.7+ 相同），同样的文本最多会多产生 35% 的 token。同一个文件、同一段提示、同一段粘贴的堆栈跟踪——比旧模型消耗更多 token，然后才轮到更高的费率。费率 × token 膨胀是复合的：过去花 $X 输入的内容，现在可能远超 2X。每次多余的文件读取都被征了两道税。

1M 上下文的诱惑

Fable 5 的上下文窗口默认就是 100 万 token——不用申请 beta，长上下文也不加价。这正是陷阱所在。一百万 token 装得下大多数中型仓库，于是最省事的接法就是”全部倒进去，让模型自己整理”。算一下账：一次满窗口请求，在模型输出任何一个 token 之前就是 $10 的输入费用。关于多轮代理会话的报道给过数字：满上下文每轮重发、不做缓存的十轮对话，光输入就 $100+；用提示缓存约 $21.50（约 $12.50 的缓存写入，之后读取约每百万 $1）。缓存帮助很大。但缓存一个臃肿的上下文，仍然是在付钱存储和重读噪声。最便宜的 token 是你从没加载过的那个。

解法不是更便宜的模型，是更小的上下文

这周流传的标准建议是模型分流：把 Fable 5 留给规划和最难的问题，批量编码推给费率只有五分之一的 Sonnet 5。这个建议是对的——照做。但分流决定的是你烧哪个表，不是烧多少。一个读 20 个文件才改 4 个的代理，在 Sonnet 上浪费 80% 的上下文，和在 Fable 上一模一样。倍率变了，漏洞没变。

漏洞在检索。代理靠关键词搜索或向量相似度找代码——这些工具为召回率优化，把一切沾边的都返回。而在代码里，真正重要的关系不是词面相似，是依赖边。OrderService.place_order() 调用一个 repository，后者用到一个缓存策略。这些文件构成一条链。关键词搜索找不到这条链；依赖图就是这条链。（完整入门见上一篇。）

基准数字，按 Fable 5 费率折算

Coograph 在仓库里附带一个已提交的基准测试——单个固定任务（“给 OrderService.place_order() 加缓存”）跑在单个已提交的 fixture（bench/fixtures/sample-app/）上，两者都在版本库里，任何人都能复跑。在这个任务上：

• 朴素 grep + 读取所有匹配文件： 20 个文件，约 4,764 输入 token，21 次工具调用。
• 图最小上下文查询： 4 个文件，约 969 输入 token，5 次工具调用。

也就是在一个有代表性的重构任务上 token 减少约 80%、工具调用减少约 4 倍——只是一个任务，不是普适保证；节省幅度随仓库规模和改动聚焦程度变化。

现在套上 Fable 5 的价格。按每百万输入 token $10 计算，这个小任务走关键词检索约 $0.048 输入费用，走依赖图约 $0.010——这是示意性算术，且基准的 token 数是在 Fable 的 tokenizer 之前测的，在 Fable 上两边都会膨胀最多约 35%，但比例不变。在小 fixture 上是几分之一美分。但 fixture 很小，而机制是线性的：把同样 80% 的浪费放大到真实仓库——一个任务动辄拉进数万上下文 token——再乘以团队每周跑的任务数，这道差距决定了 Fable 5 到底是四舍五入的零头，还是工具账单上最大的一行。

而在 7 月 12 日之前，同样的算术烧的不是卡而是钟：Fable 5 从每周限额 50% 的包含额度里扣，所以每个任务少 80% 的 token，直接等于在上限把你周中掐断之前多跑几个 Fable 任务。

实际用起来是什么样

Coograph 是开源、MIT 许可的解析器和图引擎。它用 tree-sitter 解析你的代码库（Python、TypeScript、JavaScript、Go、Rust、Java、C#、Ruby 等，另有正则兜底），产出一个本地 SQLite 文件——.code-graph/graph.db——永远不离开你的机器。你的代理通过 MCP 工具（get_minimal_context、query_graph）查询它而不是 grep，一次拿到完整依赖链。git 钩子在每次提交时只重新解析变更的文件。

安装只要几分钟：把 Coograph 克隆为同级目录，在 Claude Code（或 Copilot、Cursor、Windsurf、Codex CLI、OpenCode、Aider、Cline）里运行 /coograph-init，构建图。它是上下文层，不是代理替代品——而且模型无关，这正是这个月的关键：无论任务路由给 Fable 5、Opus 4.8 还是 Sonnet 5，图都会削减你喂进去的东西。

Fable 5 值这个价——对那些干活的 token 而言。花在重读代理根本不需要的文件上的 token，在套餐限额时代就是死重，从 7 月 13 日起则是每百万 $10 的死重。用入门指南生成你的第一张图，在代码图页面看看里面有什么，或者如果团队需要驻场集成，聊聊 Coograph Pro。基准已提交。在电表启动之前，自己复跑一遍。