先保留报错，再缩小同时运行的范围
一个会话能正常回复，另外几个任务一启动就出现 429 Too Many Requests，排查时先记录“哪些任务同时运行”，再改变并发安排。这个现象值得检查并发，但还不足以确定限流发生在哪一层。
AIGoCode 的错误码说明把同时请求过多、工具自动并发和短时间重试过快列为 429 的可能原因，建议降低并发、关闭多余客户端，等待片刻后再试。下面把这些建议整理成一轮可以记录和比较的排查步骤，适用于已经能独立完成请求、在并行工作时开始失败的场景。
第一步：确认这次确实是 429
保留 HTTP 状态码、响应体错误信息和发生时间。工具只显示“连接失败”时，先从它提供的错误详情或日志中找状态码，不要直接按 429 处理。
尤其要把两个问题分开：
- 429：优先查看同时运行的请求、工具并发和重试情况。
- 403 且伴随余额或额度提示：查看控制台额度与用量。官方额度与限制说明，余额或周限额不足时，请求可能返回 403。
不要仅凭“账户还有余额”排除并发问题，也不要把所有失败都当成需要充值。实际套餐权益以控制台展示和服务端配置为准。
第二步：列出正在工作的入口
把你能确认的终端会话、编辑器中的助手、脚本和其他客户端写在同一张清单里，标记哪些正在请求、哪些正在重试。清单可以只写本地代号，不记录 API Key 原文。
这里要区分“打开的窗口”和“实际发出的请求”。官方文档提到了工具自动并发，因此不能直接把窗口数量当作请求并发数；也不能据此认定不同工具一定共享同一限额。先记下可观察到的活动，具体限流范围仍需要结合错误信息确认。
排查时先暂停能够安全暂停的额外任务，保留一个原先能正常工作的会话。不要为了让报错消失，一次改动密钥、地址、模型和输入内容，否则即使恢复，也难以知道哪个变化有效。
第三步：做一次单会话对照，再逐个恢复
停止额外请求后，按官方建议等待片刻，再在保留的会话中发送一个简短任务。不要在等待期间连续手动重试；如果工具仍在自动重试，也把这一情况记录下来。
这一步建议保持工具、模型和输入尽量一致，仅改变同时工作的入口数量。观察结果后，再决定下一步：
| 观察结果 | 下一步动作 | 能得到的线索 |
|---|---|---|
| 单会话恢复正常 | 先完成这次请求，再逐个恢复额外任务 | 记录 429 是否随某个任务恢复而再次出现 |
| 单会话仍返回 429 | 核对是否还有其他入口或重试活动；持续出现时联系支持 | 仅关闭窗口还不足以确认触发原因 |
| 错误变成 401、403 或其他状态 | 保存新的状态码，按对应错误继续排查 | 不把不同错误混成一次“连接失败” |
逐个恢复的目的，是保留可以比较的变化记录，并非测算或突破服务端上限。不要不断加任务去碰限流边界，也不要把“一次成功”写成并行运行已经稳定的结论。
如果连单独运行的基础接入都尚未验证，可先参考本站的工具连接排查指南梳理检查顺序，具体地址和配置仍以当前工具 Docs 为准，再回到这里排查并行场景。
第四步：把结果整理成可追踪的求助材料
官方错误码说明建议，429 长时间持续出现时再联系支持。与其只发送“又限流了”，可以提供以下脱敏记录：
- 发生时间和时区、所用工具及版本、模型名称。
- HTTP 状态码与错误原文；发送前移除密钥、认证头和敏感业务内容。
- 当时有哪些入口正在工作，是否观察到自动并发或连续重试。
- 暂停了哪些任务，单会话测试的结果，恢复某个任务后现象是否变化。
- 控制台展示的相关额度或限制信息，以及仍然无法确认的部分。
这份记录的价值，是让支持人员能区分“单会话也持续失败”和“恢复并行任务后才失败”。你不需要先猜出后台采用了哪种限流算法，也不需要反复更换密钥。先完成一次有记录的对照，保留错误随操作变化的证据，再决定如何调整日常任务安排。