同一个任务可能调用多次 API；按任务次数乘一个价格通常对不上账。先把时间范围、模型、计费单位和服务商固定，再按请求核对。
先固定账本口径
本文用假设单价演示算法：普通输入每百万 Token 2元、缓存输入0.2元、输出10元；这不是任何产品的报价。账本区间为北京时间10:00—10:10，期初余额10.0000元、期末9.9882元，没有充值、退款和其他Key调用。真实操作应换成该时段生效的价格及服务档位。
三条记录算出应计费用
输入总量包含其中的缓存量，不能把缓存部分再按普通输入重复收费。公式为：（输入总量−缓存输入）×普通输入单价 + 缓存输入×缓存单价 + 输出×输出单价，再除以100万。
| 请求 | 任务 | 输入总量 | 其中缓存 | 输出 | 教学费用 |
|---|---|---|---|---|---|
| req-A | 初稿 | 1000 | 0 | 200 | 0.0040元 |
| req-B | 复核 | 1000 | 500 | 300 | 0.0041元 |
| req-C | 重试后成功 | 1500 | 500 | 100 | 0.0031元 |
合计0.0112元。以req-B为例：500×2/100万 + 500×0.2/100万 + 300×10/100万 = 0.0041。应有期末余额9.9888元，但实际是9.9882元，待解释差额为0.0006元。
发现差额后只追具体记录
对账不能把0.0006元直接叫“乱扣费”，也不能凭经验说一定是重试。教学场景中，补查原始导出，发现本地漏记一条同任务 req-D：输入300、缓存0、输出0，服务端费用0.0006元。补入后总费用0.0118元，期末余额对齐。
这不表示所有失败或零输出请求都会计费。实际请求是否计费要看服务端明细与合同口径；没有req-D记录时，差额只能保留为未解释。其他常见分支是跨时区落入相邻区间、控制台统计尚未结算、不同模型/档位单价、工具调用费用，以及其他Key或并行进程。
保存能复核的记录
可建立 CSV，字段为 timestamp_with_timezone, task_id, request_id, provider, model, input_tokens, cached_input_tokens, output_tokens, price_version, charged_amount, status。不要记录Key或请求正文。按 request_id 去重，区分一次用户点击、一次任务和多次网络尝试；服务端没有request_id时，时间+模型+用量只能辅助匹配，不能视为唯一证明。
每次先对齐一个短区间。如果账单按充值额度扣除而非人民币显示，先记录系统换算口径，不能把本教程的假设“元”直接套用。带着差额、区间、脱敏请求编号与价格版本反馈，客服才有可查的范围。
资料来源
下一步
继续阅读与你当前问题相关的教程：
