一、先定位429的来源端
Codex返回429 Too Many Requests时，仅凭状态码无法判断成因。需要先收集四项信息：完整的error.code、Retry-After响应头、当前认证方式，以及错误由OpenAI目标服务还是第三方网关产生。
- 响应中带Retry-After与turn_rate_limit_exceeded：属于官方容量或短时限制，应停止连点，等满指定时长后以小请求复测。
- 提示credit、spend或usage limit相关字样：属于API额度或支出上限，按认证方式进入额度分支处理。
- 经第三方网关出现且errorCode为upstream_reset_replay_refused：属于网关合成的连接重置错误，应查传输层而非当作限流处理。
- 同一时段大量用户同时报错：可能为官方容量事件，可查状态页并等待恢复。
在拿到完整响应要素之前，任何恢复操作都只是猜测。
二、四类来源的特征与可控性对照
- 官方容量或短时限制：error.code为turn_rate_limit_exceeded，响应带Retry-After（有案例为205秒），文案为at capacity；可控性低，应遵守等待与退避。
- API余额或支出上限：出现credit_balance_exhausted、organization_spend_limit_exceeded等明确code；可控性高，补余额或调整上限即可。
- 项目或组织用量上限：organization_usage_limit_exceeded，属平台级用量上限；可控性中等，可申请提额。
- 第三方网关合成429：upstream_reset_replay_refused，连接重置被网关包装为429；可控性中等，需维护者排查传输失败。
需避开一个常见推理错误：以「周额度还有余额」推断「不可能被限流」并不成立。已有案例返回turn_rate_limit_exceeded、capacity文案与Retry-After，但这些信息不足以推导具体计数方式、并发上限或是否按出口IP限流，应以完整响应和官方说明为准。
三、按error.code分流的五步处理
步骤1：读完整响应
记录429完整正文、error.code、Retry-After、响应头、认证入口、所用模型、是否经过中转、时间与request ID，同时停止一切额外连点与并行重试。要素齐全后才进入分流，并确认响应由OpenAI返回还是第三方网关产生。
步骤2：速率与容量类处理
有Retry-After时先按该值等待（案例值为205秒，并非统一等待时长）；无该头时，采用设有次数与总时长上限的指数退避加随机抖动，避免多客户端同时重试。slow_down等速率线索归入本分支：降低发送频率、拆小任务。等待后用同认证、同模型的小任务验证，真实完成再逐步恢复工作量；失败则返回对应code分支，不无限重试。
步骤3：额度类分流（仅API Key认证）
- credit_balance_exhausted：为正确的API组织补余额。
- organization_spend_limit_exceeded：由管理员调整组织支出上限或等待周期重置。
- project_spend_limit_exceeded：核对项目级上限。
- organization_usage_limit_exceeded：申请提高平台用量上限。
注意：ChatGPT订阅与API是两套计费，付订阅费不等于给API充值；平滑请求速率也无法补回余额。
步骤4：网关合成429
errorCode为upstream_reset_replay_refused的错误，是OpenCodex网关对连接重置拒绝不安全重放的合成错误，并非OpenAI官方统一错误码，不能推广到所有中转，也不建议盲目打开retryOnReset。维护者应确认请求是否已执行，未执行才评估重放；保留连接重置记录与请求实际发送次数，查传输失败日志。
步骤5：条件性绕过与失败下一步
重登后短暂恢复、某模型小请求曾成功均属个案线索。所有分支失败时，保留脱敏响应、request ID、时间、客户端版本与网关日志，按实际产生端（OpenAI或网关）分别反馈。
四、判别产生端：目标服务还是网关
HTTP 429只说明请求被拒绝，不说明拒绝方是谁。它可能来自OpenAI目标服务，也可能由第三方网关自行产生：官方限流等Retry-After、补额度即可；网关合成错误则要查网关自己的传输日志。方向定错后续全白查——对着合成错误调重试节奏越调越乱，对着真实限流改网关配置改完照弹。
判别依赖两样东西：error.code与网关传输日志。网关合成错误带有网关自己的errorCode标识，与官方限流的错误码族不同，仅凭HTTP状态码无法区分。每遇429，将响应中的code与网关日志中同一request ID的记录并排比对，产生端即可明确。
团队层面有两条纪律：各成员使用各自的授权账号，由客户端或调度层统一控制并发与指数退避，避免多客户端同时重试——出口本身不控制请求节奏；经网关接入的，把合成错误与上游真实状态分开统计，避免合成错误污染限流判断。
如需固定归属线路做日志归因对照，可参考 https://www.ipxss.com/ 。固定归属线路仅对日志归因与对照有帮助，并未被证明能够解除余额、容量或速率限制，排查顺序不能倒置。
五、常见问题
Codex 429是账号被封了吗？
不是。429是限流状态码，来源为容量、额度或网关三类，与账号封禁无关。按error.code分流后，等待或补足对应额度是主要路径。
为什么额度还有余额还是429？
周额度尚有剩余，也不能排除其他短时限制或服务容量拒绝。已有案例返回turn_rate_limit_exceeded、capacity文案和Retry-After，但这些信息不足以推导计数方式、并发上限或是否按出口IP限流，以完整响应和官方说明为准。
重登或新开聊天能解除429吗？
不能作为已验证方案。有个案重认证后短暂恢复，也有新开聊天仍失败的反例。失败下一步：保留脱敏响应、request ID、时间、版本与网关日志，按实际产生端反馈。
第三方网关一直报429怎么办？
先看errorCode是否为upstream_reset_replay_refused——那是OpenCodex网关对连接重置的合成错误，不是真限流。维护者应确认请求是否已执行、查传输失败日志，不要盲目换账号、换出口或打开retryOnReset。
怎样降低429出现的频率？
速率类按Retry-After等待并平滑请求；余额或支出上限按对应code处理；服务容量问题可能仍需等待；网关合成429查其传输日志。固定出口没有被证明能够解除这些限制。
总结
处理Codex 429的主线是：读全error.code、Retry-After与响应头，定位429由OpenAI返回还是网关产生；容量类遵守等待，额度类按对应code补足，网关合成错误交维护者查传输层。重登与新开聊天只是条件性绕过，并非修复手段。团队场景由各成员使用自己的授权账号，并发与退避交给客户端和调度控制。