codex周额度多少token

很多人问「Codex 周额度到底等于多少 token」，其实这不是一个能背下来的固定数：订阅额度是按额度单位算的，不是按 token 发的，折算结果取决于你用的模型、输入输出比例和缓存命中。这篇给一套自己动手算的方法：去哪看当期额度、去哪拿单价、怎么用日志倒推，最后给出一个可复用的估算区间思路，而不是一个会过期的数字。

问「Codex 周额度多少 token」的人，多半是想估一下：这一周我还能跑多少活、值不值得续。但这件事没法背一个数，因为订阅额度是按额度单位或 credits 发的，token 只是你调用的计量单位，中间隔着一层换算。同样一份额度，轻模型能跑出的 token 数可能是重模型的好几倍，所以真正靠谱的做法是自己动手折一遍。

下面给一套可复用的流程：先弄清你那一档的额度口径，再去站内拿当期单价，然后用自己一周的真实用量倒推系数，最后每隔一段时间核对一次。数字全部到站内页面看当时的，别用记忆里的旧值。

为什么没有「周额度 = X token」这个固定数

订阅额度通常以额度单位、credits 或请求次数计量，它和 token 之间是间接关系。平台给你的是「这周能消耗多少额度」，而不是「这周能发多少 token」。同一份额度，你用来写脚本、改 bug、跑长上下文分析，能撑住的 token 量完全不一样。

• 模型不同，消耗速率不同：轻模型和重模型跑同样一段对话，吃掉的额度差得远
• 输入输出比例不同：输出单价通常比输入高，输出占比越大，同样额度折出的 token 越少
• 缓存命中影响很大：命中缓存的部分计价方式不同，折出来的 token 数会明显变多
• 上下文长度和轮次：单次任务轮数越多、上下文越长，重复计费越重，折算越吃亏
• 当期口径会变：想知道这一档现在怎么写，去 Plus 档说明（/coding-plans/openai-codex-product-subscription-plus） 和 Codex 雷达（/codex-radar） 看当时的描述

折算前先凑齐三个数

动手之前先确认手上有没有这三个输入，缺一个都算不准。第一个是你这一档的周额度口径，第二个是对应模型的当期单价，第三个是你自己的输入输出比例。前两个去站内查，第三个只能从你自己的日志里抄。

把这三个数写在一张纸上或团队文档里。缺第三个的时候，可以先跑几天记录再回来算，别拿别人账号的比例硬套，任务类型不同差别很大。

四步倒推：把额度折成 token 的实操顺序

1. 算每单位额度约等于多少 token拿一周实际消耗的 token 总量，除以这一周用掉的额度比例，得到一个经验系数。注意是比例不是绝对额度，这样换档位时还能沿用一段。
2. 按输入输出拆开验证把系数拆成输入和输出两部分，分别乘当期单价，看折出来的金额和订阅费是否大致对得上。差太多说明比例或口径没对齐，回上一步重算。
3. 换模型换档位时重跑不要把这个系数乘倍数照搬。不同模型消耗速率不同，换了模型或档位就重新跑一遍上面的流程，尤其注意缓存命中率有没有变化。
4. 记账并定期回看把系数、算法和当天口径来源写进团队文档。过一阵去 价格追踪（/price-watch） 看单价有没有动，动了就按新价格重算系数。

这套流程的价值不在得出一个精确数字，而在于你随时能自己更新。数字会过期，方法不会。

什么情况下这套折算不适用

有些场景下折算本身就没什么意义，硬算反而误导判断。下面几类情况可以直接跳过这套方法。

• 按量计费的 API 用户：不用折额度，直接看用量页的花费
• 超长上下文或大量文件读取为主：上下文重复计费会把 token 折算严重拉偏
• 额度说明写的是按请求次数计量：按次数看更准，折算参考价值低
• 团队多人共用账号：个人系数不成立，要按合计用量另算一份

把折算结果用起来：一周一次的用量核对

算出来的系数如果只躺在文档里就没用。建议固定一个时间点，比如每周一上午，导出上周调用记录，按模型分组统计 token 与花费，然后去 用量页面（/usage） 对照一下公开的用量水平，看自己是不是跑偏了。

核对时重点看两件事。一是单位额度产出的 token 数有没有明显下滑，这通常意味着任务变重或缓存失效；二是有没有跑飞的重试或轮询，这类消耗不产生价值但照吃额度。发现异常先查重试和长上下文叠加，再去 刷新节奏页（/resets） 看额度重置是不是和你的排期错开了。

最后把结论压成一行记下来：本周折算系数、变化原因、下周要调整的动作。下次核对时直接对比，比每次从头算省事。