API 429 rate limit 怎么解决？并发、限速与有限重试
429 通常表示请求触发了某种限制，但具体限制需要看错误正文。可能是请求频率、token 速率、并发或上游条件。OuraiC 没有公开证明所有分组都采用同一个限额，不应凭经验写固定数字。
图：按本文操作要点制作的说明图，不是后台或调用成功截图。
先降低实际压力
暂停批量任务，把并发减到较小规模，缩短单次输入，并检查是否同时运行多个客户端。共享 Key 的其他程序也可能消耗同一限制。
如果错误明确指向额度或其他条件，应按正文处理，不只增加等待时间。
自动重试怎样设计
仅对可重试的临时错误做有限重试。优先遵循服务返回的等待提示，再使用逐步增加等待加随机扰动的方式。给次数和整个任务设置上限。
不要出现应用重试、SDK 重试和工作流重试叠加。三层各重试几次，实际调用数量可能远超预期。
重试可能产生费用吗
失败、超时和客户端断开是否计费取决于请求处理情况。不能保证“看到错误就一定不收费”。应核对本站日志，查看是否已经发生生成或多次请求。
长任务重试要避免重复业务动作，尤其是工具调用或外部写入。API 的生成重试与业务操作重试应分别设计。
查限制来源
| 现象 | 检查方向 |
|---|---|
| 单请求也失败 | 额度、渠道或短期上游限制 |
| 并发增大后失败 | 请求频率与并发 |
| 长输入更易失败 | token 速率或模型条件 |
| 多个工具同时失败 | 共享凭据或渠道压力 |
这只是排查线索，不能代替错误正文与服务说明。
恢复步骤
先单条短请求，观察日志；成功后逐步增加负载。记录模型、分组、请求规模和时间，不用一次成功证明高并发稳定。
生产工作流可设置队列与预算，避免无界循环。必要时向支持确认分组现行限速，而不是换多个 Key 试图绕过限制。