先看现象。gemini-2.5-pro 处理 25 万 token 的合同，账单单价是报价的两倍，控制台显示输入落在 200k 以上档位。
排查方向其实有限，先把可能性排一排。超过 200k 后单价按更高档位计算。少数情况下是输入按整段计费，没有做裁剪。
不容易想到的是，上下文缓存不适用于这个档位。
还有一种情况，请求里混入了重复的附件内容。
上来先查当前模型的阶梯定价
curl -s https://generativelanguage.googleapis.com/v1beta/models/gemini-2.5-pro -H "x-goog-api-key: $KEY"随后按章节拆分后再分别请求
python split_contract.py --input contract.pdf --max-tokens 60000再往下统计每次请求的真实 prompt_tokens
python -c "print('usage_metadata.prompt_token_count')"剩下的就是对重复附件做一次哈希去重
python dedup_attachments.py --dry-run中途换过一次思路，把范围缩到最小的那一层，反而快了。
恢复的判定其实很直接。单次请求的 token 落在低价档位，总成本下降一半以上，摘要结果仍然覆盖全部章节。
长上下文模型的定价是阶梯式的，跨过阈值后是所有输入一起涨价，分段处理往往比一次性塞进去更便宜。改动前把原配置备份一份，出问题能马上回滚，这比任何技巧都实用。