ChatGPT的codex价格

你可能是这样卡住的：想用 Codex 写代码，翻了一圈只看到订阅档位，算不出自己一个月大概要花多少；又或者已经开了某个档，月底发现额度早早见底，不知道该升档、还是干脆切到 API 按量。这篇不给你背数字，而是给一套拆账顺序——把订阅费、额度折算、超量后的按量口径分开算，最后落到「我这个用量该选哪条路」的判断上。所有当期数字都指到站内对应页面去核对。

你可能是这样卡住的：想用 Codex 写代码，翻了一圈只看到订阅档位，算不出自己一个月大概要花多少；又或者已经开了某个档，月底发现额度早早见底，不知道该升档、还是干脆切到 API 按量。这篇不给你背数字，而是给一套拆账顺序——把订阅费、额度折算、超量后的按量口径分开算，最后落到「我这个用量该选哪条路」的判断上。

所有当期数字都别信截图、别信别人转述，直接去站内对应页面核对当时的报价。下面每一节都会告诉你该去哪个页面看什么，你照着走一遍，就能得到属于自己用量的那笔账。

先分清：Codex 的钱分两笔，别混着算

很多人一上来就问「Codex 一个 token 多少钱」，这个问题在订阅制下其实不成立。订阅制下你付的是一段时间内的额度包，不是按 token 结算；只有在按量制下，才真的存在一条一条计费的单价。先把这两件事分开，后面才不会算歪。

订阅口径

付的是「一段时间内的额度包」，费用固定，用多用少一个价，超了受额度限制

按量口径

按实际 token 用量结算，单价随模型档位和输入输出方向不同，用多少付多少

折算口径

把订阅额度按你的用法折成 token 量，再拿它跟按量报价比，这是唯一能横向对比的办法

最常见的算错方式，就是拿订阅月费除以自己这个月的实际用量，得出来一个「每 token 价」，然后拿去跟按量单价比。这两个数字根本不是一回事：一个是摊销出来的平均数，一个是你下一笔调用的真实边际成本。要比，就用折算口径，把订阅额度先换成 token 量。

• 先确认你打算走订阅还是按量，再开始算，两条路不要交叉记账
• 按量单价去 /official-api 核对当时的数字，别用记忆里的老价
• 订阅档位额度去 /coding-plans 下对应档位页核对，别用别人截图
• 两个数都拿到之后，用同一套用量样本去比，样本不一致结论就没意义

订阅档位怎么对：先定工作量，再挑档

挑档位不是「用得多就买贵的」。档位之间真正的差别在两块：一是额度上限，二是并发和功能上的差异。你要先估的是自己每周大概跑多少轮编码任务，再看哪一档的额度能兜住它，而不是先看价格再倒推用量。

1. 估每周任务轮次回想最近一周你让模型参与了多少次编码任务，一次任务算一轮，别把一轮里的多次追问拆开算
2. 估单轮上下文长度大致分三档：只贴一小段代码的算短，贴文件加报错的算中，带仓库结构或长文件的算长
3. 对档位拿「轮次 × 上下文档位」去 /coding-plans 下对应 Codex 档位页对额度，看你落在哪一档内、有没有明显溢出
4. 对地区价同样的档位在不同地区月费不一样，开之前先在 /plans 对一遍你所在区的实际月付，别按别人的价做预算

有一个常见误区：看到别人说某档「很划算」就直接开。划算不划算是相对你的用量说的，同样的档位，一个人刚好填满，另一个人只用了一小半，结论完全相反。所以先估工作量，再挑档。

额度折算成 token：怎么把你的用量换算进去

折算的目的不是精确到个位，而是让你能拿订阅额度跟按量报价放在同一把尺子上比。编程类任务一轮的 token 消耗波动非常大，同一个问题换个问法可能差好几倍，所以估区间比估点值有用得多。

1. 取样本连续记录 5 到 7 个工作日，只记两件事：当天任务轮次、单轮的大致上下文长度
2. 算均值把样本里的轮次和上下文长度各自取个平均，不要用最高那天当基准，容易高估
3. 乘到月度按每月大约 22 个工作日折算，得出一个月度区间
4. 加缓冲区间的上界再往上留三成，用来吸收长任务和重试带来的额外消耗
5. 去核对拿这个区间去 /coding-plans 对额度，同时去按量计算器跑一遍对比

