Fable 5.1 发布中，最容易被基准测试和模型能力指标掩盖的变化，是缓存读取价格从每百万 token 1 美元降到 0.25 美元，直接下降 75%。标准输入和输出价格没有变化，仍分别是每百万 token 10 美元和 50 美元。
这意味着它并不是一次“所有调用都变便宜”的调价，而是精准降低了长上下文 Agent 在重复读取相同上下文时的成本。对于代码代理、研究助手、审阅流水线和多轮工作流，这个变化可能比一次跑分提升更容易转化为实际预算。
价格变化到底影响什么
可以把一次模型调用的成本拆成三部分：
- 新输入 token：按标准输入价格计费。
- 缓存读取 token：已经写入缓存、后续调用重复读取的上下文，按缓存读取价格计费。
- 输出 token：按输出价格计费。
在 Fable 5.1 的定价变化中，只有第二项从每百万 token 1 美元降到 0.25 美元。一个简单的成本公式是：
总成本 = 新输入 token / 1,000,000 × 10
+ 缓存读取 token / 1,000,000 × 0.25
+ 输出 token / 1,000,000 × 50
这里的关键不是单次请求，而是上下文被重复使用的次数。一次性问答通常没有大量缓存读取；一个持续数十轮的 Agent 任务，却可能反复加载系统提示、仓库索引、工具说明、历史决策和中间产物。
为什么长任务更容易受益
假设一个代码 Agent 在任务开始时建立了 2,000,000 token 的稳定上下文，之后进行 20 轮调用。为了便于说明，下面只计算这部分上下文的缓存读取成本，不把新增输入和输出算进去。
降价前：
2,000,000 / 1,000,000 × 20 × $1 = $40
降价后：
2,000,000 / 1,000,000 × 20 × $0.25 = $10
同一组重复上下文节省了 30 美元。若输出很多，输出费用仍然可能是总成本的大头；但在长任务中，缓存读取成本通常是一个可以直接优化、而且不会牺牲上下文质量的部分。
这种成本结构尤其适合以下工作流：
- Agent 多轮修改同一个代码仓库。
- 研究任务反复引用一批固定文档。
- 客服或运营助手持续使用同一套规则和产品知识。
- 自动化审阅流程对同一份大型输入执行多个检查器。
- 多个子任务共享相同的系统提示和工具定义。
用脚本估算真实账单
下面是一个可以直接运行的 Python 示例。它对比降价前后的缓存读取费用，同时保留标准输入和输出价格不变。示例中的 token 数字是演示值，接入实际系统时应替换成日志统计结果。
from dataclasses import dataclass
@dataclass
class Usage:
fresh_input_tokens: int
cached_read_tokens: int
output_tokens: int
INPUT_PRICE = 10.0 # USD per 1M tokens
OUTPUT_PRICE = 50.0 # USD per 1M tokens
OLD_CACHE_READ_PRICE = 1.0 # USD per 1M tokens
NEW_CACHE_READ_PRICE = 0.25 # USD per 1M tokens
def cost(usage: Usage, cache_read_price: float) -> float:
return (
usage.fresh_input_tokens / 1_000_000 * INPUT_PRICE
+ usage.cached_read_tokens / 1_000_000 * cache_read_price
+ usage.output_tokens / 1_000_000 * OUTPUT_PRICE
)
usage = Usage(
fresh_input_tokens=300_000,
cached_read_tokens=40_000_000,
output_tokens=2_000_000,
)
old_cost = cost(usage, OLD_CACHE_READ_PRICE)
new_cost = cost(usage, NEW_CACHE_READ_PRICE)
saving = old_cost - new_cost
print(f"Before: ${old_cost:.2f}")
print(f"After: ${new_cost:.2f}")
print(f"Saved: ${saving:.2f} ({saving / old_cost:.1%})")
运行前可以从调用日志中提取三类数据：每次新增输入 token、缓存读取 token 和输出 token。不要只看请求总 token，因为总量无法说明哪些 token 享受了缓存读取价格。
降价不等于可以无限扩大上下文
缓存读取便宜了 75%，但标准输入和输出价格没有下降，且输出仍然是每百万 token 50 美元。因此，Agent 的优化目标不应变成“把所有内容都塞进缓存”，而应是区分稳定上下文和高变化上下文。
可以这样组织请求：
缓存区：
- 稳定的系统指令
- 工具定义
- 仓库目录和接口索引
- 固定的业务规则
- 已确认的项目约束
动态输入区：
- 当前用户问题
- 最新文件片段
- 最近一次工具返回值
- 尚未验证的中间结论
稳定内容放在可复用的位置，动态内容保持精简，通常更容易获得缓存命中，也更容易控制上下文失效范围。具体缓存标记、生命周期和命中规则取决于实际 API 实现，接入前应以对应版本的官方计费与缓存文档为准。
还要注意三类风险：
- 缓存未命中：动态字段、顺序变化或过度重写系统提示，可能让原本稳定的前缀无法复用。
- 上下文陈旧：缓存保存的规则或代码索引可能已经过时，必须定义失效和刷新策略。
- 输出膨胀：读取成本下降后，团队可能放松输出约束，最终账单却被大量生成内容推高。
上线前检查这几个指标
把这次调价转化为工程收益，需要把账单指标接到 Agent 运行指标上：
- 缓存读取 token 占总输入 token 的比例。
- 缓存命中率和未命中原因。
- 每个任务的平均调用轮数。
- 每个任务的输入、缓存读取和输出成本。
- 缓存内容的平均年龄，以及因陈旧导致的重试或人工修正次数。
如果工作流是短请求、低复用、输出占比很高，那么 75% 的缓存读取降价对总账单的影响会有限。相反，如果一个任务会持续运行很久，并且每一轮都需要读取大块稳定上下文，那么这项变化值得优先纳入成本模型。
采用建议
Fable 5.1 的这个价格信号更像是对 Agent 架构的奖励：把可复用上下文设计好，长任务就可能更便宜；把所有内容混在不断变化的提示里，降价也很难兑现。
上线前可以按这份清单执行：
- 分离稳定上下文与动态上下文。
- 在日志中单独记录缓存读取 token。
- 用真实任务轨迹比较调价前后的总成本，而不是只套 75% 的折扣。
- 为缓存内容设置版本号和失效条件。
- 限制输出长度，避免节省的读取费用被输出费用抵消。
- 先在长任务和高复用任务上灰度，再扩展到普通请求。
真正值得关注的不是价格表里一个更小的数字，而是模型调用开始更明确地区分“第一次理解一份上下文”和“反复读取已经理解过的上下文”。