AI 编程成本怎么算才对？从「每次请求」到「日均 Token 消耗」

一、「每次请求」为什么是错误的心智模型

传统的 LLM 成本计算器（包括我们自己的旧版）要求你填三个数：每日请求量、平均输入 token、平均输出 token。这个模型继承自 API 计费文档，但它和用户实际看到的数据完全对不上：

在 Agent 时代这个错位更严重：一次 Agent 任务内部是几十上百次模型调用，「请求」这个概念对用户已经失去意义。 研究显示单个 Agent 编码任务平均消耗 100 万–350 万 Token，你根本不知道也不需要知道它发了多少次请求。 Claude Code、Cursor 的用量面板、各家 API 控制台，给你看的都是同一个数字：日消耗 Token 总量。 成本计算应该从这个数字出发。

二、真实世界的消耗梯队：你在哪一档

综合开发者社区调研与公开数据（Anthropic 企业用量统计显示开发者中位数约 5100 万 Token/月，即约 170 万/活跃日；重度 Agent 用户可达数亿/日），日均消耗可以分成四个梯队，直接对号入座：

两个有用的锚点：Anthropic 官方口径下，AI 编码成本约为每开发者每活跃日 13 美元、每月 150–250 美元； 90% 的用户单日花费不超过 30 美元。如果你在用 Auto 模式跑长程任务，日均 1 亿以上并不罕见—— Agent 任务的 Token 消耗是普通代码问答的 1000 倍量级。

三、Input/Output 的真实比例：成本大头在 input

知道了总量，还要知道 input 和 output 怎么分——因为两者单价差 4–5 倍。 一个常见的误解是 Agent 场景「输出很多代码所以 output 占比高」。实测恰恰相反： Agent 每执行一步都要重读全部历史上下文，input 像滚雪球一样越滚越大。 典型的多文件重构任务是 5–10 万 input 对 1–2 万 output，5:1 到 10:1。

唯一 output 占大头的是内容生成类场景（短指令进、长文出）。只要你在做的事情带「上下文」—— 代码库、文档、对话历史——成本大头就一定在 input。

四、缓存命中率：最大的隐藏变量

既然 input 占大头，input 里有多少按缓存价计费就成了成本的最大变量。 主流厂商的缓存读取价通常是原价的 10%–25%（例如 Claude 系列 0.1x）。 Claude Code 这类工具会自动做 prompt caching，实测缓存通常能省掉 40%–50% 的 input 成本； 极端案例里缓存读取占到总用量的 99% 以上。

换句话说：同样日均 2000 万 Token，缓存命中 70% 和完全不命中，月成本能差出一倍。任何不算缓存的估算，对 Agent 用户都是系统性高估。有效 input 单价的算法很简单：

有效 input 单价 = 原价 x (1 - 命中率) + 缓存读取价 x 命中率

注意缓存写入通常有 1.25x 的溢价，但相对读取节省是小头，估算时可以忽略。

五、新公式与实算示例

把三个因子合起来，月成本公式是：

日成本 = 日均Token x input占比 x 有效input单价 / 1M
       + 日均Token x (1 - input占比) x output单价 / 1M
月成本 = 日成本 x 30

用实时价格算一遍：中度开发梯队（日均 2000 万 Token）、Agent 编码场景 （input 占 85%、缓存命中 70%）：

表中价格与结果随数据管道每日更新。可以看到缓存因子对 Agent 场景的影响有多大—— 这也是为什么订阅制套餐（按 5 小时窗口限额）对重度用户往往比裸 API 划算。

六、算算你自己的

打开你的用量面板，找到日消耗 Token 总量这个数字，然后到 成本计算器 里选场景、拖滑杆——input 比例和缓存命中率会按场景自动带入，也可以在高级选项里精调。 算完可以一键复制结果或链接分享。