GPT-6 Astra 和 Fable 5.1 都是 $10/$50，60 轮 agent 循环的账单为什么差 39%

先回答标题。差的那 39%，全部出自 cache read 一行——agent 每一轮都要把系统提示和工具定义 重读一遍，这部分重复内容不按新输入计价、走缓存读取价：Astra 每百万 $1.00，Fable 5.1 是 $0.25。按 Technspire 的 Foundry 价格分析 给的 60 轮 agent 循环口径（900 万 cache read、18 万 cache write、12 万输出 token）推算， 一边 $17.25，一边 $10.50。这是依双方公开价目做的推算，不是我们的实测账单；价目采集时刻 截至 2026-09-05。

值得先把减法摆出来，因为它比百分比更有说服力：两家的输出价一模一样（12 万 × $50/M = $6.00）， 差额 $6.75 恰好等于 cache read 两项之差——$9.00 减 $2.25。也就是说，这两个「同价模型」在 agent 场景下的全部价格差异，就是一行你多半没在价目表首屏上看过的数字。

$10/$50 一样，为什么账单不一样

Astra 于 2026 年 9 月 3 日上架 Microsoft Foundry，标价与两天前的 Fable 5.1 逐字相同 （GPT-6 Astra in Foundry — Price sheet on Foundry, 3 September 2026）。 把同一组 workload 假设代进两张价目表，结果是这样：

第一行完全打平——如果你只用一次性调用来做选型评估，你会得出「两家一样贵」的结论， 而且这个结论在你自己的测试里是对的。裂缝出现在第二行，而第二行才是 agent 的常态： 一个稳定的系统提示加工具定义，每一轮都被重读一遍，60 轮下来读了 900 万 token。

这里的口径要说清楚，否则数字会被读错三次：

• 900 万 / 18 万 / 12 万这组假设来自 Technspire，不是我们跑出来的。你的循环形态不同， 倍数就不同——缓存占比越高，差距越大；如果你的 agent 每轮都换系统提示导致命中率趋零， 这 39% 会缩到接近 0，因为大家都按未缓存输入价挨打。
• 缓存写入两家同价（$12.50/M，指缓存只活 5 分钟那一档）。Anthropic 另有一档让缓存活 1 小时、写入 $20/M——更贵不是更便宜；用那一档的话 Fable 这列变成 $11.85，差距收窄到 31%。 39% 是这个形态下的上限。 Anthropic 在 5.1 上降的只有缓存读取那一行 （官方价目页脚注： 按输入价 0.025 倍计，其余所有模型仍是 0.1 倍），写价一分没动。
• Astra 还有一条本表没体现的陷阱：超过 272,000 输入 token 的请求，整个请求换一套价目—— 输入与缓存价翻倍、输出价 ×1.5。一次 30 万输入 + 8 千输出的调用是 0.300×$20 + 0.008×$75 = $6.60；把输入砍到 27 万落回标准档， 0.270×$10 + 0.008×$50 = $3.10。少三万 token，账单减半。

三条判断规则

短评就到这里，剩下的篇幅给规则。每条都能单独拿去用，也每条都有出处。

规则一：看 cache read 不看 input

标价那一行是给单次调用看的。agent 的账单由 cache read 主导，而这个事实在真实流量上 有独立的证据——不是推算。OpenRouter 的 Fable 5.1 模型页 公布了各 provider 的实付输入价与缓存命中率（截至 2026-09-05）：

看竖着的两列：标价一栏四个 $10 分文不差，实付一栏没有一个是 $10——最高的那家也只收到 $7.733，命中率最高的那家收到 $1.433。标价与实付之间横着的那道口子，才是这张表真正在说的事， 而它的宽度由命中率决定。所以「这个模型多少钱」这个问题，在 agent 场景下问的是缓存， 不是标价——先去 usage 字段里把 cache read 的占比读出来，再去看价目表。

这个占比怎么从自己的 usage 数据里拉出来，本刊 前几天算过一次（那篇解决的是同一家内部 Fable 5.1 与 Opus 5 该切哪个）。本篇不重复那道除法，只提醒它在跨厂商比价时同样是分母。

规则二：看 workload 形态不看单价

上面那张对照表的第一行和第二行用的是同两张价目表，结论一个是 0%、一个是 39%。 决定你付多少的不是单价，是哪一行单价被乘上了大系数。

Spotify 的一位工程师把这件事说得比价目表清楚。他在 Portal by Spotify cut my Claude Code token usage by 90% 里的开场是：编程 agent 替他做的事，大部分不是思考，是 I/O——为了回答关于一个方法的问题去读 五个文件，照着旁边二十个测试文件的样子再生成一个。这些 token 花掉了，几乎没有推理发生。

也就是说，形态不只决定你该选谁，也决定这些活该不该进 frontier 模型。他的做法是把大文件 读取和样板代码生成交给两个跑 Gemini 2.5 Flash 的 mode，用 PreToolUse 钩子在 Read 超过默认 350 行时拦下来改走 bulk-reader。代价写在这里：多一层 CLI 与钩子要维护，且被委派出去的内容 不再进主模型的上下文——这是省钱的原因，也是它偶尔会漏掉线索的原因。至于那个 90%， 标题里写的是 “my token usage”，是作者个人用量口径的自述，不是可外推的普适结论。

规则三：看 provider 档位不看模型名

同一个模型名下，选错档位比选错模型贵得多。 OpenRouter 的 Astra 模型页列了五档（截至 2026-09-05）：

从 Flex 到 Fast 是四倍价差，模型名一个字没变。Flex 便宜的代价写在同一张表的延迟列里 （P50 约 6.88 秒，Fast 约 2.04 秒），批处理类任务拿这个延迟换一半价钱通常划算， 交互式的不行。「我们用的是 Astra」这句话不包含任何价格信息，它得配上档位才成立。

下一次选型之前，先量三个数

先说清这篇的边界：本文只比价，不比能力——两家在你的任务上是否等价，是另一道必须先过的门 （能力侧见值不值 $10/$50）。若不等价，这 39% 不是净收益。

不必重做一遍我们的算术，去量你自己的：从响应的 usage 字段里取 cache read、cache write、 output 三项，按你自己一个真实会话的形态，代进候选模型的价目表各算一遍。这件事的代价是 半天，比按错口径签一个季度便宜——这也是上一篇里那四条底线 的直接用法：当时说的是账单看不见的地方，这次是同一份账单在两家之间的分岔。

标价是给单次调用看的，agent 账单是给循环看的。两个 $10/$50 摆在一起看不出区别， 跑满 60 轮才看得出来。

---

延伸阅读：五档 provider 把同一个 Astra 的账单拉开 4 倍、三种 workload 形态的逐档算账， 在 en 刊同日篇 same $10/$50, and a 39% cheaper agent bill。 能力侧「这个价买到了什么」见 GPT-6 Astra 值不值 $10/$50。