Codex 周限额耗尽怎么办：7 种修复方案、限额机制和替代 API（2026）

如果出现的是账号停用通知，而非限额用完，请先按ChatGPT / Codex 账号封禁排查与申诉步骤判断；等待限额重置不能解除账号停用。

摘要

$20 Plus 套餐的 Codex 周限额，被一次长重构就可以在三小时内打空；而重置时间不是你能算出来的时钟规则，它是服务端下发的一个 resetsAt 时间戳，CLI 只负责显示。

限额触顶后你有两条路：等待滚动重置（Plus 每 5 小时滚一次，周限额按周重置），或者把 Codex CLI 的 OPENAI_BASE_URL 切到按 token 计费的 API。本文给你 30 秒诊断方法、Plus 和 Pro 的精确数学题，以及 7 种从「今天还能继续用 ChatGPT」到「60 秒切到按量 API」的具体修复方案。

Codex 挂了，还是你的周限额被打空？30 秒诊断

在切换供应商之前，先确认是哪个窗口爆了。在任何打开的 Codex CLI 会话里跑：

codex /status

输出会显示三个数字。对照下表：

如果 /status 显示容量正常但仍然看到 You've hit your usage limit. To get more access now, send a request to your admin or try again at 3:51 PM，那就是 #19215 幻象限额 bug（2026 年 4 月 23 日在 Codex CLI v0.124.0 上报告）。直接跳到方案 #4。

常见 Codex 报错文案 → 原因 → 修复

Codex 打印出的字面文案是分诊最快的依据，对应到下表：

什么时候修限额，什么时候直接切到按量 API

不是所有限额触顶都值得绕开。把你的处境对到下面的规则：

继续修现有套餐的限额。 本周第一次触顶，/status 显示是正常限额（不是幻象 bug），手上跑的任务接近收尾、不是新开一个多小时的 agent 循环。OpenAI 会给账号发放可兑换的 reset credit，你手上可能正好有一个还没花（机制见下面「能提前重置 Codex 的限额吗」一节）。

直接切到按 token 计费的 API。 每个月超过两次打满周限额，agent 工作流单次会话动辄 30 万+ 输入 token，需要每个任务有可预估的成本（比如给客户报价），或者在 CI 和共享开发环境里 —— 分层 ChatGPT 鉴权本来就不适合。

停止规则。 如果 /status 显示剩余容量充足、当天只触顶一次，什么都别做。5 小时滚动窗口会自动恢复，为一次偶发问题切换供应商是过度工程。关掉这个 tab 写代码去。

解读 Codex 限额：套餐、窗口、各档实际能给到什么

Codex CLI 继承的是当前鉴权路径的限额。三个订阅档位和 API 路径各有不同的上限。

订阅档位的 5 小时消息上限

ChatGPT 订阅档位通过滚动 5 小时窗口里的消息数对 Codex 使用做限流，而不是 token。公布的区间很宽，因为每条「消息」会按模型和任务复杂度加权。

来源：OpenAI Codex rate card 和 Codex 定价文档，数据在 2026 年 6 月 15 日核对。Plus（15-80）和 Pro 20x（300-1,600）有第三方社区报告佐证；Pro 5x 的 75-400 区间目前只来自官方 rate card，撰稿时尚无第三方交叉验证。

宽区间（如「15-80」）反映 OpenAI 会根据平台总负载和个人使用模式动态调整上限。区间下限就是繁忙时段你能实际拿到的数。

周限额机制

周限额叠加在 5 小时窗口之上。周限额从你本周第一条消息开始，以 7 天滚动重置。两个窗口独立计算 —— 数学问题就在这里。

GPT-5.5 上一次多文件 agent 循环（输入重型：约 25 万 token / 输出约 2.5 万）在 5 小时口径上大约等价 30-40 条消息，但在周窗口上算一次「会话」。Plus 用户连跑 2-3 次重型重构就足以打空周限额，而 5 小时计量盘可能还显示 30%+ 剩余。

API key 路径（无消息上限）

