LLM API 限流控制的是账号、项目或模型在一段时间内能接受多少流量。收到 429，只是排查的起点，不代表应该无限重试。先读错误正文、找出受限资源；如果需要改资金或配置，继续重试没有意义。
本文基于 2026 年 9 月 29 日核验的服务商文档。不同接口和账号的限制不同，不存在本文承诺的统一“每分钟请求数”。
重试前先给错误分类
保留 HTTP 状态、服务商错误码、时间、请求 ID 和相关响应头，不要记录认证头或私有提示词。
各服务商的术语不同。OpenAI 的限流文档说明了请求、Token 限制信息和重试处理；费用上限文档也说明，触发硬费用限制可以返回 429。所以不能只凭状态数字判断原因。
Codex 或 Claude Code 的订阅用量周期是另一类控制。API 报 429，并不能证明需要等待订阅额度重置。
请求数与 Token 都要纳入调度
一句短问题和一份仓库级上下文都算一次请求，但 Token 需求可能差很多。队列放行时，应考虑当前模型实际限制的维度。
举个假设的调度场景：多个 worker 同时提交长上下文，即使全天平均流量不高，也可能产生突发流量。应错开启动时间，并在多个 worker 之间共用并发限制。多个进程各自限流，不等于整个应用已经限流。
要算费用，而不是限流吞吐量，可用 Coding Agent API 费用工作表。缓存 Token 如何计入限制，要以当前服务商规则为准。
只保留一套有限重试策略
服务商返回 Retry-After 时，遵守它的等待要求；没有这个字段时，按官方建议逐步延长等待，并加入随机间隔，同时设置最大尝试次数和总截止时间。
先确认 SDK 是否已经自动重试。应用层再套一层重试，可能让请求数意外倍增。应指定一层负责重试，并记录最终尝试次数。
超时不代表第一次操作没有发生。重新请求模型，与重新执行写文件、发消息、创建外部资源的工具动作，是两件事。重复有影响的动作前，先核对旧动作结果，或使用目标系统支持的操作标识防重。
用小规模任务验证恢复
降低并发后，重跑一个受控任务，记录成功请求、最终失败、重试次数和完成时间。修复成功的标志是任务能在限制内完成，不只是错误提示消失。
如果仍失败，把脱敏请求标识和准确时间范围交给服务商。不要为了补偿限流而继续增加 worker。
接入时保留可核对的用量记录
Agent.Space Developer API 指南介绍了如何检查 Key、模型、协议和资金记录，便于区分连接问题与账号用量问题。
如果需要这条接入路径，可以打开 Agent.Space。先从一笔请求和较小的 worker 预算开始，不要把 API 接通理解成无限容量。