打算把 Codex 当日常开发工具，却说不清一个月到底要准备多少预算——这是很常见的情况。难处不在单价，而在你根本不知道自己一个月会跑多少轮任务，同时订阅制、按量 API、中转渠道的计费口径又各不相同。这篇不讲单价数字，只给一套可复用的估算流程：把开销拆成几层、用什么指标估用量、到哪里核对当期价格，以及估算在什么情况下会失准。
打算把 Codex 当日常开发工具，第一个冒出来的问题往往不是「好不好用」，而是「一个月大概要准备多少预算」。这个问题之所以难回答，不是单价藏得深，而是你根本不知道自己一个月会跑多少轮任务。有人一周就改几个小脚本，有人天天做大范围重构，同样一个工具，账单能差出好几倍。
更麻烦的是计费口径不统一：订阅制按席位收固定费用，纯 API 按 token 走量，走中转渠道还要再叠一层倍率折算。三种口径下「一个月多少钱」根本不是一个算式。这篇不报单价，只给一套可复用的估算流程：把开销分层、用自己的历史记录倒推用量、到站内核对当期数字，最后留出波动余量。照着走一遍，你至少能拿到一个靠谱的预算区间。
为什么「一个月多少钱」这个问题很难直接回答
同一个问题问三个人，可能得到三个完全不同的答案，而且都没错。原因在于付费方式本身就是分叉的：订阅按席位算，用不用都在扣；API 按 token 算，写多写少差别巨大；中转按倍率折算，同一份用量在不同渠道结出来的账不一样。你不说清自己走的是哪条路，谁都给不了一个有意义的数字。
| 计费口径 | 花多少由什么决定 | 估算时的坑 |
|---|---|---|
| 订阅制 | 席位数 + 档位额度 | 额度用超后的部分才是真正变量 |
| 按量 API | 输入输出 token 总量 | 输入和输出单价口径常常不同，别混算 |
| 中转渠道 | 官方价 × 渠道倍率 | 倍率会随渠道调整，历史账单不能直接沿用 |
- 很多人拿别人的账单当参考，但任务类型和代码库规模完全不同，参考价值很有限
- 只看月总额而不看构成，超标了也不知道是套餐选错还是用量跑飞
- 把试用期的一次性额度当成常态，下个月账单直接翻脸
先把每月的钱拆成四层
别一上来就盯着总价，先把开销按性质拆开。拆开之后你会发现，真正波动的只有其中一层，其余三层基本是可预期的固定项。这样估算就从「猜一个数」变成了「固定项加浮动项」，难度降一大截。
- 订阅层
- 为使用资格付的固定费用，不管这个月用不用都在扣，属于刚性支出
- 用量层
- 超出套餐额度后按量计的部分，或者纯 API 调用产生的那部分，是唯一真正浮动的一层
- 杂项层
- 汇率折算、支付通道手续费、代理或中转的额外加价，单笔不大但每月都在发生
- 周边层
- 为跑 Codex 顺带开的编辑器、云主机、存储等，最容易被漏算
四层里最该盯的是用量层，但最容易出事的是周边层。很多人的实际支出超出预期，不是因为主力工具贵，而是几项小开销长期没被计入。建议第一次估算时把四层都列出来，后面每月只看用量层的变化就行。
估用量：用你自己的历史记录倒推
用量没法凭空猜，但可以从你自己的使用痕迹里倒推。最土也最有效的方法：记录一周的真实使用，数清任务轮数和每次大致读写的代码量。一周样本不够准，但足够定出一个量级，后面再按月修正。
- 记一周流水每完成一次 Codex 任务就记一行：任务类型、涉及文件数、大致耗时。不用精确到 token，能分清大小就行
- 按类型分组把「大重构」和「改个小 bug」分开统计。两者消耗量级不同，混在一起取平均没有意义，会把估算带偏
- 算出周均值再乘系数周均值乘以月份周数得到粗估，然后留一个区间而不是一个点值。估算预算时按区间上限准备
- 月底回填校准实际账单出来后和估算对一遍，看偏差出在哪一类任务上，下次估算时针对性调整系数
把你的用量映射到具体方案上
有了用量画像，下一步是把它对上具体方案的额度节奏。这里的关键不是比较额度总量，而是比较节奏：你的使用是低频持续型，还是集中在某几天的高频爆发型？两种节奏适合的方案方向完全不同。
| 使用画像 | 特征 | 选方案时先看什么 |
|---|---|---|
| 低频持续型 | 每天都用一点，单次任务不大 | 看刷新周期和额度能否攒住 |
| 高频爆发型 | 平时不用，一做大任务就集中消耗 | 看短期额度上限和超额计价 |
| 团队共用型 | 多人共享额度，个人用量被摊薄 | 看席位规则和用量是否可见 |
套餐的额度口径、刷新周期与重置规则，到 /coding-plans 对照当时的说明。特别要关注超额度之后怎么算——用超之后的价格才是真正决定你月花费的部分，而不是套餐本身的标价。
- 先确认额度是自然月重置还是滚动刷新，这直接影响你的使用节奏安排
- 确认超额是按量继续扣还是直接降级到慢速档，两种体验差很多
- 确认额度是否区分输入输出，有些方案两边的计算方式并不一样
- 如果有团队共享需求，确认席位是否独立计量，避免一人跑飞全组受限
去哪里核对当期数字
价格是会动的，任何写死在文章里的数字过几天就可能失效，所以这里只给核对路径，不给数字。判断当天实际单价，一律以站内页面为准。
| 你要核对的项 | 去哪看 | 看的时候注意 |
|---|---|---|
| 官方按量单价 | /official-api | 输入输出口径可能不同，别只看一个数 |
| 订阅与编程套餐额度 | /coding-plans | 重点看超额规则和刷新周期 |
| 中转渠道可信度 | /sites 与 /tools/verify | 先确认可信再看价格，顺序不能反 |
走中转渠道的人尤其要注意顺序：先到 /sites 和 /tools/verify 确认渠道可信度，再谈价格。一个报价再低但中途跑路的渠道，摊到月成本上反而是最贵的。价格本身的波动可以盯 /price-watch 看趋势。
预算怎么留余量：把波动算进去
估出来的数字不要直接当预算用，那只是一个中间结果。真实月份里总会有几周任务格外重，或者临时要赶一个重构，用量会明显偏离均值。预算的作用不是精确预测，而是保证超了也不慌。
- 按上限加缓冲拿估算区间的上限再乘一个缓冲系数，把超出的部分当成安全垫，而不是指望不会超
- 设用量告警在方案侧开用量提醒，或者在月中做一次自查，别等到月底账单出来才发现跑飞
- 准备备选路径主力方案额度用尽时切到哪个接口，提前想好并测通一次，避免临时抓瞎
- 每月复盘一次把实际用量和估算对一遍，连续两三个月后你的估算会明显变准
这套估算什么时候不适用
没有任何一套估算方法能一直有效，明确它的失效边界比记住步骤更重要。下面几种情况下，历史数据参考价值会明显下降，需要重新估。
- 任务类型突然变化，比如从写小脚本变成大规模重构，用量量级会跳一个台阶
- 团队多人共用同一账号，个人估算模型不成立，要按人均重新分摊再估
- 渠道价格调整期，估算结果的有效期很短，需要重新到站内核对数字
- 刚开始用还没积累出一周以上样本，此时只能先按偏保守的上限准备
遇到这些情况，不用推翻整套流程，只需要把出问题的那一层重新估。比如只是任务类型变了，就回到估用量那一步重记一周；只是渠道调价了，就回站内重新核对当期数字。分层的好处就在这里，改一层不用动全局。
月花费不是一个能查到的数字，而是一个需要你自己估出来的区间。下一步先去核对当期套餐额度与超额规则，再拿你上周的真实使用量对一遍，就能得到属于自己的预算区间。→
常见问题
只想个人用，一个月大概要按什么量级准备预算？
没法给一个通用数字，因为差异主要来自你的任务强度而不是工具本身。建议先按上面流程记录一周真实用量，再乘到整月并留出余量。当期各档的实际价格和额度，到 /coding-plans 和 /official-api 核对最准。
订阅和按量 API，哪个更适合长期用？
看你用量是否稳定。使用节奏平稳、每月消耗接近，订阅更容易控预算；用量忽高忽低或者集中在某几周，按量更不容易浪费。判断标准和适用边界，参考 /guides/billing-models-compare 里的对比口径。
估算出来的钱和实际账单差很多，正常吗？
很常见，差距一般来自三处：缓存与否影响实际计价、输入输出计价口径不同、以及渠道的倍率折算。如果账单长期高于预估，先去看 /guides/token-cost 把计价口径对齐，再回头看你的用量记录。
用量突然涨上去了，一般是什么原因？
先排查任务类型变化、上下文变长、以及是否发生过失败重试。这三个方向在 /guides/long-context-cost-spike 和 /guides/retry-cost-checklist 里有拆解，比盲目换方案更有效。
走中转渠道是不是一定更便宜？
不一定。中转的倍率、额度折算方式、超量后的价格都与官方不同，有的还夹着汇率和手续费。省不省取决于你的量级和渠道质量，选之前先到 /sites 看目录、用 /tools/verify 实测，别只看标价。