如果 OPENAI_API_KEY 以 sk- 开头且是普通 API key，Codex CLI 完全绕开订阅档位上限。按 token 走 API 定价表，无周消息上限，只受你在控制台设置的支出上限约束。这是应对周限额触顶最干净的方案，下面给出具体数学。

为什么一次 agent 循环就能打空一整周

Codex 周限额不直观的点在于：它不和 /status 看到的消息数成线性关系。OpenAI 的 Codex 定价文档 给出了 credit 的底层算法：

• GPT-5.5 每 1M 输入 token 消耗 125 credit、缓存 12.50、每 1M 输出 750
• GPT-5.4 是 62.50 / 6.25 / 375
• GPT-5.4 mini 是 18.75 / 1.875 / 113

一次 GPT-5.5 的 agent 循环读 30 个文件（约 25 万输入 token）、产出 2.5 万 token 的方案/diff，大约消耗：

输入:  250,000 × 125/1M = 31.25 credit
输出:  25,000  × 750/1M = 18.75 credit
合计:                     ≈ 50 credit / 次

Plus 套餐的周 GPT-5.5 预算视平台总负载浮动，平均落在 250-300 credit 区间。六次这样的 agent 循环就能掏空整周 —— 而 /status 的 5 小时盘可能还显示 40%+ 剩余，因为 5 小时窗口按消息算，不按 credit。这就解释了 #19215 里用户看到的反差：5 小时还剩很多，周窗口已耗尽。

结构性修复是：重型 agent 循环走 API key（按美元结算，没有 credit 记账），订阅留给交互式对话。

「You’ve Hit Your Usage Limit」修复方案（覆盖每个档位）

下面 7 种方案按破坏性从小到大排列。挑第一个匹配你处境的方案，看完就停。

方案 #1 — 等 5 小时滚动重置（Free / Plus，轻度用量）

如果 /status 显示 5 小时窗口剩余 <5%、但周窗口在 30% 以上，等就行。精确的重置时间戳在 /status 里 —— 通常在你最后一次突发用量后 3-5 小时内。

等的过程里，有产出的做法是把 IDE 切到手动编码模式，或用一个不共享这套限额的非 Codex 工具（任何 IDE 端自动补全都行）。

方案 #2 — 领取免费重置（2026 年 6 月 11 日 changelog）

2026 年 6 月 11 日的 Codex changelog 引入了「rate-limit reset banking」，在功能上线时给 Plus 和 Pro 用户各发一次免费重置。如果你还没领，触顶时 Codex CLI 会显示选项；CLI ≥ v0.135 也支持 codex /reset 命令。

每次发布事件每用户一次。如果 OpenAI 又发了一次重置（5 月 15 日 Tibo 在 X 上宣布的那次是团队级，不消耗 banking 的那一次），先看 changelog 公告再决定要不要烧掉手上唯一一次 banking 重置。

方案 #3 — 升级套餐档位

如果你每周都在打空 Plus 的周限额，Pro 5x（$100）给到 5 倍消息预算，Pro 20x（$200）给 20 倍。和走 API 路径的盈亏平衡点大致是：

如果你的用量模式是「偶尔爆发式重型工作」，API 路径几乎稳赢。订阅只有在用量稳定可预测时才划算。

方案 #4 — 幻象限额绕开方法（issue #19215）

如果 /status 显示容量正常但 Codex 仍然以 usage limit 拒绝请求，你撞上了 #19215。这个 bug 在 Codex CLI v0.124.0 出现（issue 提交时仍未修复）。可行步骤：

