终端里读懂每次请求的账单：输入、输出、缓存写入与命中

终端里读懂每次请求的账单：输入、输出、缓存写入与命中

每天在编辑器里改代码，很容易把一次任务当成一次调用。实际上，一轮代码审查可能经过读取文件、工具调用、补充上下文和重试，最终留下多条账单。2026年看模型成本，实用的起点不是比较单个标价，而是把每次请求拆成输入、输出、缓存写入和缓存命中四项。

我习惯先保存请求标识，再看费用。回答突然变贵时，先查是不是多带了文件、生成了更长的补丁，或者缓存前缀失效，而不是立刻换模型。

四种令牌，先确认是否重复计数

输入是送给模型的内容，输出是模型生成的内容；缓存写入是建立可复用上下文，缓存命中则是读取已经缓存的部分。但账单字段未必互斥：有的接口把缓存令牌包含在输入总量里，有的单独列出；缓存写入也可能采用独立单价，或者在基础输入费用上加收。

因此，别直接把所有 usage 数字相加。先核对当前模型的计费说明，明确普通输入是否已经扣除缓存部分，再计算金额。输出侧也应确认是否包含计费的推理令牌，不能只按终端里看见的文字估算。

用一笔假设账单验证计算公式

假设某次请求的输入已经拆成互不重叠的三部分：普通输入8000令牌、缓存写入4000令牌、缓存命中12000令牌，另有输出2000令牌。假设四项每百万令牌价格依次为2、2.5、0.2和10美元；这些只是演示数字，不是任何在售模型的报价。

这笔费用就是0.016＋0.010＋0.0024＋0.020＝0.0484美元。这里缓存写入使用完整单价；若实际规则是附加费，公式必须调整。把这个小例子放进计费脚本的测试，比盯着控制台猜数字可靠，也能抓出把每百万价格当成每千价格的单位错误。

缓存优化先稳定前缀，再讨论命中率

把稳定的系统指令、工具定义和项目约定放在前面，把当前问题、动态日志和时间戳放在后面。不要每轮都随机重排工具，也别为了记录请求时间而改动固定前缀。缓存资格、最小长度、有效期和隔离范围仍要按模型规则核对，重复发送不等于必然命中。

写入缓存也有成本，单次任务可能还没复用就结束了。我会用同一份上下文连续跑几次，比较总费用和延迟，而不是只展示第二次请求的便宜账单。命中率上升也不保证总费用下降：如果为此塞进大量无关代码，输出质量和整体开销都可能变差。

请求日志保留四项费用与重试关系

至少记录模型、请求标识、时间、四类令牌、对应金额、计价单位、耗时和重试来源。原始 usage 与归一化结果都保留，但默认不落盘源码、密钥或完整提示词。流式响应应确认最终用量是否收齐；断连和超时也不能直接视为免费。

任务级统计则把工具往返、自动重试和并行分支一起汇总。比较 Claude Sonnet 5.5 与 DeepSeek V4 Flash 时，用同一组任务和验收标准，观察每个通过测试的任务花了多少钱，而不是只比较每百万输入价格。

统一入口后，仍要按模型核对账单

在 Fluxo，我可以用一个密钥和同一个基础地址 https://api.fluxorelay.com 接入 Claude、GPT、Gemini、DeepSeek、Kimi、GLM、Qwen、Grok 等模型，并沿用 Claude Code、Codex、Gemini CLI 或任意 OpenAI SDK。统一入口减少配置切换，但不意味着不同模型的缓存语义也完全相同。

Fluxo 按实际令牌计费，包含缓存读取和写入，没有月费。如果你想拿自己的终端任务验证这套方法，可以创建一个 Fluxo 账户，从一条短请求开始。邀请的人付费后，邀请者还能获得推荐分成；做成本分析时，应把分成收益与请求费用分开记录。

合并代码前，跑一次账单回归

我会固定一组任务，分别测试冷缓存、热缓存和上下文变更后的费用，保存当时的价格快照，并给单任务预算设提醒。发现差异时，先对照请求标识和原始用量，再排查重试与字段映射。如果仍需帮助，可以登录后在联系页面留言。让费用变化像测试失败一样可追踪，账单才真正成为开发工具。