事情本身不复杂，线索都在日志里。开了 prompt caching 之后账单反而涨了，同一份 6000 token 的 system 每分钟重建一次，缓存读取只有 3 次，账单里 cache creation 那一项占了三成。
第一反应是「缓存有效期短，重建频率高于命中频率」，验证下来不成立。
这类报错背后常见的原因有几处，逐个排除就行。缓存写入按更高倍率计价，写得越多越贵。少数情况下是前缀每次都变，导致反复创建缓存。
少数情况下是把不该缓存的动态内容放进了前缀。
动手时先看用量里缓存读写各占多少
python -c "import json;d=json.loads(open('usage.json').read());print(d.get('cache_creation_input_tokens'),d.get('cache_read_input_tokens'))"再往下把时间戳从 system 前缀里挪走
python -c "s=open('system.txt').read();print(s.replace('当前时间：', '')[:120])"固定前缀长度后再压测命中率
python bench_cache.py --prefix system.txt --rounds 20 --interval 30剩下的就是按命中率决定是否继续开缓存
python -c "print('hit = read/(read+create); 低于 0.3 就关掉')"改完先别撤，确认这几项。缓存读取次数是写入的三倍以上，账单里 cache creation 占比降到 5% 以下，总成本回落。
缓存的账要按读写比例算，前缀短、变动频繁时开缓存比不开更贵。这类问题最好一次改到位，反复小改反而容易把原因搅混。