两种账单，两种形状
主机账单是容量。你加 CPU、带宽、存储，表针跟着流量曲线走；看过一个月，下个月能猜到几个百分点以内的误差。
token 账单是行为。两个流量完全一样的团队，账单可以差 20 倍——因为一个团队每次请求带 12,000 token 的检索上下文，另一个只缓存了 400 token 的系统提示、其余什么都不带。同样的用户、同样的功能，账单天差地别。
这不是定价的猫腻，而是计量方式决定的：你按 token 付费，而 token 数量是设计决策。
让花费变跳的三个效应
1. 输入通常远多于输出，两者单价还不一样。 在多数对话与检索功能里，输入 token 是输出的 5～20 倍，而输出 token 的单价往往是输入的几倍。所以「我们只生成一小段回答」这句话，对成本没有任何说明力。
2. 缓存输入是另一套费率。 供应商对重复出现的输入给更便宜的价格——固定的系统提示、不变的长文档、大段指令。忽略缓存，就等于每次请求都为同样的 3,000 token 付全价。
3. 每次请求的上下文能差一个数量级。 一个每轮都追加对话历史的总结任务，等于每次都把整份记录重新发一遍。成本增长比轮数更快：第 20 轮很贵，是因为第 1 到 19 轮又在账单上出现了一次。
重试和工具调用还会再加一个在任何用量图表里都看不见的乘数：一次失败后重试的调用会计费两次；每轮调四个工具的 Agent，每轮计费五次。
杠杆，按收益排序
团队的第一反应通常是去换模型。那很少是最大的杠杆。建议按这个顺序试：
- 先砍上下文。 删掉检索到却不影响答案的文档、限制回溯的历史长度、把永不变的部分放进缓存。这往往是单项收益最大的一步。
- 限制输出长度。 直接要求形状（「三条要点，不要前言」），而不是给一个宽松的 token 上限。模型生成的那 900 token 客套话，是你在付费。
- 不紧急的走批次。 夜间补数、回填、评测这类任务通常可以接受更慢但更便宜的路径。
- 最后才换模型。 把摘要任务降级到更小的模型确实是省钱——但这是在前面三步已经压小的那个数字上，再省一次。
上线前先估一遍
你需要每次请求的两个数字：输入 token 与输出 token。功能已经上线，就直接从 API 返回里读，不要估。还没上线，只能先猜：
每月成本 ≈ 每天请求数 × 30 × (输入 ÷ 1M × 输入单价 + 输出 ÷ 1M × 输出单价)
猜的时候有两个坑：一是平均数会掩盖最贵的那次请求（一份长文档的 p95 请求可能是中位数的 30 倍，而账单正是它决定的）；二是多轮功能让平均数失去意义，因为每一轮都拖着完整历史。
AI 成本计算器 用一份可编辑的费率表来完成这套算术：贴用量日志就按模型汇总，或者描述工作量（每次请求 token、每天请求数、缓存命中率、批次折扣）得到每次请求、每天、每月、每年的数字。对比页会把同一份工作量套到每一条费率上——这是判断「换模型到底值不值得迁」最快的方式。
订阅还是按量付费
这是个用量问题，不是方案偏好。如果你实测的每月 API 成本低于订阅价，那么订阅是你为方便多付的钱；如果远高于，通常订阅更划算——直到你撞上它的用量上限，而那是平衡点算不出来的另一个约束。
真正有用的输出是平衡量：按你自己的每次请求成本，每天要超过多少次请求，固定月费才开始划算。把它和你的实际流量放在一起看，这个决定就不再靠感觉。
关于数字的一句实话
价格会变、方案会变，而一个把价格写死在代码里的计算器，会在别人更新价格页的那一刻就变成错的。所以这个工具给的是示例占位值，要求你填自己账单上的费率；你的修改留在浏览器本地，不抓取、不上传、不在服务器上留缓存。
算术部分可以做到完全正确，费率部分只有你的账户能回答。
如果 AI 的输出还会进报表，另外两个工具处理相邻的问题：AI 数字核验器 标出找不到出处的数字，护栏生成器 则为编码 Agent 生成规则文件与权限清单，让它待在自己的车道里。