Retry-After
HTTP 响应头，服务端用于明确告知客户端应当等待多久再重试，单位可以是秒数或 HTTP 日期。
核心事实
时间轴 (近 90 天)
Anthropic文档明确要求客户端遵循429响应中的retry-after头。
Anthropic文档指出，由月度支出上限触发的429响应没有retry-after头，且会持续失败直到额度重置。
在遵守retry-after基础上叠加全抖动后，最后一个调用在11.8秒完成，发送313次请求，p95为9.1秒，每项指标均优于两种退避公式。
Retry-After 头有两种格式：秒数（如 Retry-After: 120）或HTTP日期（如 Retry-After: Wed, 21 Oct 2026 07:28:00 GMT）。
Anthropic API返回529错误表示服务过载，通常伴随 Retry-After 头，官方建议对529进行重试并遵循退避策略。
符合 HTTP 语义的服务在返回 429 时往往附带 Retry-After 响应头，指明建议等待秒数，客户端应优先遵循该值。
收到429时应从约500ms开始实施带随机抖动的指数退避，如存在Retry-After响应头则至少等待该时长；忽略Retry-After或使用固定间隔重试会为整个团队延长中断时间。
对于 HTTP 429，应检查 Retry-After 头，若存在则用其值替代计算出的退避延迟。
Retry-After 是 HTTP 响应头，服务端用它明确告知客户端应当等待多久再重试，单位可以是秒数或 HTTP 日期；客户端应优先遵守 Retry-After，只有该头缺失时才退回指数退避。
代码中的重试循环最多尝试 4 次，指数退避从 500 毫秒开始，并在服务提供 Retry-After 响应头时优先遵守该头部值。
还有 7 条时间轴事件
全部知识事实 (17)
Retry-After 是 HTTP 标准响应头，服务端在返回 429 或 503 时通过该头部告知客户端应等待多少秒后再重试
75%已验证HTTP 429响应中的Retry-After头由服务器告知客户端需等待的秒数，优先读取该值优于自行计算
65%已验证指数退避机制的核心思想是每次重试等待时间按指数增长，并加入随机抖动以避免惊群效应
65%待验证Anthropic文档指出，由月度支出上限触发的429响应没有retry-after头，且会持续失败直到额度重置。
50%待验证Anthropic文档明确要求客户端遵循429响应中的retry-after头。
50%待验证在遵守retry-after基础上叠加全抖动后，最后一个调用在11.8秒完成，发送313次请求，p95为9.1秒，每项指标均优于两种退避公式。
50%待验证Anthropic API返回529错误表示服务过载，通常伴随 Retry-After 头，官方建议对529进行重试并遵循退避策略。
50%待验证Retry-After 头有两种格式：秒数（如 Retry-After: 120）或HTTP日期（如 Retry-After: Wed, 21 Oct 2026 07:28:00 GMT）。
50%待验证符合 HTTP 语义的服务在返回 429 时往往附带 Retry-After 响应头，指明建议等待秒数，客户端应优先遵循该值。
50%待验证收到429时应从约500ms开始实施带随机抖动的指数退避，如存在Retry-After响应头则至少等待该时长；忽略Retry-After或使用固定间隔重试会为整个团队延长中断时间。
50%待验证对于 HTTP 429，应检查 Retry-After 头，若存在则用其值替代计算出的退避延迟。
50%待验证Retry-After 是 HTTP 响应头，服务端用它明确告知客户端应当等待多久再重试，单位可以是秒数或 HTTP 日期；客户端应优先遵守 Retry-After，只有该头缺失时才退回指数退避。
50%待验证代码中的重试循环最多尝试 4 次，指数退避从 500 毫秒开始，并在服务提供 Retry-After 响应头时优先遵守该头部值。
50%待验证部分API会在429响应中通过Retry-After响应头明确告知客户端应等待多少秒，使用该值比盲目退避更精准
50%待验证对于非法的 Retry-After 值，SDK 现在会直接忽略，并对 maxRetries 进行校验
50%待验证v1.6.0 修复了重试逻辑，使客户端尊重超过 60 秒的 Retry-After 值，此前因上限限制会过早重试
50%待验证部分 API 在返回 429（Too Many Requests）时会通过 Retry-After 响应头告知客户端应等待多久，此时应以该值为准
50%