有几个因素会让同样的任务消耗差出好几倍：缓存是否命中、上下文是不是越堆越长、有没有带仓库索引。这些口径在 /guides/token-cost 里讲得比较细，这里不重复，你只要知道折算时要给它们留余量就够了。

编程场景为什么特别费：把消耗来源列清楚

写代码的调用不是一问一答。一轮任务里，模型可能反复读文件、改文件、跑工具、看报错、再改，token 是被这一串步骤叠加吃掉的。所以「我明明只问了一个问题」和「账单上怎么这么多」这两件事并不矛盾。

• 多步操作叠加：读文件、写文件、跑命令、重试，每一步都在消耗
• 上下文滚雪球：会话越长，后面每一轮都要把历史重新带上，成本不是线性的
• 任务粒度差异：改一处小 bug 和整仓库重构，量级根本不在一个档
• 重试成本：报错后反复调整，实际消耗往往比你预估的多出一截

什么情况下这条判断不适用？如果你的用法始终是「单轮、小上下文、不带工具调用」，那消耗基本是平的，上面这些叠加项对你影响很小，按轮次估就够了，不用纠结折算。

订阅还是按量：什么情况下选哪个

这两条路没有绝对优劣，只有适不适合你的用量形态。订阅适合用量稳定、不希望每次调用都盯账单的人；按量适合用量波动大、或者想把成本挂到项目账上的人。真正的分界线是：你的月用量能不能稳定填满一档订阅额度。

如果拿不准，别急着做长期决定。先用按量跑两周，把真实用量数据拿到手，再拿这个数据去对订阅额度。填得满就换订阅，填不满就继续按量，中间地带可以先用低档订阅加按量兜底。

• 填不满一档额度：留在按量，别为了「可能用得上」先交月费
• 刚好填满：订阅更省心，成本也更好预测
• 经常溢出：要么升档，要么把长任务单独切到按量
• 用量按项目走：按量更好分摊，订阅不好拆账
• 团队多人共用：先看额度是否共享，再去 /coding-plans 确认规则

一套可复用的月度估算步骤

下面这套流程你每个月都可以跑一遍，换模型、换档位、换项目都不影响。核心思路是：先用真实样本估出自己的用量区间，再拿区间去套两条路，最后比较差额。

1. 记样本连续记录 5 到 7 个工作日，只记每天任务轮次和大致上下文长度，别追求精确
2. 乘月度按 22 个工作日折算成月度区间，上界留三成缓冲
3. 对订阅拿区间去 /coding-plans 下对应档位页，看落在哪一档额度内、有没有溢出
4. 对按量拿同一个区间去 /tools/model-cost-calculator 跑一遍按量口径
5. 比差额两边差得越明显越容易选，差得不多就选自己更省心的那条

这套流程有个前提：你的用量是相对稳定的。如果你这个月几乎没怎么写代码、下个月又要赶一个大项目，样本就不代表未来，这时候更稳的做法是先用按量，等项目结束再决定要不要转订阅。

开完之后怎么盯：别只看月底账单

选完路之后，真正的省钱动作在过程里。用量超支的典型信号不是平稳上涨，而是某几天突然拉高——通常对应着几个长上下文的大任务。每周看一次用量曲线，比月底才发现问题强得多。

• 每周看一次用量走势，重点关注有没有突起的几天
• 额度快到上限时，先砍长上下文任务，再考虑临时切按量
• 临时切按量只用于救急，别常态化，否则两条路都算不清
• 小改动坚持用低档位跑，把额度留给真正难的任务
• 每月复盘一次：哪几天花得最多，那天的任务类型值不值得

判断顺序很重要：先砍任务、再切口径、最后才谈升档。很多人一遇到额度不够就升档，结果升完之后长任务照旧，只是把超支的时间往后推了一点。价格追踪和各家方案变动可以看 /price-watch，但别把它当成实时账本，它反映的是当时的公开报价。