Codex 额度用完了怎么办？重置、降级与切 API 三条路

正写着代码，Codex 突然不干活了，屏幕上要么转圈要么报错——这时候最怕的是瞎折腾：先怀疑网络、再怀疑账号，最后才发现是额度见底。这篇把「怎么确认到底哪种情况」放在第一步，然后给你三条能落地的路：等重置、降档继续用、切到按量计费的 API。每条都说清适用和不适用，附排查顺序和切换前该做的准备。

正写着代码，Codex 突然不干活了：要么转圈，要么弹个错误。这时候最容易犯的错是瞎折腾——先怀疑网络，再怀疑客户端，最后才发现是额度见底。其实这三类情况的表现不一样，处理路径也完全不同，先花两分钟确认自己属于哪一种，比反复重试有价值得多。

确认完再选路。这篇给你三条能落地的方向：等重置、降档继续用、切到按量计费的 API。每条都说清楚什么情况下适用、什么情况下别硬走，以及动手前该准备什么。

第一步：先分清是限流、降级还是额度真见底

三类现象的症状差别挺明显。短时间密集发请求后被卡住，多半是限流，稍微等一会儿、把并发降下来就能恢复；响应明显变慢、回答变短、动不动就截断，可能是被降级到了较弱的处理路径；直接报额度类错误、连一个最简单的请求都过不去，那才是真的用完了。先看报错原文里的关键词，比凭感觉猜靠谱。

1. 看报错原文把报错完整读一遍，找「额度」「配额」「频率」这类关键词，先给问题归个类。
2. 用最小请求复测发一个简单到不能再简单的请求，能过说明偏限流，过不去就往额度方向查。
3. 对照用量记录翻最近一段时间的用量，看是不是刚好踩到自己的额度上限。

等重置这条路：什么情况值得等，怎么判断要等多久

额度的回补口径各家不同，有的是滚动窗口，有的是固定周期，别按自己的直觉猜。先去账号的用量或订阅说明里确认自己的周期是按天、按周还是按订阅周期走，再决定值不值得等。到 Codex 雷达和额度重置追踪页看一眼，也能知道别人是不是同一时间点出问题，方便排除平台侧异常。

滚动窗口

额度随时间持续回补，用掉的那部分过一阵子慢慢回来

固定周期

到某个时间点统一回补，之前的余量不累积

按订阅周期

跟着订阅的起止时间走，周期结束才整体刷新

• 值得等：任务不紧急、离下一个回补点不远、手上还有别的活能先干
• 不值得等：卡在交付节点上、连续几天都在同一时间撞墙
• 等待期间做一件事：把额度余量和回补时间点记一笔，攒出自己的用量节奏
• 顺手做的事：到站内追踪页看看是不是只有你一个人出问题

如果每个周期都是到了中途就开始撞墙，说明当前档位根本不匹配你的真实用量，这时候「等」只是在拖时间，该看下一条路。

降档继续用：把贵活省着干，而不是硬扛

降档不是简单换个更便宜的模型就完事，核心是按任务分档。探索性提问、改错别字、写样板代码这类活，用轻一点的处理路径就够了；架构设计、复杂重构、跨文件改动才值得占用强的资源。同样的额度，用在刀刃上能多撑好几轮。

1. 拆分长上下文别把整个仓库塞进去，只贴相关文件片段，减少单次请求的消耗。
2. 关掉自动重试失败自动重试会悄悄吃掉额度，先关掉，失败了手动判断原因。
3. 大改拆成几轮小改一次只推进一小块，每轮都能验证，返工也比一次性大改便宜。

适用边界很明确：如果任务本身就必须强处理加长上下文，降档只会来回返工，总消耗反而更高。这种情况别省，直接看第三条路。

切到 API 计费：什么信号说明该切了，切之前备什么

该切的信号其实不难认：连续两个周期都在中途撞墙、等待时间已经影响到交付节奏、用量忽高忽低导致订阅档位永远选不对。按量计费至少不会把你卡死在半路，多出来的成本换来的是不中断。到价格追踪页核对当时的单价口径，再和你的实际用量放一起估一估。

• 先把客户端里的模型和 Base URL 配好，跑通一个最小请求
• 再逐步把日常任务挪过去，别等订阅彻底用干才动手
• 请求带上可识别的标签，方便后面按项目归账
• 记下每次任务的用量，设一条自己的告警线
• 过一段时间把实际花费和当初订阅价放一起比，再决定长期走哪条

# 切换前先用最小请求验证连通性
curl -s -o /dev/null -w "%{http_code}\n" \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"<当前可用模型>","input":"ping"}' \
  "$BASE_URL"

成本可控的关键在留痕：没有记录，你永远不知道自己到底花了多少，也就没法判断哪条路更划算。迁移和对比的具体做法，站内指南中心有更细的拆解。