codex /quit
rm -rf ~/.codex/sessions/*
codex

清掉本地会话缓存可以解决多数报告案例。如果仍未解决，把日志发到 issue 帖里反馈，并切到方案 #5（API key 路径）保持工作不中断。

方案 #5 — 把 OPENAI_BASE_URL 切到 OpenAI 直连 API 端点

最干净的「我只想继续写代码」方案。在 platform.openai.com/api-keys 生成一个 OpenAI API key（sk- 开头那种，不是 sk-proj- 的 ChatGPT 绑定 key），然后：

export OPENAI_API_KEY=sk-your-api-key
export OPENAI_BASE_URL=https://api.openai.com/v1
codex

Codex 此时打的是按 token 计费的 API，而不是你的 ChatGPT 订阅。成本按 token 算。一次小 bug 修复在 GPT-5.5 上大约 $0.40，多文件重构（约 30 万输入 / 3 万输出）大约 $2.40 —— 都远低于一次「需要付费」的 banking 重置。

权衡：你会失去 ChatGPT 捆绑的云端功能（Slack 集成、Codex dashboard 里的 GitHub 评审）。如果只做纯 CLI 工作，这是最高杠杆的方案。

方案 #6 — 把 OPENAI_BASE_URL 切到兼容 OpenAI 的按量 API

和方案 #5 同形态，区别在于走的是聚合多模型、统一 key、暴露每 key 预算的供应商。下面例子用 ofox，但这套模式适用于任何兼容 OpenAI 的端点。

export OPENAI_API_KEY=ofox-your-key-here
export OPENAI_BASE_URL=https://api.ofox.io/v1
codex

ChatGPT 订阅已打空时，这条路相比直连 OpenAI 有三点优势：

1. 单价与官方一致。ofox 上 openai/gpt-5.3-codex 挂的就是 OpenAI 的 $1.75 / $14.00 每百万 token。单价请以模型页为准，不要按某次活动的返还倒推——会过期的正是那一部分。
2. 模型可无缝切换。ofox 上 openai/gpt-5.4-mini 是输入 $0.75 / 输出 $4.50 每百万 token，便宜到可以当作迭代工作的默认模型，把 gpt-5.3-codex 留给硬重构。
3. 每 key 预算。ofox 在 dashboard 上暴露每个 key 的月度上限。设成 $50/月，不管 agent 循环跑得多猛都不会超。

ofox Codex 集成文档 和深度版的 Codex CLI 自定义端点指南 涵盖了模型级调优。

方案 #7 — 通过 ~/.codex/config.toml 做多供应商路由

如果你的团队或个人想让 gpt-5.3-codex 跑硬重构、便宜模型跑迭代，配置两个供应商让 Codex 切换：

[model_providers.ofox]
name = "OfoxAI"
base_url = "https://api.ofox.io/v1"
wire_api = "responses"

[model_providers.openai_direct]
name = "OpenAI Direct"
base_url = "https://api.openai.com/v1"
wire_api = "responses"

[profiles.fast]
model = "openai/gpt-5.4-mini"
model_provider = "ofox"

[profiles.heavy]
model = "openai/gpt-5.3-codex"
model_provider = "ofox"

按需切换：硬活用 codex --profile heavy，迭代用 codex --profile fast。完整 schema 见 Codex CLI config.toml 深度解析。

Codex 限额事件：2026 年的真实节奏

今年和周限额相关的事件时间线。盯节奏是预判下一次的唯一办法。

规律很清楚：OpenAI 给的是战术性重置而不是永久性提高上限。一个月内打满两次的 Plus 和 Pro 用户应该开始为 API 路径做准备，不要再赌第三次重置。

限额不会自己回来时：现在就能用的按量 API 替代方案

如果你等不起，按切换成本排序的几个选项如下。先看核心对比：

来源：定价在 2026 年 6 月 15 日核对 ofox 模型目录 和 Codex 定价文档。

方案 A — ofox（兼容 OpenAI 的替换）

优点：每 key 支出上限，若同时用 Claude/Gemini 还能合并账单，Codex CLI 是官方支持的客户端。单价与 OpenAI 目录价一致。

怎么切：两个环境变量。OPENAI_BASE_URL=https://api.ofox.io/v1，OPENAI_API_KEY 设成 ofox key。重启 Codex。总耗时不到 60 秒。

API 模型 ID：openai/gpt-5.3-codex、openai/gpt-5.5、openai/gpt-5.4、openai/gpt-5.4-mini。完整目录见 ofox 模型目录。

方案 B — OpenAI 直连 API

优点：和 ChatGPT 套餐同一家，不存在第三方信任问题，模型阵容完整。

缺点：官方定价（没有折扣），没有脚本支持就没有每 key 预算。

怎么切：在 platform.openai.com/api-keys 拿一个 sk- API key，OPENAI_BASE_URL=https://api.openai.com/v1。重启 Codex。

方案 C — Amazon Bedrock（2026 年 6 月 4 日上线）

优点：配额走你的 AWS 账户，本身已经付 AWS 的账时合适。

缺点：模型目录仅限 AWS（当前是 OpenAI 的一个子集），区域可用性受限，鉴权比环境变量复杂。

怎么切：配置 Bedrock 凭证，OPENAI_BASE_URL 指向 Bedrock 代理端点。具体步骤看 changelog。

方案 D — 直接换编码工具

如果 Codex CLI 周限额一直在咬你，也可以转 Claude Code（用 claude-opus-4-8，2026 年 6 月在 Anthropic 当前的旗舰，并已在 ofox marketplace 上线）或其他编码 agent。摩擦在配置重写 —— 你的 Codex AGENTS.md、提示词、harness 习惯不能干净迁移。这条路留给「我决定不再用 Codex」，不是「我今天得交活」。

工作流迁移的具体差异可看 Codex 真实编码工作流。

怎么监控 Codex 状态、给未来烧钱设上限

止血之后，给自己安一套防再次撞墙的机制。

每次重活前都 /status 一下

把它做成反射动作。任何超过 10 万输入 token 的任务都先 /status。如果有一个窗口剩余低于 30%，本次会话直接切到 API key 鉴权。

订阅 OpenAI 状态页

status.openai.com 近实时显示 API 故障和 Codex 降级。订阅邮件或 RSS —— Codex 出问题时你想第一时间知道，而不是先花 10 分钟怀疑自己配置坏了。

跟踪 Codex CLI 版本号

幻象限额 bug（#19215）绑定 CLI v0.124.0。固定到一个已知良好版本：

npm install -g @openai/codex@0.135.0

用 codex --version 查当前版本。新版本起码用一周，让回归 bug 暴露出来再升级。

走 API 鉴权时设每 key 支出上限

切到按量 API 后（方案 #5/#6），设一个硬上限。OpenAI 直连在 dashboard「Spend limits」里，ofox 在 keys 页面的每 key 月度上限。单开发者的合理起步上限：$50/月。看完一个月真实烧钱再调。

用 10 行 shell hook 看每日支出

比起等 dashboard 告警，更务实的做法是本地记每次 Codex 会话的 token 数，再累加日总。把下面这段丢到 ~/.codex/hooks/post-session.sh：

#!/bin/bash
# 把每次会话的 token 数追加到 ~/.codex/spend.log
LOG=~/.codex/spend.log
TS=$(date -u +%Y-%m-%dT%H:%M:%SZ)
echo "$TS in=$CODEX_INPUT_TOKENS out=$CODEX_OUTPUT_TOKENS model=$CODEX_MODEL" >> "$LOG"

读今日总量：

grep "^$(date -u +%Y-%m-%d)" ~/.codex/spend.log | \
  awk '{for(i=1;i<=NF;i++){if($i~/^in=/){gsub("in=","",$i);ins+=$i};if($i~/^out=/){gsub("out=","",$i);outs+=$i}}} \
       END{printf "today: %d input / %d output tokens\n", ins, outs}'

得不到精确到美元的账单（模型价位会让换算复杂），但你能在下一次开 agent 循环之前看到「今天已经烧了 80 万 token」。仅这一个行为提示，实践中通常让周烧量下降 20-30%。

默认用便宜模型

迭代工作最便宜可靠的模型是 ofox 上的 openai/gpt-5.4-mini，输入 $0.75/百万 token。把它设成 Codex CLI 默认模型，只在确实需要旗舰编码能力时切到 gpt-5.3-codex。这种模式跑一周通常能砍掉一半支出。

更宽的模式可见 自定义模型供应商 BYO 配置指南。

团队共享配置（多人开发场景）

如果团队里 3 人以上都在打满同一个周限额，个人 ChatGPT 订阅已经不是合适的形状。经济账翻转：

• 5 个开发者 × $20 Plus = $100/月，但限额各自计算且不可预测
• 5 个开发者 × 共享 API key + $50/月上限 = 可预测的 $250/月封顶，用量池化

ofox 大多数客户用的团队共享模式是按环境（dev、staging、ci）一个 API key，而不是按开发者。config.toml 放仓库里，环境变量从每个开发者的密钥管理器拿。可以提交到仓库的示例：

# .codex/config.toml — 提交到仓库
[model_providers.team]
name = "Team Shared (ofox)"
base_url = "https://api.ofox.io/v1"
wire_api = "responses"
# 鉴权走每个开发者的 $OPENAI_API_KEY（开发者本地环境，不进仓库）

[profiles.default]
model = "openai/gpt-5.4-mini"
model_provider = "team"

[profiles.heavy]
model = "openai/gpt-5.3-codex"
model_provider = "team"

每个开发者本地设自己的 OPENAI_API_KEY（指向密钥管理器里的每人或每团队 key）。支出监控集中到一块 ofox dashboard，而不是五个独立的 ChatGPT 账号。CI 管道用单独一个 key，每次跑配更严格的上限。

相对个人 ChatGPT 订阅的差别：一个开发者跑了一次 $4 token 成本的重构，整个团队在一个 dashboard 上看得见。五个独立 ChatGPT 订阅同一周各自打满周限额时，你既没有可见性也没有共享预算。

关于真实性和成本的一段话

把 Codex CLI 从 $20 ChatGPT 套餐切到兼容 OpenAI 的 API 上跑，gpt-5.3-codex 上一次小 bug 修复按目录价约 $0.15、8 月活动期间约 $0.13 —— 比订阅在某个糟糕下午被幻象限额浪费掉的额度还少。

这就是真实的算术。ChatGPT 订阅在用量稳定、在上限以内时是好东西。一旦用量变成爆发形状 —— 重构周、CI 死线、单次 agent 循环触碰 30 个文件 —— 订阅上限就是错误的抽象。Token 计费按实际用量付费，让你能继续交活。

Codex 怎么决定你的限额什么时候重置？

它不决定。后端给它一个时间戳，它负责渲染。

Codex CLI 自带一份机器可读的协议描述，所以这件事可以核而不用猜。跑这条命令，自己读生成出来的 schema：

codex app-server generate-json-schema --out /tmp/codex-schema

0.147.0 上这会导出 557 个类型定义。而支配你盯过的每一个重置倒计时的那个类型，只有三个字段宽：

只有 usedPercent 是必填。resetsAt 可空——这就是对「Codex 限额」最常见那条抱怨的官方答案：CLI 不告诉你什么时候重置，不是它藏着，是它没有这个数。

三条值得记住的推论：

• 没有时钟规则可以逆推。 没有「周一 UTC 零点重置」，也没有「从你第一条消息起算 5 小时」。服务端发什么就是答案，而且它可以在不发客户端版本的情况下改。
• 只有两个窗口，不是五个。 一个 RateLimitSnapshot 只带 primary 和 secondary 两个窗口，没有别的。状态栏另外备了 5 小时、每日、每周、每月、每年五套标签串，所以这两个槽位是在渲染时按 windowDurationMins 取名的。看到「weekly」不代表存在一个独立的周配额桶。
• 更新是稀疏的。 account/rateLimits/updated 这条通知的文档写明它是「sparse rolling rate-limit update」，而且自己描述里写着：更新里缺失的可空元数据「不会清掉之前观测到的值」。看着像冻住的仪表，可能只是没被重发。

同一个 snapshot 还带着多数教程漏掉的部分。planType 是 15 个值的枚举，包含 go、prolite、ent26 以及四个不同的 business 和 enterprise 变体，所以配额形态是按具体套餐而不是按套餐名分类的。rateLimitsByLimitId 是一个按 metered limit_id（比如 codex）分键的 map，所以一个账号可以持有多个互不相干的限额桶。而 rateLimitReachedType 区分了五种全都以「you’ve hit your usage limit」形式出现的状态：

rate_limit_reached
workspace_owner_credits_depleted
workspace_member_credits_depleted
workspace_owner_usage_limit_reached
workspace_member_usage_limit_reached

如果你在 workspace 套餐上，这个字段就是「等」和「找 owner 加 credit」之间的区别，也是 CLI 有时提出帮你通知 owner、而不是提供重置的原因。

能提前重置 Codex 的限额吗？

只能兑换你账号已经获得的 reset credit，而且只能在你确实被限流的时候。

Codex CLI 0.147.0 为此有一个正式菜单。/usage 里提供「View account usage or redeem an earned reset」「Redeem usage limit reset」，以及一条描述为「Reset your current usage limits」的「Full reset」，后面挂着确认步骤（「Use this reset?」/「Yes, use reset」）。底下 app server 暴露的是 account/rateLimitResetCredit/consume。

内部命名才是有用的那部分：它是一个 credit，不是一条命令。每一个都是一条记录：

账号汇总里给的是一个 availableCount 加一份可选的明细列表，而 schema 明确警告后端可能截断这份列表，所以它的长度可以小于 availableCount。兑换需要一个必填的 idempotencyKey（一个 UUID，重试时复用同一个）和一个可选的 creditId；不传 ID，后端就挑下一个可用的。

响应恰好是四种结果之一：

nothingToReset 回答的是大家真正会问的那个问题。你没被限流之前花不掉这个 credit，也就是说没有办法在一场重活之前先攒一个 reset。CLI 把这件事显示成「Your usage does not need a reset right now.」，它的兄弟文案「You don’t have any usage limit resets available」对应的是 noCredit。

这几条放在一起看，把很多人去找的那件事堵死了。一个 reset 授予给一个账号、由该账号自己已认证的会话兑换、以该账号当前正被限流为前提、且一次性消耗。它不是可购买的商品，不可转让，第三方服务也生产不出来；任何宣传批量重置额度的，要么在卖别人账号的访问权——这违反 OpenAI 的条款、且让两个账号都有风险——要么根本什么都没在卖。

OpenAI 确实在卖的是 credit，而且 CLI 现在会直接这么说。它的限额文案按套餐不同：免费账号被指向 Plus，Plus 账号看到的是「Upgrade to Pro … visit https://chatgpt.com/codex/settings/usage to purchase more credits」，workspace 成员看到的是「Request a limit increase from your owner to continue using codex.」。另外还有一个 rate-limit-switch-prompt，在你接近限额时触发、建议接下来几轮换个便宜模型，带一个「永不再显示」选项。如果你当初点过一次然后再没见过它，原因就在这儿。

不进 TUI 怎么读自己的重置时间？

用 stdio 驱动 app server。 两个只读方法就够了：account/rateLimits/read 和 account/usage/read。

{
  printf '%s\n' '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"clientInfo":{"name":"probe","version":"0.0.1"}}}'
  printf '%s\n' '{"jsonrpc":"2.0","method":"initialized"}'
  printf '%s\n' '{"jsonrpc":"2.0","id":2,"method":"account/rateLimits/read"}'
  sleep 5
} | codex app-server

登录状态下，这会返回上面描述的那个 snapshot，含 resetsAt，你想怎么格式化都行。未登录状态下它返回的是一条具体报错而不是空对象，值得认一下：

{"error":{"code":-32600,"message":"codex account authentication required to read rate limits"},"id":2}

account/usage/read 行为一样，只是报错文案不同：「codex account authentication required to read token usage」。这个方法返回累计 token 数、按天分桶、单日峰值 token，以及——给好奇的人——currentStreakDays 和 longestRunningTurnSec。

这两个都可以放心轮询。account/rateLimitResetCredit/consume 不行：它会真的花掉你账号上的一个 credit，所以别写进脚本，留给 /usage 的确认框。

参考信息来源

• OpenAI Codex rate card
• Codex 定价文档
• Codex changelog
• openai/codex#19215
• Knightli 重置历史
• ofox 模型目录
• ofox Codex 集成文档
• Codex CLI 自定义端点指南（ofox blog）
• Codex config.toml 深度解析（ofox blog）
• Codex CLI 真实编码工作流（ofox blog）