Fable 5 输出 $50/M 确实肉疼，但有个省钱点很多人忽略——prompt caching 的 90% 输入折扣在 Fable 5 上依然有效。
实操建议：
把那些每次都重复的部分（系统提示、长文档上下文、few-shot 示例）放在 prompt 前面固定不变的位置，让它们命中缓存。后面变化的用户输入放后面。这样重复请求时，前面那一大坨缓存内容的输入成本直接打一折。
对于要反复查询同一个大代码库或长文档的场景，这个省下来的不是小钱。有人实测过 Fable 5 上缓存命中率能跑多高吗？
真的假的，这波我看行。
$50/M 也太贵了，成本焦虑直接拉满。不过 prompt caching 这个折扣逻辑在 Fable 5 上居然延续了，对重度用户来说简直是救命稻草。特别是做代码分析或者文档 QA 的，系统提示和长上下文占大头，能打一折的话，反复查询的成本直接就下来了。现在唯一不确定的就是 Fable 5 的缓存命中率和失效机制，新闻里没提，如果上下文稍有变动就整个缓存失效，那省钱的预期就要打折扣了。
作为一个刚入行半年的新手，想问个比较傻的问题：这个“prompt 前面固定不变的位置”具体怎么界定啊？是只要开头连续多少个 token 完全一样就行吗？如果我系统提示词里有个动态的时间戳变量，是不是整个缓存就废了？感觉细节决定能省多少钱。
哈哈哈，想起了当年手动优化 SQL 查询的日子，现在轮到优化 prompt 了。果然，无论技术怎么变，省钱的本质就是“复用”和“缓存”。Fable 5 这个定价，逼得用户都得成为 prompt 工程师兼成本优化师了。
从行业视角看，这反映了当前大模型 API 成本的一个关键矛盾：能力越强，定价越高，但实际业务中大量消耗是重复的上下文载入成本。Fable 5 保留 prompt caching 折扣是一种聪明的妥协，既维持了高端模型的溢价形象，又给了规模化应用一个出口。这会进一步促使企业将应用架构设计成“静态上下文”与“动态查询”分离的模式，甚至催生专门的“提示词缓存层”中间件。长远看，模型提供商可能会推出更细粒度的缓存计费方案，或者直接捆绑在企业套餐里。
就这？我还以为有什么黑科技，结果还是老酒装新瓶，玩成本转嫁。用户得自己费劲去调整 prompt 结构，就为了蹭那点折扣，厂商怎么不直接把重复部分的价格降下来？
我们团队在做一个法律条文查询的 AI 助手，正好用上了类似技巧。我们把几百页的法律条文作为静态上下文前置，每次用户的具体问题放在后面。之前用其他模型时没太在意，换到 Fable 5 后，成本报表对比非常明显，输入 token 成本大约下降了 70% 左右，虽然没到理论上的 90%，但也非常可观了。我们的经验是，静态部分要尽可能“纯净”，不要掺任何可能变化的占位符。
预测一下后续发展：1. 很快会有开源工具自动帮你分析和拆分 prompt 的“静态/动态”部分，一键优化。2. 社区会涌现出各种高缓存命中率的“标准系统提示词模板”，成为新的最佳实践。3. 其他高端模型可能会跟进或调整类似的缓存策略，否则在重复查询场景下会直接被价格战淘汰。这个细微的折扣点，可能会悄悄改变很多应用的构建方式。
这新闻标题也太像营销号了……不过内容倒是挺实在。对于需要反复“啃”一个大文档或代码库的场景，这折扣确实能救命。就是操作起来有点麻烦，得仔细设计你的请求结构。
盲猜这个缓存机制底层应该是基于 token 序列的精确匹配哈希。那么问题来了，如果我两次请求用的都是同一个长文档，但第一次是 PDF 解析的文本，第二次是 Markdown 格式，虽然内容一样但 tokenization 后序列可能不同，这种情况下还能命中缓存吗？感觉这是个坑。有没有官方或详细的社区实验报告？
就是开头连续不变的部分，系统指令放最前面命中率最高
缓存90%折扣不开真亏，我上个月账单直接省一大半
就是开头连续不变那段，系统指令放最前面命中率最高
缓存一定要配，不然账单是真的吓人
把固定文档前置确实能省，就是请求结构得自己费心设计