Codex 报 429 是什么意思？和额度耗尽是两回事

429 是 HTTP 状态码里的「Too Many Requests」，意思是「你请求得太密了，先歇一下」。很多人看到它第一反应是额度没了去升级，其实完全没必要。

429 和额度耗尽的区别

这是两个不同层面的限制，混为一谈会做错决策：

• 429（限流）：短时间内请求太密集，系统让你等一下。通常几分钟到几十分钟自动恢复，和你的订阅档位无关。
• 额度耗尽：周期内的配额用完了，要等到下个周期才恢复。升级档位能解决。
• 判断方法：报错信息里带 rate limit / too many requests 的是 429；提示 quota / usage limit reached 的是额度问题。

什么操作最容易触发 429

429 基本都是「密度」问题，这几种用法最容易撞上：

• 脚本循环调用：写个 for 循环批量处理文件，几秒钟几十次请求，必炸。加个间隔，或者分批跑。
• 多开并行：同时开好几个会话一起跑，看着快，实际撞限流。改成串行或者错开时间。
• 重试风暴：报错后立刻无脑重试，越试越堵。正确做法是等一下再试，或者指数退避（间隔翻倍）。
• 团队席位席位撞车：同车人同时高频使用。这种情况只能错峰，或者换独享。

三种应对方式

按场景选，别都往升级上想：

• 临时应对：等 5-15 分钟再试，多数情况自动恢复。别在报错期间反复重试。
• 代码层应对：批处理加 sleep、失败重试用指数退避、把大任务拆成几个小批错开跑。
• 长期应对：如果你的正常工作量就长期撞限流（不是脚本问题），那才是档位不够，考虑升级。

怎么快速判断自己属于哪种

简单实验：停手 20 分钟，然后手动发一次普通请求。能正常返回 → 是限流，你的用法太密；仍然报额度类错误 → 是真的额度问题。

这个测试做完再决定要不要花钱，能省下不少冤枉钱。