写着写着发现额度不够用，或者月底账单比预期高出一截，多半不是模型涨价，而是从没认真估过自己一个月到底烧多少token。这篇给一套可执行的估算法：先拆日常动作，再套用量模板，最后落到限额、告警和复盘节奏上，让你在充值和续费前心里有个数。
月底账单比预期高，第一反应往往是「是不是模型涨价了」，但多数时候是你从没认真估过自己一个月到底烧多少。额度不够用、续费前心里没底，本质都是同一个问题：没有把日常动作换算成量级的习惯。
这篇不讲概念，给一套能直接抄的估算法：先把一天的编程动作拆成几类，再套一张按月估算的模板，然后用两周真实记录去校准，最后落到限额、告警和复盘节奏上。全程不需要你提前知道任何单价，具体折算金额去站内工具页看当时的数字就行。
为什么估不准：三个常见误区
估不准通常不是因为你算错，而是计量单位从一开始就选错了。先把这三个坑避开，后面的模板才有意义。
- 把「一次对话」当成一个计量单位：编程任务几乎都是多轮的，每一轮都会把之前的上下文重新发一遍，一句话追问背后的实际输入量可能是首次提问的好几倍
- 只算一边：只盯输入忽略输出，或只盯输出忽略缓存重写，两种都会让量级差出一截，尤其是长上下文任务
- 按最贵的那档模型估全部任务：算出一个自己都不敢看的数字，最后干脆不估了，这等于放弃了预算控制
把一天的工作拆成几类动作
不要按「问了几次」统计，按动作类型分。不同类型的单次量级差很多，混在一起算必然失真。下面这四类是大多数开发者的日常构成。
- 补全与改写
- 单次很小但次数最多，构成基数而不是大头，适合用轻档模型
- 解释与排错
- 贴代码、贴报错、来回追问，轮次多，上下文反复重发，累计量容易被低估
- 生成新代码
- 一次产出较长，输出占比高，改成结构化输出后重试次数通常会下降
- Agent 类任务
- 读写文件、跑命令，一轮任务里藏着很多次请求，是四个分类里最容易估少的
判断标准很简单：如果某类动作你一天想不起来做了几次，那它大概率不是大头；如果某类动作你做了很多次但每次都觉得「很快」，那它更值得单独拉一行统计。
一张按月估算的用量模板
把上面四类动作填进一张表，四列就够。关键原则是：先填量级，不填精确数。精确数留给后面两周校准阶段去替换。
| 动作类型 | 日均次数 | 单次量级 | 每月工作日 |
|---|---|---|---|
| 补全与改写 | 最高，常以几十计 | 小 | 按你的实际出勤填 |
| 解释与排错 | 中等 | 中到大，取决于贴多少上下文 | 同上 |
| 生成新代码 | 较低 | 大，输出占比高 | 同上 |
| Agent 类任务 | 低但单轮请求多 | 波动最大 | 同上 |
单次量级先用小/中/大三档相对表示，别急着折算金额。真要换成人能理解的成本数字，去 /tools/token-price-calculator 用当时的单价换算。还可以再留一列「估算置信度」，把 Agent 这种波动大的行标记成低置信度，后面用实测覆盖。
用真实记录替换猜测：两周校准法
模板只是骨架，真正让估算变准的是实测。做法是先正常用两周，只记录不调整，拿到属于你自己的真实分布，再去改模板。
- 正常用，先别优化这两周按平时习惯工作，不要刻意省着用，否则拿到的分布不代表真实情况。
- 对齐用量日志用客户端或网关的用量记录导出，注意区分输入、输出和缓存部分，字段口径可以先到 /usage 对照一遍，避免把三者加混。
- 找出最高的一类按动作类型汇总，挑出用量占比最高的那一类。优化它通常比优化其他所有项加起来都有效。
- 换算月度基线把两周实际值乘以工作周数，得到月度基线，再乘一个安全系数留出波动空间。
估算的价值不在于一次算准，而在于每个月都比上个月更接近真实值。
不降体验的四个省钱动作
省钱不等于降配。下面四个动作的共性是：几乎不影响你的开发体验，但能明显压住用量曲线。
- 按任务切模型：机械改写、格式化这类任务用轻档即可，复杂推理才上高配，路由思路可参考 /ai-nav/category/ai-api 里的分类
- 控制上下文长度：长对话定期开新会话，或先做摘要压缩，别把整个仓库代码一直挂在上下文里跑
- 减少无效重试：报错先读懂代码含义再改提示词，盲目重抽是最贵的习惯，它同时消耗输入和输出
- 利用缓存命中：把固定前缀、固定系统提示放在最前面，重复部分更容易命中，注意前缀一旦变动命中就可能失效
判断顺序建议从后往前：先看能否命中缓存，再看重试是不是太多，再看上下文有没有拖长，最后才考虑换模型档位。前三个改完往往就够了。
订阅额度还是按量付费：先对齐口径
很多人比较套餐和按量时直接拿「次数」乘「单价」，结果得出错误结论。问题在于各家对「额度」的定义不一样，有的按次数、有的折算成金额，口径都不同。
| 你的使用特征 | 倾向哪种计费 | 原因 |
|---|---|---|
| 用量稳定且持续偏高 | 订阅类套餐 | 预算固定，省心 |
| 用量波动大、集中在赶工期 | 按量付费 | 不为闲置时段买单 |
| 前期不确定自己的用量 | 先按量实测两周 | 拿真实数据再决定 |
把套餐额度折算成可比的量，再和按量路径放在一起看，折算方法可以去 /coding-plans 看当时的说明。决定前记得用真实任务跑几天，别拿演示任务的数字下结论。如果你还关心不同中转路径的差异，可以顺带对照 /price-watch 的走势。
把跑飞限制在一晚以内：限额与告警
估算解决的是「心中有数」，限额解决的是「跑飞了也不至于太惨」。Agent 类任务尤其需要这一层，因为它会在你离开电脑之后继续发请求。
- 按人分 Key团队里每人一把独立 Key，不要共用。共用会让用量无法归因，出了问题也找不到是谁。
- 设两条线一条预警线，到了提醒你去看用量；一条硬停线，到了直接掐断。两条线之间留出你能反应的时间。
- 给 Agent 加双重上限除了额度上限，再加步数上限和单任务预算上限，具体做法参考 /agent-runaway-guardrails 里的清单。
- 留出缓冲限额别设太贴，否则正常开发中途被打断比多花一点更烦。缓冲大小可以根据你两周校准的波动幅度来定。
月度复盘：十分钟做完的三件事
复盘不需要开长会，十分钟三件事就够。关键是固定节奏，每月做一次，估算误差会逐月收敛。
- 比对账单与记录：看实际扣费和你估算的差在哪一类动作，差异通常集中在少数几类，不会均匀分布
- 更新模板量级：把猜测值替换成实测值，低置信度的那几行优先更新，下个月误差会明显变小
- 只改一条策略：换模型档位、改工作习惯或换计费方式，三选一只改一样，这样下个月才能判断到底是谁起了作用
如果某个月用量突然跳升，先别急着换方案，去查那一次是不是有 Agent 类任务跑飞，或者上下文被拖得异常长。多数突增都能在记录里找到单点原因。
先把工具页存下来估算需要真实数字支撑。把 /tools/token-price-calculator 和 /price-watch 存进书签，下次充值或续费前先去核对当时的数字，比凭印象拍脑袋可靠得多。→常见问题
我就是个普通开发者，一天写几小时代码，大概什么量级？
没法给统一数字，取决于你用补全还是整段生成、是不是频繁贴大文件。稳妥做法是先正常用两周，去 /usage 看真实记录，再乘工作周数。凭感觉拍的数字往往偏差很大，尤其是带了 Agent 类任务的情况。
为什么我按对话次数估的，和实际账单对不上？
因为计费单位是 token 不是对话次数。同一句话，带上下文重发的输入可能远大于你新写的那句，缓存读写还有单独的口径。先分清输入、输出、缓存三项，再回 /tools/token-price-calculator 换算，对不上的部分通常就在 Agent 或多轮追问上。
省 token 是不是就意味着用差一点的模型？
不是。多数人的浪费在上下文重复和无效重试上，先把这两项处理掉，再考虑按任务分档。真正需要强模型的推理任务不要降档，降了反而要重试更多次，总花费未必低。判断标准看任务类型，不看单价。
订阅套餐是不是一定比按量便宜？
看你的用量形态。用量稳定、天天在写的人，套餐往往更划算；用量忽高忽低、或者只在项目冲刺期密集使用的，按量更灵活。另外各家套餐的额度口径不一致，得先折算成可比的量再比，参考 /coding-plans。
团队多人共用，怎么估总量？
不要用一个人的用量乘人数。按角色分开估：写业务代码的、做数据处理的、跑 Agent 批任务的，三者消耗结构差别很大。分 Key 分开记，再看谁的额度先到顶。共用一把 Key 既估不准也说不清责任。
