缓存写、缓存读、输入、输出：四项计价一分钟分清

很多人第一次拉用量明细时会愣住：返回体里的几个字段加起来，跟账单上的数对不上。问题多半不在站点，而在四项计价没分清——哪项是这次新写入缓存的，哪项是命中缓存便宜读的，哪项是普通输入，哪项是输出。这篇给一张对照表和一套对账顺序，让你下次看到 usage 就能自己拆开。

很多人第一次把用量明细拉出来会愣一下：返回体里那几行 token 数字，加一加跟账单上的金额对不上。第一反应是「站点算错了」，但多数时候问题出在自己这边——四项计价的边界没分清。哪笔是这次刚写进缓存的，哪笔是命中缓存便宜读的，哪笔只是普通输入，哪笔是输出，各自单价不一样，混在一起当然对不上。

这篇不讲原理，只做两件事：给一张四项对照表，让你知道每项什么时候产生、在返回体里大概长什么样；再给一套从总数拆到四项的对账顺序。看完你下次打开 usage 就能自己拆开，而不是发消息问客服。字段命名各家有差异，具体名字到站内资料页核对当时的字段说明。

四项计价对照表：什么时候产生、返回体里叫什么

先把四项拆干净。普通输入和输出是每次请求都有的基础两项，跟缓存无关；缓存写和缓存读只在用了提示词缓存之后才出现，且不会同时发生——一次请求要么是在写缓存，要么是在读缓存，很少两个都大。理解这一点，对账时第一步就能把请求分成两类。

字段名各家不完全一样。Anthropic 系偏 cache_creation_input_tokens 与 cache_read_input_tokens 这种写法，OpenAI 系更多用带 cached 字样的明细字段。别死记名字，去站内 /ai-dict 查名词解释，再去 /official-api/providers/anthropic-claude-api 这类厂商页对照当时的字段说明和单价。

对账顺序：从总数拆到四项，别反过来

对账最容易犯的错是先盯差额、再猜哪项漏了。正确顺序是从总数往下拆：先拿到返回体里的总 token，再按四项分开，然后四项各自乘以当时的单价求和。单价别凭记忆，去 /official-api 或 /tools/token-price-calculator 按当时的数字换算，换算完再跟账单比。

1. 拿到总数从返回体或日志里取这次请求的总 token，先不拆，确认这个数本身没有漏字段。
2. 按四项拆开把总数分解成普通输入、输出、缓存写、缓存读四份，缺哪份就说明这类请求本来就不涉及。
3. 分别乘单价再求和四项各自的量乘以当时单价，加总得到一个自算金额，单价到 /official-api 核对当时的数字。
4. 跟账单比差额差额方向有意义：账单比自算高，多半是倍率或输出占比大；账单比自算低，多半是命中了缓存读。

求和跟账单对不上，先别怀疑字段漏算，先怀疑倍率与分组。倍率口径站内 /markup-group-pricing-columns 那篇已经讲过，这里不重复。你要做的是把倍率、分组这些站点侧参数单独列一行，跟四项分开算，混在一起算永远对不清。

三种最常见的误读，以及各自的纠正动作

下面三种误读几乎每次对不上账都能碰到。它们的共同点是「凭感觉估算某一项」——要么当它免费，要么当它不存在，要么只看总量不看结构。纠正动作都不复杂，关键是养成固定记录的习惯。

• 误读一：把缓存读当免费。纠正动作是把缓存读单价单独记一笔，哪怕它便宜，量大了一样进账单；命中率高的场景尤其要盯住这一项。
• 误读二：只算缓存读不算缓存写。第一次写入那笔通常更贵，长文档反复重发时这笔开销最容易被忽略，对账时先把缓存写单独列出来看。
• 误读三：只看总 token 不看结构。同样的总量，输出占比高和缓存命中高，花费能差出一截，去 /usage 看真实用量结构比看总量有用。

什么情况下这套逻辑不适用：短提示词、单轮问答基本不触发缓存，这时四项里只有输入和输出有效。硬套缓存逻辑去拆，只会拆出一堆零，白白增加困惑。先判断你的场景会不会命中缓存，再决定要不要拆四项。

落地动作：让以后每一笔都能对上

判断标准有了，接下来是让它变成日常动作。核心是把四项字段固定记进日志，把站点侧参数和四项分列，再定一个对账频率。做不到这三点，下次打开账单还是两眼一抹黑。

不确定口径的时候，去 /price-watch 和 /tools/model-cost-calculator 复核当时的数字，别靠自己记的旧单价。站点计价规则和模型单价都可能调整，你手里那张表要么定期更新，要么每次对账时现查一次，省下来的时间远比查一次多。