先把当时的情况摆出来。开了 prompt caching，月度账单比自算高 18%，usage 里有 cache_creation_input_tokens 和 cache_read_input_tokens 两个字段，自算只乘了普通输入单价。
原因不止一个，得分开看。缓存写入单价高于普通输入。另一种情况是读取折扣只在命中时生效。
还有一种情况，缓存过期后重复写入同一前缀。另外，对账脚本只取了 prompt_tokens 一个字段。
先导出 usage 的三个计费字段
jq -r '.usage | [.prompt_tokens,.cache_creation_input_tokens,.cache_read_input_tokens] | @csv' resp.jsonl > usage.csv接着按三种单价分别计算再求和
python cost.py --input usage.csv --price 1,1.25,0.1再往下统计同一前缀的重复写入次数
python cache_stat.py --field prefix_hash --out cw.csv调整 TTL 减少重写并复核
python tune_ttl.py --ttl 1800中途换过一次思路，把范围缩到最小的那一层，反而快了。
中间停过一次，把已经改的东西回滚干净，再重新来一遍。
同样的操作我在测试机上先走了一遍，线上只做验证过的部分。
恢复的判定其实很直接。自算金额与账单差在 1% 以内，同一前缀的重复写入次数下降一半。
补一句。缓存不是白送的折扣，写入那一笔往往比普通输入还贵。线上能稳定复现的问题都不算难，难的是只在大流量下才出现的那种。