Codex 额度重置前后：重置卡取舍、用量与报错排查
Codex 在第 17 天安排的额度重置引发了一轮集中讨论：重置时间换算说法不一、手里快过期的重置卡不知该不该用、额度有人剩大半有人一天烧光、高峰期还频繁撞上容量报错。本文把这几类问题拆开，给出时间核对、重置卡取舍、用量控制和报错排查的具体做法，并提示哪些说法需要以官方公告为准。
背景：一次预告过的重置，为什么还能吵起来
Codex 官方在某个连续活动的第 17 天安排了额度重置，团队负责人提前放话：重置已经在路上，等核验确认就落地。按理说这是纯粹的利好，但讨论很快分成几派：有人算不清具体落地时间，有人盯着手里即将过期的重置卡不敢动，有人抱怨额度怎么都不够用，也有人反过来说根本用不完，还有人被 Selected model is at capacity 挡在门外。
矛盾可以归成一句话：官方的重置节奏和用户自己的额度节奏对不上。官方按活动日历走，用户按项目排期走，中间隔着一个「卡快过期了」的焦虑。下面把几类问题分开处理。
第一步：把重置时间算准，别用二手换算
讨论里出现的时间版本至少有三种：PST 上午 10 点前、北京时间凌晨 1 点、凌晨 2 点、凌晨 5 点。差一两个小时，对赶 deadline 的人来说就是一整晚的区别。
几个容易踩的坑：
- PST 和 PDT 不是一回事。美西夏令时和冬令时差一小时，转述时经常没人说清。
- 「10am PST 前」是上限，不是承诺时间点。官方原文的意思是「在这个时点之前落地」，可能提前很多。
- 二手换算容易叠加误差。中间经过一次模型改写、一次人工复述，时间就可能漂移。
要自己核对，用标准时区库算一遍最稳（把占位日期换成官方给出的日期）：
from datetime import datetime
from zoneinfo import ZoneInfo
deadline = datetime(YYYY, M, D, 10, 0, tzinfo=ZoneInfo("America/Los_Angeles"))
print(deadline.astimezone(ZoneInfo("Asia/Shanghai")))
结论只信两个来源：官方渠道的原话，以及你自己账户页面上状态的实际变化。任何「我听说北京时间几点」的说法，都当作参考值。
第二步：重置卡用还是不用
这是讨论里最纠结的一点：官方重置和手里的重置卡撞在一起，怕用了浪费，又怕不用就过期。判断逻辑其实不复杂——先看卡的实际到期时间，再看官方重置是「已确认落地」还是「在路上」。看账户页面自己确认，别信转述的日期。
| 情形 | 建议 |
|---|---|
| 卡 24 小时内到期，官方已确认重置当晚落地 | 等官方重置，卡作废可以接受 |
| 卡快到期，官方只说「在路上」 | 有实际任务就用掉，别赌一个未确认的时间 |
| 卡还有好几天，额度也有富余 | 不动，留着应急 |
| 额度已见底且有硬交付 | 先用卡保住交付，重置当额外收益 |
还有两条原则值得记住：
- 不要为了「用掉」而刷无意义的请求。既消耗算力，也提高触发限流的概率，属于用真实成本换心理平衡。
- 不要假设重置和卡会叠加。官方没明确说明之前，按「不叠加、以最后一次生效为准」来规划最安全；叠加规则请以官方说明为准。
第三步：额度消耗差异为什么这么大
同一时间，有人说周额度还剩一半多，有人说一天就把高档套餐跑空了。差异通常来自四个变量：
- 套餐档位不同，基数本来就不一样。
- 模型档位不同。高推理档位配合高速模式，是额度杀手；有人反馈开启高档位组合后，五小时窗口直接被清空。
- 并发数不同。多线程并行看着快，实际既成倍消耗额度，又容易让输出质量下滑、返工变多。
- 任务形态不同。长上下文、大仓库、反复重试的对话，比一次性小任务贵得多。
可操作的收敛方式：
- 日常改动走中档模型，只在关键节点（架构设计、疑难排查）切高档。
- 并发从 2–3 路起步，观察额度和质量再决定要不要加。
- 把大任务拆成「可验证的小步」，每步要求输出改动清单和验证方法，减少来回返工。
- 记录一两天的实际消耗曲线，比凭感觉判断「够不够用」可靠得多。
第四步：撞上容量报错怎么排查
Selected model is at capacity. Please try a different model. 是服务端容量问题，不是你的代码写错了，也不是提示词的问题。按这个顺序处理：
- 换模型或换档位重试，报错信息本身就在建议这一步。
- 退避重试，别一秒一次地打：第 1 次失败等 10 秒，第 2 次等 30 秒，第 3 次等 2 分钟，仍失败就换档位或暂停。
- 看官方状态页和公告，确认是不是全局高峰。
- 对比网络环境。如果只有你这边持续报错，换个出口网络试一次，可以排除出口 IP 或区域线路的因素；讨论里也有人怀疑是 IP 问题，但这一点没有定论，需要自己验证。
- 降低并发，把请求摊平到更长的时间窗里。
顺带一提，高峰期「感觉模型变笨了」的体感和容量压力往往是同时出现的。应对方式不是反复重问，而是把任务拆细、要求分步确认、保留中间产物，返工少了，体感会好很多。
第五步：别让本地环境把长任务打断
重置窗口经常落在凌晨，很多人会把大批任务压到那个时间点跑。这时真正的风险往往不是额度，而是环境：笔记本休眠、Wi-Fi 抖动、SSH 断连、会话过期，任务跑到一半断掉，额度照扣，结果没留下。
几个低成本做法：关掉系统休眠、用 tmux 或 nohup 保持会话、把长任务写成可断点续跑的形式（分片处理 + 中间结果落盘）。如果任务确实需要连续挂几个小时，也可以考虑把它放到一台长期在线、网络出口稳定的机器上跑，本地只负责查看结果——这类场景下租用机房里的远程 Mac（例如整机放在新加坡机房、按月使用的方案）是常见选项之一，但要不要为此付成本，取决于你的任务频率，不是必需项。
一份可执行的检查清单
重置前：
- 在账户页面确认自己的额度百分比和重置卡到期时间
- 用标准时区库把官方时间换算成本地时间，记下「上限时刻」
- 决定卡的处置方式（等 / 用 / 留），写下来就别再反复改
重置中和重置后：
- 确认状态真的变化了，再开始大批量任务
- 长任务放在不掉线的环境，开好断点续跑
- 遇到容量报错先退避再换档位，不硬刚
- 记录本次消耗，为下次重置做参照
小结
重置是官方节奏，用户控制不了；能控制的是三件事：时间的自我核对、重置卡的取舍决策、以及任务跑在什么环境里。别为了「怕浪费」而制造更多不确定性，也别把二手时间当承诺。涉及重置落地时间、重置卡有效期、模型档位和叠加规则这类时效性信息，请以官方最新公告和账户页面显示为准。
