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

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

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

所以你看到：

1
2

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

通常是正常现象。

01 先记住结论

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

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

用伪代码表示就是：

1
2
3
4

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

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

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

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

每次 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。

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

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

1
2
3
4

本次消耗
≈ 输入 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 掉很多”，常见原因有这些：

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

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

• limit_window_seconds
• percent_left
• reset_at
• bucket / feature 名称

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

1
2
3
4
5

limit_window_seconds = 18000
=> 约 5 小时窗口

limit_window_seconds = 604800
=> 约 7 天窗口

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

07 更省额度的使用方式

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

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

最实用的记忆方式是：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

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

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

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

08 用 auth.json 本地检查额度窗口

如果界面只显示百分比、你又需要确认窗口长度和重置时间，可以在本机读取 ~/.codex/auth.json，请求 ChatGPT 当前使用的额度接口。这个方法使用的是非公开内部接口，不属于稳定 API：字段、路径和权限都可能变化，不能作为生产依赖。

使用前注意：

• 只在自己的电脑上运行，不要上传、粘贴或分享 auth.json。
• 脚本不会打印 token，但终端记录、调试代理和异常日志仍可能泄露凭证。
• HTTP 401 通常表示 access token 过期；403 表示账号或接口没有访问权限，不等于账号一定被封禁。
• 返回字段变化时先保存 raw JSON，再按 limit_window_seconds、percent_left 和 reset_at 判断窗口。

先安装依赖：

1

python -m pip install requests

将下面脚本保存为 codex_usage.py：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

import json
from pathlib import Path

import requests


auth_path = Path.home() / ".codex" / "auth.json"
auth = json.loads(auth_path.read_text(encoding="utf-8"))
tokens = auth.get("tokens", auth)
access_token = tokens.get("access_token")
account_id = tokens.get("account_id")

if not access_token or not account_id:
    raise SystemExit("auth.json 中缺少 access_token 或 account_id")

response = requests.get(
    "https://chatgpt.com/backend-api/wham/usage",
    headers={
        "Authorization": f"Bearer {access_token}",
        "ChatGPT-Account-Id": account_id,
        "Accept": "application/json",
        "Origin": "https://chatgpt.com",
        "Referer": "https://chatgpt.com/",
    },
    timeout=30,
)

if response.status_code in (401, 403):
    raise SystemExit(f"HTTP {response.status_code}: 凭证过期或无接口权限")

response.raise_for_status()
data = response.json()
print(json.dumps(data.get("rate_limit", data), ensure_ascii=False, indent=2))

运行：

1

python codex_usage.py

验收标准不是“请求返回 200”这么简单。还要确认输出里存在可识别的窗口长度、剩余比例和重置时间，并与 Codex 界面大致一致。字段缺失时不要猜测标签；内部接口无法访问时，以产品界面和 OpenAI 官方说明为准。

相关链接

• Using Codex with your ChatGPT plan - OpenAI Help Center
• ChatGPT Rate Card - OpenAI Help Center
• Codex rate card - OpenAI Help Center
• Using Credits for Flexible Usage in ChatGPT - OpenAI Help Center

2026 年 8 月应怎样理解额度和重置

OpenAI 当前给出的订阅额度是估算范围，不是每个账号都能稳定复现的固定消息数。local messages 与 cloud chats 共用 5 小时窗口，并且可能叠加周限额；模型、上下文、推理强度、工具调用、检索和缓存都会影响一次任务的实际消耗。

因此排查时只记录四项即可：使用的模型、任务是 local 还是 cloud、界面显示的 reset 时间、任务前后的剩余比例。不同账号或时段出现不同结果，不足以证明系统计算错误。

临时赠送的 reset、邀请奖励或故障补偿属于活动额度，不应写成长期套餐承诺。界面出现重置入口时，先看资格和有效期；没有入口时不要通过反复登录、创建账号或第三方脚本规避限制。购买 credits 也不等于永久提高订阅窗口，它只是为支持的功能提供额外按量使用空间。

Fast mode 会以更高速度处理支持的模型，同时更快消耗 credits。需要控制预算时，应以“每个成功任务的总成本”比较模型和速度，而不是只比较单条消息。