用 Codex 写代码,最容易卡在「额度还没回来」这件事上:昨天还能跑,今天提示用不了;以为是月底统一重置,结果中途又冒出来一点。这篇不给你一个写死的刷新时间,而是讲清额度刷新有哪几种节奏、哪些条件会让它看起来没刷、以及怎么自己确认当时的真实状态,再按节奏安排任务。
用 Codex 写代码,最难受的不是它不会写,而是写着写着额度没了。昨天还能跑,今天提示用不了,也没收到通知。很多人第一反应是月底是不是没重置,或者以为自己哪里违规了。其实额度这个东西有好几种回血节奏,混在一起看就很容易误判。这篇不给你一个写死的时间点,而是讲清刷新有哪几种节奏、哪些情况会让它看起来没刷、以及怎么自己确认当时的真实状态,再按节奏把任务排开。
先记住一句话:额度刷新不是一个统一动作,而是好几套规则同时生效,你遇到的「没恢复」到底是哪种没恢复,决定了下一步是等、是换入口,还是干脆补额度。下面的顺序建议照着排查,不要一上来就猜服务方改了规则。
额度刷新的几种节奏,先分清你遇到的是哪一种
常见的刷新节奏大致分三类,三者经常叠在一起,这是看错的主因。第一类是按固定周期滚动恢复,通常从你上次把额度用掉的那个时间点往后算,所以你用掉的时间不同,回来的时间也不同,不存在一个全站统一的开闸时刻。第二类是按自然周期归零,服务方划一个时间边界,到点统一清一次,但这个边界不一定按你所在地的时区算。第三类是活动或赠送带来的一次性额度,往往带单独有效期,到期直接失效,不会跟周期一起回来。
| 节奏类型 | 看的是哪个时间点 | 常见误判 |
|---|---|---|
| 滚动恢复 | 你上次用掉的时刻往后推 | 以为全站同一时间恢复 |
| 自然周期归零 | 服务方划定的时间边界 | 拿本地时区去套,差一天 |
| 活动或赠送额度 | 单独的有效期 | 以为到期会跟周期一起回来 |
- 先给眼前的缺口归类:是滚动还没轮到、是自然周期没到、还是一次性额度已经过期,归错类等待方式就全错
- 滚动恢复类的额度,等待时间取决于你自己的使用记录,别人说「我这边已经回来了」对你不构成参考
- 自然周期类的额度,跨时差的服务方边界容易和你的直觉差一天,别只按自己手机上的日期判断
- 赠送类额度通常单独记一笔,到期就没了,不要把它算进固定周期里
- 当前各类规则的实际状态和口径,到 /resets|额度重置追踪 核对当时的说明,不要凭印象
明明到点了却没恢复,先排查这几件事
判断「到点没恢复」之前,先确认你看的是同一套口径。账号层面的额度统计和具体入口、客户端里的提示,很可能不是同一个数字。同一个账号,在网页里看到的和在某客户端里看到的对不上,是很常见的情况。这种时候以账号里的额度显示为准,而不是以某个客户端的提示为准。
| 现象 | 优先排查 | 判断标准 |
|---|---|---|
| 换个入口就变了 | 不同客户端的额度口径 | 以账号额度页为准 |
| 付费档没用满但免费用不了 | 两套额度不互相顶替 | 免费位是否单独见底 |
| 重登后又有了 | 本地缓存了旧状态 | 退出重登看真实数字 |
| 没怎么用却掉得快 | 失败重试也计入消耗 | 对调用记录看掉在哪 |
还有一个容易被忽略的点:请求失败、被限速、超时这些调用,很多情况下也照样计入消耗。所以你感觉「今天根本没跑成几件事」,额度却掉了一大截,很可能不是任务重,而是重试太多。另外,套餐档位和免费位通常是两套口径,付费档位没用满,不代表免费位还能接着用,两者不会互相顶替。
- 账号维度 vs 入口维度
- 有的按整个账号统计,有的按具体入口或客户端算,换入口结果可能不同
- 失败计入消耗
- 报错、限速、超时的调用也可能算进用量,看调用记录才知道掉在哪
- 档位与免费位
- 付费档位和免费位是两套口径,不会互相补充
自己确认当下状态的三步
与其到处问「刷新了没」,不如按固定步骤自己确认一遍,几分钟就能得到当下可用的结论。下面这三步建议按顺序做,前一步的结论会影响后一步怎么解读。
- 两边对照把账号里的额度显示页和客户端里的提示各看一遍,两边对不上就以账号页为准;重登一次排除缓存。
- 核对口径到 /codex-radar|Codex 雷达 和 /resets|额度重置追踪 看一下当前的刷新与重置口径,别只靠记忆里的旧规则。
- 对齐记录把最近的调用记录和额度变化对一遍,确认掉得快是任务本身重,还是失败重试多;两种情况的应对方式完全不同。
如果查不到明确说法,或者口径本身模糊,那就按「今天够不够用」来排计划,而不是按「下周一定会满血」来排。把不确定的额度当成一种会随时中断的资源,心态和排期都会稳很多。
先确认当下真实可用的量,再决定今天做什么,比先规划一个大任务再等额度靠谱。
按刷新节奏排用量:几条能直接照做的做法
搞清楚节奏之后,真正的收益在于把任务和额度节奏对齐。不用记复杂的日程,只要把任务分档、把关键动作放在额度刚恢复的时候做,就能少踩很多「跑一半断掉」的坑。
- 任务分两档:随时能停的小改动放免费位,跑起来就停不下来的整块重构留到额度刚恢复的时候做
- 在恢复日前后各记一次额度数字,连续记两三个周期,就能摸出自己账号的真实节奏,比查外部说明准
- 单一入口吃紧时,先看 /coding-plans|编程套餐目录 里的档位说明,判断是换档还是把部分调用切到按量接口
- 跨周期的长任务尽量拆成能中断的小段,中途被断后重跑的消耗,通常比重排一次更贵
- 别为了等刷新把任务压到最后一刻,恢复前的那段时间最容易误判自己还有多少余量
这里要说清楚不适用的情况:如果你的用量本身就很小、几天才动一次,那基本不需要按节奏排,随手用完就行;反之,如果你每天都要跑大任务,那这套分档和记账的方式才有明显价值。判断自己属于哪种,看的是过去两三个周期里有没有出现过「跑一半断了」,有就需要排,没有就不必折腾。
下一步想看清当下各家的额度口径和套餐档位,可以去站内的编程套餐目录,对照自己的用量习惯判断是换档还是继续等刷新。→常见问题
Codex 的免费额度是每天刷新还是每月刷新?
不同入口和不同活动下的规则不一样,有按固定周期滚动的,也有按自然周期归零的,还有一次性赠送到期即失效的。与其记一个说法,不如在 /resets|额度重置追踪 看当前口径,再拿自己账号连续记两三个周期的额度变化来确认。
额度显示已经恢复,为什么还是用不了?
常见原因是看错了口径:账号页显示的是账号维度,客户端提示可能来自另一个入口;也可能是免费位和付费档位两套规则混在一起。先退出重登换一个入口看真实数字,再去 /codex-radar|Codex 雷达 对一下当前状态。
等到恢复再用好,还是提前切到按量 API?
看任务能不能停。能随时中断的小改动,等恢复更省;跑起来就要连续输出、中断就要重来的任务,切按量反而更划算。具体按量单价到 /official-api|官方 API 价格 核对,再对比 /coding-plans|编程套餐目录 里各档位的额度说明。