先说清楚性质：这个页面上的所有金额，都是把你填进去的 token 数、单价和命中率 做了一遍算术，工具不联网、不内置任何服务商的价格，输入框里的初始值只是占位数字。 实际能省多少，一切以你自己的监控数据与账单为准。

缓存省的到底是哪一块钱

提示缓存的原理并不复杂：如果你每次请求的开头都是同样一大段内容， 服务端可以把这段内容处理后的中间状态存下来，下次遇到一模一样的开头就直接复用， 省掉重复计算，因此这部分 token 可以按一个明显更低的单价计费。 关键词是「一模一样」和「开头」—— 它匹配的是从第一个 token 起连续相同的那一段，中间断了就全断了。

这决定了一件很重要的事：缓存能省的钱，天花板是固定的， 就是「固定前缀占总输入的比例」乘以「标准价与缓存价之间的差额」。 它动不了变化输入那部分，更动不了输出那部分。 很多人对缓存抱有不切实际的期待，是因为脑子里只有「省了 90%」这类单价降幅的印象， 却忘了这个降幅只作用在整张账单的一小块上。这个工具存在的意义， 就是把这块占比和最终降幅算给你看。

这个工具具体算什么

输入八个参数：固定前缀 token、变化输入 token、单次输出 token、日调用次数， 以及标准输入价、缓存命中价、输出价和缓存命中率。工具按 30 天折算月成本，输出四组数字。

不开缓存的月成本是基准线：全部输入按标准价计，加上输出成本。 开缓存的月成本是加权结果：前缀里命中的那部分按缓存价计， 没命中的那部分退回标准价，变化输入始终按标准价计，输出成本不变。 两者相减得到每月节省额，再除以基准线得到节省比例。 除此之外还有两个诊断值：一是固定前缀占总输入的百分比，也就是前面说的天花板来源； 二是命中率拉满时的理论最大节省额，你可以拿它和当前节省额比，看还有多少空间没吃到。 最后还会给出当前的实际输入均价，方便你和标准价做直观对照。

结果怎么读，以及它的边界在哪

建议的读法是先看前缀占比。如果这个数很低，说明你的调用形态本身就不适合靠缓存省钱， 与其调命中率，不如回头看看能不能把稳定不变的内容尽量前移、聚拢成一整段。 如果前缀占比不低但节省额离理论上限差很远，那问题就出在命中率上， 常见原因是前缀里混进了时间戳、请求 ID、随机排序的工具列表或者用户标识这类每次都变的东西， 它们会让匹配从那个位置起整段失效。

局限同样要说清楚。工具按 30 天等量折算，不考虑周内波动和节假日； 它把命中率当成一个稳定的平均值，而真实命中率会随流量密度和缓存有效期起伏； 它没有把可能存在的缓存写入计费、最小前缀长度门槛、缓存有效期这些规则差异建模进去， 这些细则各家不同，需要你自己核对所用服务的计费文档。所以这里算出来的是决策参考—— 帮你判断「值不值得改造」这个量级问题，而不是用来预测下个月账单的具体数字。

延伸阅读

想搞清楚提示缓存的机制细节和改造做法，可以读 Prompt Caching 省钱原理与实践， 里面讲了命中条件和适用场景；如果你的场景里还有大量重复请求， 缓存复用减少重复调用 这篇讲的是在提示缓存之外再加一层应用层结果缓存，两层配合能把边际成本压得更低， 建议在动手改造前先看一遍。