claude api的529与429怎样区分？529 overloaded_error表示服务暂时过载，429 rate_limit_error则指向组织速率限制、用量档位支出上限或特定工作区额度等条件。两者都可能使请求失败，但不能采用完全相同的恢复判断。fable 5.2与mythos 5.2曾有约四分钟的过载事件，官方已标记resolved；这条历史记录不代表所有后续错误都属于同一次故障。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
错误码表示原因层次，不只是成功或失败
应用看到失败后，需要区分请求本身、身份权限、额度和服务状态。暂时过载不意味着密钥失效；认证问题也不会因无限重试自动解决。HTTP状态、error.type与message应放在同一上下文理解，不能只凭“返回5xx”或“过去有公告”推断当前根因。
| 状态 | 常见类型 | 主要含义 |
|---|---|---|
| 529 | overloaded_error | API暂时过载 |
| 429 | rate_limit_error | 速率、使用档位支出上限或Claude Code工作区额度等限制 |
| 401 | authentication_error | 认证条件有问题，具体原因仍看消息 |
| 403 | permission_error | 无权访问指定资源 |
| 400 | invalid_request_error | 请求格式、内容或特定支出限制等条件 |
当前文档还区分普通组织或工作区自设支出限制通常返回400，而Claude Code工作区限额可能返回429。档位支出上限的429可能没有retry-after，并持续失败直到访问条件恢复；所以429不一定意味着短暂等待后即可恢复。
短时过载公告能证明什么
事件pgz8r13pk4sm明确点名Fable 5.2与Mythos 5.2，现象为约四分钟overloaded errors，说明已缓解。恢复说明发布于2026年11月10日21:47 UTC，即北京时间11月11日05:47。这个时间是公告发布时间，不能机械向前减四分钟构造精确故障窗口。
公告没有给出精确起止、受影响请求比例、区域分布或根因，也没有确认全部Claude模型、网页和客户端同时不可用。单个应用的失败是否与它有关，需要模型、时间与错误内容相符，不能把所有相似错误归到同一历史事件。
为什么request_id比一张报错印象更有用
API错误JSON通常含error对象，其中type描述类别、message提供细节，并带request_id；响应头还有request-id。请求时间及其时区、模型、请求ID和是否收到完整结果，能够将应用现象对应到具体调用。
请求ID是定位标识，不是模型输出或成功证明。同一业务任务如果发起多次调用，会涉及不同请求记录；业务上的“任务是否完成”也不能只由某个请求曾经返回200决定。完整响应和外部工具结果，需要与实际任务记录对应。
默认重试为什么可能与应用循环叠加
官方SDK会对连接错误、限流和5xx等暂时失败做指数退避，默认重试两次，并在提供retry-after时尊重该值。max_retries可以配置或关闭SDK重试。若外层再无条件套多次循环，单个业务任务的总请求量会被放大，而不是简单的“一次失败再试一次”。
429若由支出上限而非短时速率引起，继续发送不能自动解除限制；401、403和请求验证问题也需要对应处理。用量突然增长还可能触发加速限制，因此恢复流量不等于立即把所有积压请求同时释放。
流式200与工具副作用是两个容易遗漏的边界
SSE可能在HTTP 200返回后发生错误，初始状态只能说明连接已开始，不能保证生成已完整结束。半截文本不应被当作完整结果继续交给后续业务；长请求的非流式连接也可能因网络空闲中断，流式Messages或Message Batches是不同结果交付方式，需要按实时性与时长选择。
如果请求关联文件写入或外部工具动作，连接断开不证明这些动作都未发生。是否补做应依据目标系统实际完成记录，而非单靠模型响应是否完整。历史公告并未确认发生重复执行或数据损坏，这一边界属于通用业务恢复设计。
Resolved之后为什么仍可能看到新错误
状态页恢复意味着该已报告事件结束，不是对每个账户、客户端和后续请求的保证。新的429可能由流量增长或额度引起，认证与权限错误也可能独立存在；更换模型或密钥还涉及能力、授权与输出要求，不能仅由一次过载推导为必需措施。
故障归因应保留模型、请求标识和时区边界，恢复判断应同时考虑完整结果、重试层级与外部任务状态。这样才能把“服务恢复”“请求成功”和“业务动作完成”区分开，避免把历史过载当成所有失败的统一解释。
