给长系统提示分段加 cache_control，一共标了 6 个断点，请求回 400，原文是 maximum of 4 cache breakpoints allowed，去掉两个后正常。
一开始怀疑是「工具定义里重复标记」，查了一圈，方向不对。
这类报错背后常见的原因有几处，逐个排除就行。单次请求最多 4 个缓存断点。另一种情况是每轮动态内容也被加了断点。
不容易想到的是，分段逻辑按段落数而不是按断点数。
数一遍请求里的断点数量
python -c "r=open('req.json',encoding='utf-8').read();print(r.count('cache_control'))"只保留系统提示开头与工具定义两处
python trim_cache.py --in req.json --out req_fix.json --max 4发一次带缓存的请求确认
curl https://api.anthropic.com/v1/messages -H "x-api-key: $ANTHROPIC_API_KEY" -H "anthropic-version: 2023-06-01" -H "Content-Type: application/json" -d @req_fix.json剩下的就是看 usage 里的缓存读写 token
python -c "import json;print(json.load(open('resp_fix.json'))['usage'])"报错是间歇性的，我蹲守了半小时才抓到一次完整现场。
白天有业务在跑，能验证的部分都压到了晚上做。
当时还开着另一个排查窗口，两边日志对照着看才定位到。
改完先别撤，确认这几项。请求返回 200，usage 里 cache_creation_input_tokens 大于零，第二轮出现 cache_read_input_tokens。
容易忽略的是，断点越少越容易命中，把稳定不变的部分放前面，动态内容一律不加断点。拖得越久，排查成本越高，因为现场状态会被后续操作覆盖。