终端里的百万 token 账单：常见算价错误与修正
从终端里的一次请求看百万 token 单价
我在编辑器里改完一个函数，直接用 curl 发给 https://api.fluxorelay.com，返回的 usage 字段显示 input、output、cache read、cache write 四行数字，账单就从这些数字开始算。单价通常写成每百万 token 多少钱，先把这个价格除以一百万，得到每 token 的单价，再乘以实际使用量，最后再换算成人民币或美元，避免用整数估算造成的误差。
例如请求发送了 1200 个 token，模型回了 480 个 token，单纯按输入和输出相加得到 1680 个 token，如果单价是每百万 token 两元，费用就是 1680 乘以 0.000002，约 0.00336 元。真实请求还会包含缓存写入的 900 个 token 和缓存读取的 2400 个 token，四类用量都可能有独立价格，少算任何一类都会让预算看起来比实际便宜。
Fluxo 只要一个 key 和一个 base URL 就能同时调用 Claude、GPT、Gemini、DeepSeek、Kimi、GLM、Qwen、Grok 等模型，并且按真实 token 计费，缓存读取和写入也分别计入，没有月费，所以每次请求都能和 usage 对上账。
把输入和输出当成同一个价格
最常见的算价错误，是看到一个“每百万 token”价格后，把提示词、补全内容、工具调用返回都乘同一个系数。多数模型的输入和输出单价不同，输出往往更贵，而且工具结果、系统消息、历史轮次都可能算进输入，调用次数增加后差距会很快放大。
- 检查文档或响应元数据，分别记录输入 token、输出 token 和缓存相关用量的单价，再把四类费用单独相加。
- 为每次调试请求保留原始 usage 字段，避免只看聊天界面显示的字数而漏掉被隐藏的系统消息和工具结果。
- 在脚本中输出每类 token 的小计和总计，让编辑器里的每次运行都能看到费用分解，而不是只看到一个模糊的总数字。
我通常会把请求拆成两次测量，一次带完整上下文，一次只带最小提示词，比较输出差异，确认哪些 token 真正值得付费。这样既不会把便宜的输入误当成昂贵的输出，也不会因为估算保守而错误砍掉有用的上下文。
忽略缓存读写让预算失真
缓存看起来是省钱工具，但它有写入成本和读取成本，第一次请求写入的长系统提示词会在后续请求中读取，而读取价格通常低于重新输入，却不是免费。只按普通输入计算，会让长对话的月度费用被低估；反过来把所有缓存读取都按普通输入计算，又会错过真实的节省幅度。
- 把缓存写入视为一次性投资，把缓存读取视为后续折扣，分别记录次数和 token 数，才能判断多轮对话是否真的划算。
- 当缓存命中率突然下降时，先检查提示词前缀是否发生微小变化，因为一个空格或时间戳都可能导致整段缓存失效并重新计费。
- 在批量脚本中限制并发请求，避免缓存尚未稳定就同时刷新大量上下文，造成昂贵的写入费用集中出现。
我在跑代码审查流水线时，会把稳定的项目规范放在请求最前面，把易变的文件差异放在后面，让前缀保持稳定；再用 usage 统计缓存读写比例，确认折扣确实发生，而不是凭感觉判断。
长上下文、重试和失败请求都会消耗 token
另一个隐蔽错误是把失败请求当作零成本。网络超时、参数校验失败、模型限流后自动重试，只要服务端已经读取提示词并开始生成，就可能产生输入 token，甚至产生部分输出 token。开发者工具里的“请求失败”提示不会帮你免掉这部分用量。
- 在重试逻辑中给请求编号并记录每次尝试的 usage，统计失败请求的 token 占比，避免把返工成本误认为一次成功调用。
- 对长文件和多轮历史设置预算上限，达到阈值就截断或摘要，别让一次补全因为携带整个仓库内容而产生意外的百万级输入。
- 为工具调用设置最大轮数和最大返回长度，防止模型反复读取大结果块，把一个简单任务拖成长时间高消耗会话。
实际项目里，我会先用短上下文跑通函数签名，再逐步加入必要文件，每次都在终端打印本次费用，这样能及时发现某个工具返回的隐藏大块数据正在悄悄拉高账单。
切换模型时不要套用同一个单价
货架上的模型价格和能力并不一一对应，例如 Claude Haiku 4.5 适合高频小任务，而 DeepSeek V4 Flash 更偏向快速批量处理，两者的输入输出单价、缓存策略和上下文上限都不同。把一个模型的经验直接套到另一个模型，通常会让批量任务的预算偏差超过三成。
- 为每个模型建立单独的价格表和用量样例，至少用同一组提示词分别测量输入、输出和缓存读取的真实花费。
- 在切换模型前比较单位任务成本，而不是只比较每百万 token 标价，因为更便宜的模型可能需要更长输出或更多轮工具调用。
- 把模型名写进每次请求日志，和费用一起保存，出了偏差就能回溯是哪个模型、哪类 token 导致的。
我最近把一个代码补全脚本从通用模型换成 Claude Haiku 4.5，又把批量文档摘要换成 DeepSeek V4 Flash，随后按真实 usage 重算，发现总费用下降的同时输出长度更稳定，这比只看标价更可靠。
用一次真实调用校准整张计价表
与其在表格里反复猜测，不如在编辑器里发一个最小请求，把返回的 usage 和账单金额放到同一行比较。Fluxo 同时兼容 Claude Code、Codex、Gemini CLI 以及任何 OpenAI SDK，同一个 key 和同一个 base URL 就能复现实验，换模型时只需要改模型名，计价口径保持可见。
把请求日志按模型、token 类型和项目分组，每周抽样核对一次实际扣费，久而久之就会得到自己的单价表和常见误区清单。邀请来的用户付费后，你还会获得对应的 referral 分成，这部分收入也应该单独记录，别和 API 支出混在一起。
如果你正在编辑器里整理这套计价表，欢迎创建一个 Fluxo 账号，把真实请求跑起来并对照 usage 校准费用；如果使用中遇到问题，登录后可以在联系页面留下说明，方便一起核对账单细节。