AI API 通常不是按“问一次多少钱”收费，而是按 Token 数量计算。一次请求会同时产生输入和输出，部分模型还区分缓存读取、缓存写入、图片或工具调用。想控制成本，第一步不是寻找一个最低单价，而是把自己的真实请求拆开计算。
基本公式
最常见的计算方式是：
单次费用 = 输入 Token ÷ 1,000,000 × 输入单价
+ 输出 Token ÷ 1,000,000 × 输出单价假设某次请求输入 20,000 Token、输出 2,000 Token，只需要把当前模型的输入和输出单价分别代入。不要用输入单价计算全部 Token，因为输出通常采用另一档价格。
模型价格会变化，计算时应从 模型广场 获取当前值，不要长期依赖旧文章里的数字。
什么算输入 Token
输入不只是你最后输入的那一句话，还可能包括：
- 系统提示词
- 历史对话
- 上传或读取的文档
- Claude Code 读取的项目文件
- 工具返回结果
- 重试时再次发送的上下文
这也是为什么同一句“继续”在长会话后可能比新会话贵得多。模型需要重新看到足够的上下文才能继续工作。
什么算输出 Token
输出包括模型生成的文字、代码和部分工具调用参数。要求模型输出完整文件、超长解释或大量候选方案，会直接增加输出 Token。
控制输出并不意味着一味要求“越短越好”。更有效的方法是明确格式：
- 只返回补丁，不重复原文件
- 限定表格列数
- 先给结论，需要时再展开
- 批量任务返回结构化 JSON
缓存怎么计算
部分模型和协议支持 Prompt Cache。重复的系统提示或长文档命中缓存后，读取价格可能低于普通输入；首次写入缓存则可能有单独价格。
判断缓存是否值得：
- 相同前缀会被重复请求
- 前缀足够长
- 内容在缓存有效期内不变化
- 调用次数足以覆盖首次写入成本
如果每次都修改开头，或者只调用一次，缓存通常没有明显意义。具体支持范围查看 计费说明。
长上下文为什么容易超预算
长上下文模型允许一次放入大量内容，但“能放进去”不等于“每次都应该全部放进去”。常见浪费包括：
- 每次请求重复发送整个仓库
- 对话历史从不裁剪
- 检索结果没有去重
- 日志和文档没有先筛选
可以先用便宜模型做分类或摘要，再把相关片段交给目标模型。Gemini 长上下文场景可参考 长上下文成本控制。
从单次费用估算月度预算
用下面四步估算：
- 从用量记录取 20 至 50 次真实请求
- 分别计算平均输入和输出 Token
- 乘以每天预计请求次数
- 再乘以每月工作天数，并留出重试和增长空间
月 Token = 单次平均 Token × 每日请求数 × 每月使用天数团队不要只看总预算，还要按成员、项目和 Key 分开。测试脚本失控时，独立 Key 的上限能避免它消耗整个团队余额。Zivv 的 团队模式 可为成员分配独立 Key 和预算。
用量记录比估算更重要
上线前的估算只能给范围。运行后应定期查看：
- 哪个模型消耗最多
- 输入与输出比例
- 哪个 Key 或成员增长最快
- 是否有异常重试
- 高价模型是否用于简单任务
先优化最大的一项，通常比全面压缩 Prompt 更有效。例如大部分费用来自重复长上下文，就优先做检索和缓存；来自超长输出，就先收紧返回格式。
一个可执行的成本控制顺序
- 从模型广场确认当前单价
- 用真实用量计算平均单次成本
- 按任务选择模型，不让高价模型处理简单分类
- 控制重复上下文和无效输出
- 为每个 Key 设置可承受的上限
- 每周看一次用量变化，而不是月底才看账单
Token 成本没有一个适用于所有人的固定答案。可靠的方法是用当前价格和真实用量计算，再通过模型选择、上下文管理和预算上限持续校正。刚开始接入可先看 AI API 新手入门，完整计费口径以 计费文档 为准。