token 计费方式

很多人第一次看 API 账单会懵：明明只问了十几个字，扣的却不止这些。问题多半出在「输入」和「输出」是分开计价的两笔账，而且输入里塞的不只是你打的那句话。这篇不重复别人已经讲过的缓存和倍率，只把输入输出拆分、用量估算和核对流程讲成一套能照着做的动作，让你下次看到账单能对上号。

很多人第一次看 API 账单会懵：明明只问了十几个字，扣的却不止这些。问题多半出在输入和输出是分开计价的两笔账，而且输入里塞的不只是你打的那句话。系统提示词、历史对话、检索回来的资料、工具定义，全都算在输入里。

这篇不重复站内已经讲透的缓存和倍率，只把输入输出拆分、用量估算和核对流程讲成一套能照着做的动作。目标很朴素：让你下次看到账单能对上号，知道钱花在哪一段，哪些能砍。

先分清：输入和输出是两笔账

输入指你这次请求发出去的全部内容，凡是进到请求体里的都算；输出只算模型生成返回的部分。这两者单价通常不一样，输出一般更贵，所以同样多的 token，让它多写示例、多给结论，花费差距会明显拉开。

输入 token

系统提示词、历史轮次、本轮提问、检索资料、工具定义，凡是发出去的全算

输出 token

只有模型返回生成的正文算，思考过程是否计入要看渠道口径

多轮会话

每轮都要把前面的内容重发，轮次越多单轮输入越大

不适用的情况要说清楚：订阅制编程工具是按额度而不是按 token 直接扣费，看的不是这套拆分逻辑，判断标准在 /coding-plans。另外中转站渠道的计费口径可能和官方不同，先对齐倍率再谈拆分。

估算用量：按字符粗算再乘个系数

没有计量工具时，可以先按字符粗估。中文大致一个字接近一个 token，英文按字符数打七折左右，代码和标点密度高的文本要往上浮。先粗算一轮，再用实际账单回校，两三次就能摸出自己业务的系数。

1. 列全四项系统提示词长度、历史轮次总量、本轮提问、预计输出长度，四项相加才是这次调用的总消耗，缺一项就会估偏。
2. 历史单独看把历史对话单独拉出来算一次。多轮会话里输入是滚雪球，前面几轮的小开销会被反复重发。
3. 工具换算要精确到具体模型，用 /tools/token-price-calculator 换算，别靠感觉说个大概。

估算的用处不是省这点算力，而是发现异常。如果估算和账单差出一个量级，说明有东西在被重复发送，或者失败重试在偷偷加次数，这比单纯算准更有价值。

把成本压下来的四个动作

• 拆 prompt：固定系统提示词尽量短，示例从常驻改成按需塞，直接减少每次调用的输入量
• 控输出：提示里限定字数、要求直接给结论、禁止复述问题，输出单价高，这里见效最快
• 截断历史：超过一定轮次就把早期对话压成摘要，或只带最近几轮，别让上下文无限增长
• 分任务选模型：分类、格式转换这类活走便宜档，复杂推理再用贵档，分档参考 /models 和 /official-api

这四个动作有优先级。先做控输出和截断历史，因为它们改的是每次调用的固定部分，效果立刻体现在账单上；拆 prompt 和分模型选型是中期优化，需要改代码和流程，适合放进迭代计划。

不适用的情况：如果业务本身就依赖长上下文、多轮追问，那截断历史会伤到效果，这时候优先动输出约束和模型分档，别硬砍上下文。

对账：三步把账单和用量对上

1. 按天聚合用量把用量日志按天聚合，分别看输入和输出是多少，缺少字段的参考 /usage 里的记录维度自己补上。
2. 乘单价对金额拿当日输入输出量乘当期单价，和账单金额比。差异超出预期就去查缓存命中、失败重试、重复发送这几块。
3. 写进复盘把结果写进月度复盘，只盯变化最大的那一两项，别每项都动，动多了分不清是哪一步起的作用。

对账的意义是建立基线。有了连续几个周期的输入输出曲线，你才能判断某次成本上涨是新功能带来的正常增长，还是某段逻辑在漏 token。没有基线，所有讨论都是凭感觉。

不适用的情况：中转站渠道的计费口径和官方可能不同，先对齐倍率再对账，具体说明在 /sites。如果对账差异长期存在且集中在某个渠道，那问题可能不在你的代码，而在计费口径本身，这时候换渠道验证比继续调参更有效。