最近 Claude 出了新旗舰 Fable 5。官方文档里写了一句话，把不少人看慌了：新分词器（你可以理解成"把文字切成计费小块的那把尺子"）会让同样的内容多耗大约 30% 的 token，定价还比上一代贵。
普通人就关心一件事：我还是写那份周报、回那条消息，换新模型要多花多少钱？
我把这事真测了。30 个上班族每天在干的活，新旗舰 Fable 5 和上一代主力 Opus 4.8 各跑一遍。结论先甩给你，三句话：
- 钱上，基本没差。 新模型不但没多烧 30%，反而省了 0.5%。
- 但它多收你三成时间。 同样一句话，Fable 5 平均要 8.97 秒，Opus 4.8 只要 6.94 秒，慢了 29%。你天天用它回消息，会明显觉得它"墨迹"。
- 最反直觉的一条：决定你额度烧多快的，根本不是你选哪个模型。 模型之间差 0.5%，但你给它配的"隐形行李"轻重之间能差 2.6 倍。大家都在错误的地方省钱。
下面说我怎么测出来的，包括中间被打脸三次的过程——那才是最有意思的部分。
一、为什么测这个，而不是测那些工程师自嗨的指标
一开始我让两个 AI 互相出题：OpenAI 的 codex 出 5 个实验设计，Claude 来挑刺，再合成 Top 3。
结果第一轮出来的全是工程师自嗨：纯 JSON 输出测试、合成文本里捞针、token 延迟中位数……我看完只说了一句：这些跟普通用户的需求一个都不搭。三个候选全废。
然后我把评审标准改成一票否决：任务必须是普通人真在干的事——写周报、回消息、读合同、算账。标题得让完全不懂 AI 的人也想点开。再加一条：优先验证"官方吹的是不是真的""网友骂的是不是真的"。
Fable 5 官方那句"多烧 30%"，正好撞枪口上。就它了。
二、怎么跑的（跑之前把结论锁死，不给 AI 编数的机会）
30 个中文日常写作任务：产品经理周报、后端工程师周报、市场专员周报、招聘文案、发布会预告、给老板回消息……每个任务里塞 2-3 个必须写进去的事实点（比如周报必须包含"支付模块灰度上线覆盖 10% 用户"），200 字以内，机器逐条检查写没写到。
两个模型，同样的提示词，各跑一遍。
关键一步：跑之前我就把五种结局的措辞全写死了。 多烧 25%-35% 算"官方预告兑现"，超 35% 算"比官方还狠"，低于 25% 算"比传言温和"，负数算"反转"，数据不全有兜底条款。跑完直接查表对号入座——模型没有机会盯着结果现编一个好听的结论。
10 号晚上 22:37 在一台海外服务器上开跑（我自己掏钱的生产环境，光部署就翻了三次车，每个 bug 修完都进了代码库）。60 次调用（30 任务 × 2 模型），9 分钟跑完，零中断、零拒答、零报错。
中间有个小插曲挺有意思：自动脱敏扫描突然拦下一条数据——模型在"回消息"任务里自己编了一个 hr@某公司.com（已打码） 的邮箱，要被摘进公开数据时触发了隐私规则。处理办法是在源头打码（邮箱 → [邮箱已打码]）。因为这批数据要公开给读者下载对账，连虚构的邮箱都不让出现。
机检结果：Fable 5 事实点通过率 95.6%，Opus 4.8 是 93.3%。挺近的。
最抓马的是单题级别：设计师周报那道，Fable 5 三个事实点全过，Opus 4.8 同一道题全军覆没，0/3。不是没写出来，是按那把写死的尺子量，一项没达标。可"招聘文案-前端工程师"那道又恰好反过来，Opus 全过、Fable 失手。所以单题都是抓马，只有 30 题的总账才靠得住。
三、第一版结论写完，被一句话捅穿了
第一版总账出来：Fable 5 烧了 63,000 token，Opus 4.8 烧了 63,297——新模型反而省了 297 个，-0.5%。 官方说的 +30% 连影子都没有，正好命中我预注册的"反转"条款。
文章草稿都写好了。我自己回头看了一眼，只问了一句：你这张表的口径对吗？你不是用 -p（命令行单发模式）跑的吗？
就这一问，把整个测量体系捅穿了。
复查发现：63,000 这个数，只是"任务提示词 + 模型输出"的账面数。但命令行每一次调用，其实都背着一个隐形行李箱——系统提示词、工具说明书，全都要重新塞进上下文，每次都重新计费。账面数里一个字没算它。
我顺手去翻了自己更早跑的另一个实验（50 个任务的护栏测试，在我本地电脑上跑的），做了一次法证式复盘：
- 账面 26.3 万 token，真实流量 293 万——账面只占 18%。
- 每次调用背着 22,586 个 token 的行李，80 次调用刷出 238 万 token 的 cache 流量。
- 更扎心：那次我的 Claude Max 五小时额度窗口被烧掉了 75%，36 个任务就被卡停。我一直以为是新模型贵。真相是——行李占 82%，正事只占 18%。
我重新按完整口径核算这次实验（把行李按计费权重折算进去）：Fable 5 等效 205,581，Opus 4.8 等效 207,340，差 -0.8%。方向和账面一致，"反转"结论站得住——但有个前提：只在这台轻行李的服务器环境下成立。
这里有个值得记住的机制：官方说的 +30% 是真的，但它咬的是"同样内容被切成更多 token"。而行李（系统提示）恰恰就是每次调用都重复的"同样内容"。Fable 5 在输出侧写得更精炼，反而省了；但在行李侧，30% 才真正显形。我在本地那台重型环境实测到行李的读取量不对称地多了 22%，已经很接近官方那个数了。
一句话:官方没骗你，但那 30% 烧在哪，跟你想的不是一个地方。
四、顺藤摸瓜：那个"隐形行李"到底有多重，能不能减
既然行李才是大头，我干脆把它单独称了一下重。
我本地这台电脑，挂了 27 个插件 + 3 个 MCP 工具 + 全局配置。最简单的一次调用，背 44,951 token 的行李。
我第一反应是"删掉 MCP 工具能省"。结果实测直接打脸：3 个 MCP 工具加起来才占 164 token——新版工具改成按需加载了，说明书不再常驻。删了等于白删。
真凶是插件生态。27 个插件的子代理描述、技能列表，全部常驻在系统提示里。我禁掉 13 个低频插件后，降到 40,909，省了 9%。
再看那台裸机服务器（零插件、零 MCP）：17,319。
三档摆一起看：
| 环境 | 每次调用的行李 |
|---|---|
| 本地满配（27 插件 + MCP） | 44,951 |
| 本地禁掉 13 个低频插件 | 40,909 |
| 裸机服务器 | 17,319 |
最重和最轻，差 2.6 倍。
回头看模型之间那 0.5% 的差距——在 2.6 倍的环境差异面前，它就是个零头。
所以结论就一句：你额度烧得快慢，主要不取决于选哪个模型，取决于你给它配了多重的行李。先清行李，再挑模型。
五、发布前最后一关：另一个 AI 扮演"掏钱读者"，把我全文级别打脸
我没敢直接发。发布前让另一个模型扮演"挑剔的、掏了钱的读者"来审稿。它的判决是 needs_work——必须补洞才能发。三个问题，第一个直接是致命的：
"你标题喊'省了 0.5%'，可我问的是钱和会不会卡。你数据里 Fable 5 平均 8.97 秒、Opus 4.8 只要 6.94 秒，Fable 慢了 29%。我天天拿它回消息，同样额度下它更慢、单位时间产出更少——你为什么把这个对日常最致命的数字藏在 json 里，正文一个字不提，还敢说'基本打平'？评论区点开 json 一对账，当场就拆穿你这种选择性框架。"
它说得对。我之前满脑子都是"钱",把"慢"给漏了。对一个天天回消息的人来说，慢 29% 比省 0.5% 重要得多。这个洞必须补——所以你看到的这篇，开头第二条就是它。
另外两个问题，我在文章里诚实认了：
- "你这 -0.5% 是在 17,319 行李的裸机上测的，我电脑行李是 44,951。行李越重 Fable 越亏——你是不是专挑了对 Fable 最有利的环境？" → 我认：重型环境下两边差多少，不在这次的测量范围里，我的乐观结论不能往重行李环境外推。
- "30 题、单跑一次、方差都没算，95.6% 对 93.3% 这么近，会不会就是噪声？" → 我认："合格"只指通过事实点机检，这俩数近到我不敢替你拍板谁写得更准。
六、这对你（掏钱用 AI 的人）到底意味着什么
把没用的话剥掉，剩下这几条你能直接用：
- 写周报、回消息这类轻活，Fable 5 和 Opus 4.8 花的钱基本一样，别因为"新模型贵 30%"的传言不敢用。
- 但 Fable 5 明显更慢（慢 29%）。 你要是高频交互、追求手感，旧的反而更跟手；你要是不在乎多等两秒，那随意。
- 真想省额度，先别纠结模型，去清你的行李。 插件、常驻工具这些东西，比你换模型省下的多得多。我禁 13 个低频插件就省了 9%，比模型之间 0.5% 的差距大一个量级。
- 删 MCP 工具是无效操作（新版按需加载，才占 164 token），别在这上面费劲。要减就减常驻的插件。
诚实边界也一并交代清楚，免得你过度引申：这 30 个任务全是 200 字内的轻量中文写作，长文、写代码、深度推理这种重活不在测量范围；只跑了一次，没算方差；"合格"只看事实点、不评文风。原始数据（逐任务 CSV + 完整指标 JSON）我挂在文末了，每个数字你都能自己下载对账。
七、最后说点我自己的反思
这次最让我后背发凉的，不是数据，是我那套自以为很严的质量体系——数字对账、自动脱敏、预注册结论表——它们全都在检查"文章和实验记录对不对得上"，但没有任何一环在检查"实验记录和真实世界对不对得上"。
验证链是个内部闭环，没有闭到现实上。所以三次都是我这个用户先用肉眼看见问题（口径量错了、时间被漏了），系统才跟上。
预注册是把双刃剑：它防住了"看完数据现编结论"，但也把我设计那一刻的认知盲区给焊死了——我的结论表写的是"输出 token 对比"，跑完之后，系统永远不会自己跳出来说一句"等等，你这口径量错对象了"。
所以我往流程里加了两个新机制：发布前自动红队（就是上面那个"掏钱读者"三连问），以及成本类实验强制写口径声明——量的是什么、不含什么、已知盲区在哪，一个都不许省。
这篇文章本身，就是被这两个新机制拦下来、补完洞才发出来的。
原始数据（逐任务 CSV + 完整指标 JSON）已挂在文章页，可下载对账。文中每一个数字都能在实验记录里找到出处。