单个聊天会话的上下文token开销(第一次超限之前)怎么计算？

[xmkid]

研究了好一阵，核心应该是input_tokens、output_tokens、cache_creation_input_tokens、cache_read_input_tokens这些字段？但是agent和大模型给的答案都不太像，返回的数值看着也不太对，想直接抄答案了，猫猫帮忙回答下吧

[zts212653]

好问题，这个确实不直观。我来拆解一下。

核心字段

Claude API 返回的 usage 里有这几个关键字段：

字段	含义
input_tokens	本次请求发给模型的 总输入 token 数（含 system prompt、历史消息、工具结果等）
output_tokens	模型本次生成的 输出 token 数
cache_creation_input_tokens	本次请求中 新写入缓存 的 token 数
cache_read_input_tokens	本次请求中 从缓存命中 的 token 数

怎么理解"上下文开销"

单次请求的上下文大小 ≈ input_tokens

这就是你这一轮对话发给模型的全部内容。注意：

• 每一轮对话，整个历史都会重新发送（这是 stateless API 的特点）
• 所以 input_tokens 会随着对话轮次单调递增（直到你做了压缩/截断）

缓存的关系：

• input_tokens = cache_read_input_tokens + cache_creation_input_tokens + 未缓存的 token
• 缓存不影响"上下文有多大"，只影响计费和延迟
• 缓存命中的 token 便宜很多（约 1/10 价格），所以 cache hit 率高 = 省钱

实际计算"我离限制还有多远"

已用上下文 = input_tokens + output_tokens
剩余空间 = 模型上下文窗口 - 已用上下文

比如 Claude Sonnet 的上下文窗口是 200K tokens：

• 你的 input_tokens = 150K，output_tokens = 5K
• 已用 = 155K，还剩 45K
• 当 input_tokens 涨到接近窗口限制时，就会触发超限

为什么"agent 给的数值看着不对"

几个常见陷阱：

1. system prompt 也算 input_tokens：很多人忘了，system prompt 可能就占了几千到几万 token
2. 工具调用的结果也算：每次工具返回的内容都会作为下一轮的 input
3. 缓存字段可能为 0：如果你没开 prompt caching，cache_* 字段就是 0 或不返回
4. token ≠ 字符数：中文大约 1 字 ≈ 1-2 token，英文大约 1 词 ≈ 1-1.5 token

如果用 Claude Code CLI

Claude Code 的 /cost 命令可以直接看当前 session 的 token 用量。它内部帮你做了上面的计算。

希望这个拆解有帮助！如果你能贴一下具体看到的 usage 返回值，我可以帮你分析哪个数字对不上。

— 布偶猫/宪宪 🐾

[xmkid]

我有一次调用input_tokens: 5480, cache_read_input_tokens: 105984，为啥？用的是claude code cli + kimi k2.5 llm