Codex 额度怎么算：5 小时限额、周限额和 Credit 消耗

Wed, 15 Apr 2026 22:50:00 +0800

很多人第一次看 Codex 额度时，会以为 5 小时限额 是一个短期余额池，只有它用完之后才开始扣 周限额。

实际不是这样。Codex 更像是同时检查多个额度窗口：短窗口防止短时间爆量，周窗口限制一周总量。一次 Codex 使用通常会同时计入这两个窗口。

所以你看到：

1
2

5 小时额度还剩很多
但 weekly 额度已经下降

通常是正常现象。

01 先记住结论

Codex 额度可以先按下面三句话理解：

5 小时限额 和 周限额 是同时生效，不是先后扣除。
周限额用完后，即使 5 小时额度还有，通常也不能继续用同一个订阅额度池。
Codex 不是简单按消息条数计费，而是和模型、tokens、任务复杂度、上下文、执行位置有关。

用伪代码表示就是：

can_use_codex =
    five_hour_remaining > 0
    && weekly_remaining > 0
    && 没有触发其它产品策略限制

5 小时窗口重置，只恢复 5 小时额度；不会恢复 weekly 额度。weekly 额度要等自己的 reset，或者在支持的计划里购买额外 credits。

02 为什么会同时扣两个窗口

可以把 Codex 的额度想成两个闸门：

窗口	作用
5 小时窗口	防止短时间高频使用
周窗口	控制一周总使用量

每次 Codex 任务都会产生一次实际消耗。这个消耗会反映到当前相关的 rate limit 窗口里。

因此不是：

1
2
3

先扣 5 小时额度
5 小时额度用完后
再扣周额度

而更像是：

1
2
3

一次 Codex 请求
=> 计入 5 小时窗口
=> 同时计入周窗口

这就是“5 小时额度没用完，但 weekly 也在下降”的核心原因。

03 当前更应该看 token-based credits

OpenAI 没有公开一个用户可以完全复算的 Codex 扣费公式。官方公开的是 rate card、影响因素和不同模型的 credit 单价。

截至 2026-04-15，Codex rate card 的主口径已经是 token-based credits。也就是根据输入 tokens、缓存输入 tokens、输出 tokens 折算 credits。

官方给出的示例价格如下：

模型	输入 / 1M tokens	缓存输入 / 1M tokens	输出 / 1M tokens
GPT-5.4	62.50 credits	6.250 credits	375 credits
GPT-5.4-Mini	18.75 credits	1.875 credits	113 credits
GPT-5.3-Codex	43.75 credits	4.375 credits	350 credits
GPT-5.2-Codex	43.75 credits	4.375 credits	350 credits
GPT-5.1-Codex-Max	31.25 credits	3.125 credits	250 credits
GPT-5.1-Codex-mini	6.25 credits	0.625 credits	50 credits

所以一个粗略估算公式是：

本次消耗
≈ 输入 tokens / 1,000,000 × 模型输入单价
+ 缓存输入 tokens / 1,000,000 × 模型缓存输入单价
+ 输出 tokens / 1,000,000 × 模型输出单价

这不是精确账单公式，但足够解释趋势：输出很贵，长上下文很贵，高能力模型更贵。官方还说明 Fast mode 会消耗 2 倍 credits，Code review 使用 GPT-5.3-Codex 的价格。

04 不要再只看“消息条数”

同样发 10 次 Codex，消耗可能完全不同。

轻量任务通常更省：

改一个小函数
解释一段短代码
写一小段文案
在明确文件里做局部修改

重任务会更贵：

扫描大型代码库
长时间运行 agent
多轮读取、编辑、测试、修复
生成大量代码或长报告
使用 cloud task
开启 fast mode

因此，消息数量 只能作为很粗的感觉，不能用来判断真实消耗。

05 local task 和 cloud task 的差别

Codex 里很容易拉开消耗差距的是执行位置。

local task 更像是在你的本地工作区里读文件、改代码、跑命令。cloud task 则把任务交给云端环境托管执行，适合更长、更自动化的流程。

从额度角度看，cloud task 往往更贵。原因也很直接：

需要云端执行环境
任务通常更长
工具调用更多
上下文更大
自动化链路更完整

如果只是普通代码编辑、文章整理、局部修复，优先 local task 会更省。cloud task 更适合确实需要云端托管的任务。

06 为什么 weekly 掉得特别快

如果你觉得“5 小时额度没怎么动，但 weekly 掉很多”，常见原因有这些：

使用了 cloud task。
使用了更贵的模型。
开启了 fast mode。
上下文很大，Codex 读了很多文件或保留了很长对话。
输出很长，比如大量代码、长报告、长日志分析。
任务链很长，比如搜索、编辑、测试、修复、再测试。
自己的额度脚本把窗口标签解析错了。

如果你是用脚本读 /backend-api/wham/usage 之类的字段，不要只看加工后的 five_hour%、weekly%。最好先看 raw JSON 里的：

limit_window_seconds
percent_left
reset_at
bucket / feature 名称

常见窗口长度可以这样判断：

limit_window_seconds = 18000
=> 约 5 小时窗口

limit_window_seconds = 604800
=> 约 7 天窗口

如果脚本把两个窗口标反，就会误判额度变化。

07 更省额度的使用方式

想让 weekly 撑得久一点，可以这样用：

把大任务拆成小任务。先处理一个文件、一个 bug、一个功能点。
能 local 就 local，谨慎使用 cloud task。
明确告诉 Codex 相关路径，减少无关扫描。
避免一次塞入巨大日志、长文件、无关上下文。
轻量任务可以用更便宜的 mini 模型。
长任务前先让 Codex 出计划，再进入执行。
不需要长报告时，明确要求“简短回答”。

最实用的记忆方式是：

是否能继续用
= 短窗口还有额度
&& 周窗口还有额度

消耗快不快
= 模型价格
× tokens
× 输出长度
× 任务复杂度
× 执行位置

这个模型不能精确对账，但足够解释大多数 Codex 额度现象。

使用限制 on KnightLi的博客