Codex 重置卡天天发却加载不出来：到账、叠加与 5 小时限额排查

最近一批 Codex 付费用户收到了一种新东西：不再是系统自动重置用量，而是一张可以自己决定何时使用的「重置卡」（界面里通常写作 usage limit reset）。按讨论中流传的说法，这类卡会持续发放到新模型 Astra 全量上线为止。于是话题迅速分成两拨：一拨在问「我的卡在哪」，另一拨在问「卡加载不出来怎么办」。

先给没跟上的读者交代背景：重置卡相当于一次手动重置当前计费周期用量的机会，用掉就没了；而过去遇到额度耗尽，多数情况只能等周期自然滚动或系统统一重置。理解这一点，后面的很多争论就顺了。

重置卡解决了什么，又没解决什么

• 解决：周额度提前耗尽时，可以自己挑时机「续一条命」，不必干等周期结束。
• 没解决：5 小时滚动窗口的速率限制。不少人反馈，即便手里有卡，也常常是「5 小时窗口先卡住，周额度却还没见底」，于是卡根本没机会用。
• 不改变计费：卡只是额度层面的补偿，不等于套餐升级，也不会把低档套餐变成高档。

这解释了为什么会出现「有卡但感觉没用」的声音——瓶颈不在总量，而在短周期速率。

到账不是同时的：为什么有人有、有人没有

从讨论里反复出现的情况看，大致可以归为四类：

1. 分批发放：同一档位的人到账时间差几小时甚至一两天都出现过，「还没到」是常态而非异常。
2. 资格范围：只有付费套餐在发放范围内，免费账号看不到入口。较低档的付费套餐也有人在讨论中表示收到了。
3. 客户端与缓存问题：有人在网页和某一平台的桌面客户端都看不到，更新桌面端或换另一个平台的客户端后才显示出来。
4. 服务端接口临时异常：大量「Couldn't load usage limit resets」和 429 的反馈，明显是拉取接口过载或被限流，与个人账号状态无关。

对应的处理顺序建议：

• 先刷新网页版账号页，确认到底是「卡确实没发」还是「前端没渲染出来」。
• 把桌面客户端更新到最新版，或换一个客户端、换一个浏览器再登录一次。
• 遇到 429 就等 1–2 小时再试，避开发放高峰；限流面前反复点击只会更糟。
• 确认账号确实处于付费有效状态，而不是「已取消、等当前周期结束」的中间态。

5 小时限制才是主要矛盾

整场讨论里最集中的一个抱怨是：重置卡发得再多，也顶不住 5 小时窗口。相比「多拿几张卡」，很多人更希望放宽短周期速率。

可操作的应对方式：

• 把重活（大范围重构、批量生成、长上下文分析）排在窗口刚开始时做，轻量任务留到窗口末尾。
• 拆分任务，减少一次性超长会话；上下文越长，单次消耗越陡。
• 若确有连续高强度需求，再评估是否升到更高档位。有用户称更高档位不受同样的短周期限制，但这属于个人观察，请以官方套餐页的最新说明为准。
• 不要为了「把卡用掉」而刻意刷量，卡的价值在于应急。

升级、取消订阅与重置卡：几个容易踩的坑

• 升级会不会清空已有重置卡：讨论中的经验是「不会」，但这只是用户侧观察。重要操作前，建议先记录当前卡的数量与有效期，出问题时至少能对照。
• 「先取消再升级」有风险：通过应用商店订阅时，这种组合操作可能触发退款并让订阅状态短暂中断，有人因此一度掉回免费档。稳妥做法是等当前周期自然切换，或直接在网页端管理订阅，避免在到期前几小时做连环操作。
• 逐级升级多拿卡：这类路径依赖当时的活动规则，规则随时可能调整，中途出问题也不好回滚，不建议把套餐设计建立在这种套利上。

关于 Astra 与「每天一张」的流传说法

• 「发到 Astra 全量为止」是讨论中的说法，具体截止时间与发放频率并没有可靠的公开说明，别把它当成确定的时间表。
• 「新模型价格是现有某模型的若干倍」这类说法属于未经证实的传闻，不适合拿来做预算或采购决策。
• 卡的叠加与有效期：确实有人手里同时持有多张、到期日各不相同。能否叠加、能存多久，以界面显示为准，不要把「囤在手里」当成长期资产。

小结：一份可执行的检查清单

1. 确认账号为付费状态且在有效期内，排除「已取消待到期」。
2. 网页端与最新桌面端各看一次，排除渲染和缓存问题。
3. 遇到 429 或加载失败，等 1–2 小时再试，不要连续刷新。
4. 先记录手上卡的数量与有效期，再决定是否升级或取消订阅。
5. 把卡留给真正卡住进度的时刻，日常靠任务拆分和窗口节奏控制消耗。
6. 涉及套餐权益、发放规则的具体条款，一律以官方最新公告和订阅页为准。

整体来看，这一轮发放更像是新模型上线前的过渡补偿，而不是长期机制。与其纠结能不能多囤几张，不如先把手上的用量节奏理顺——卡是保险，不是产能。