HTTP 429

HTTP 429响应中的Retry-After头由服务器告知客户端需等待的秒数，优先读取该值优于自行计算

在 CrewAI 或 LangGraph 等智能体框架中，未处理的 HTTP 429 会立即终止整个执行运行，破坏已积累的上下文并浪费 token 成本。

不同错误类型（如 429 限流与 500 内部错误）对应的重试策略和降级方案截然不同。

免费层级通常有速率限制（如RPM、TPM、RPD）、上下文长度限制或功能限制，触发后通常返回HTTP 429。

HTTP 503表示提供商一侧暂时不可用，通常与调用频率无关；429表示调用方超出单位时间配额，响应头常带Retry-After。503适合指数退避重试，429更适合切换备用模型或延后到下一周期。

静默丢弃数据的接收方比直接拒绝数据的接收方更糟糕，因为429状态码能告诉发送方重试。

HTTP 429表示客户端在给定时间内发送了过多请求，通常伴随Retry-After头指示重试等待时间。

429（Too Many Requests）错误表示超出速率限制或配额，通常需要等待。

AWS Bedrock文档建议对503进行重试，429则需检查限流配置，因为Bedrock的配额与IAM策略关联。

OpenAI的429错误可能由速率限制或配额耗尽引起，配额耗尽错误（如 insufficient_quota）不应重试。

开发中作者收到 HTTP 413 和 429 错误，修复策略分三步：减少单次请求量（一次只处理一个游戏的一个语言组）、限制 max_tokens、请求之间等待 70 秒（空闲时 240 秒）。

符合 HTTP 语义的服务在返回 429 时往往附带 Retry-After 响应头，指明建议等待秒数，客户端应优先遵循该值。

TTS 服务通常按分钟限制请求数，超限会返回 429 Too Many Requests。

当数据源返回 429 时表示被限流，可采取退避、加大缓存力度或增加第二个 key 等应对措施；429 不是模型问题

HTTP 429 状态码由 RFC 6585 定义为 'Too Many Requests'，属于可重试状态码，与 401（鉴权失败）、403（权限不足）本质不同。

对于 HTTP 429，应检查 Retry-After 头，若存在则用其值替代计算出的退避延迟。

应重试的 HTTP 状态码包括：429、502、503、504，以及连接重置、超时等网络层故障。

429状态码通常表示该密钥下的特定模型已达限额，而非整个密钥已用完，因此可以尝试同一密钥下的其他模型。

HTTP 429状态码表示服务端限速，通常附带Retry-After头部；HTTP 403表示访问被直接拒绝，可能因IP黑名单、User-Agent被识别为爬虫或缺少认证信息。

文章指出，HTTP 429是基础设施税而非模型失败，编排层应实现指数退避、令牌桶或跨运行的配额调度来应对。