先记录错误，再决定检查哪一边
AIGoCode 请求失败时，工具可能只显示“连接失败”或“请求被拒绝”。如果已经能看到 401 或 403，下一步应把 HTTP 状态码与响应体中的错误信息放在一起看，而不是同时更换密钥、地址和套餐。
官方《错误码说明》把 401 的排查重点放在 API Key 与认证填写，把伴随余额、额度或订阅不足提示的 403 指向账户额度。下面围绕这两个分支整理操作顺序；它们是排查方向，单凭一个数字不能确定唯一原因。
401：核对当前请求实际使用的认证
先在本机确认这次请求选中了哪把 Key。检查复制是否完整、Key 是否已经删除，以及工具是否填错字段。这些都是官方文档列出的 401 可能原因。不要在工单或聊天中贴出真实 Key，用自己能识别的密钥名称或本地代号即可。
随后按实际使用的接口核对认证格式。AIGoCode 第一次请求中的 OpenAI Compatible 示例使用 Authorization: Bearer；Claude Messages 示例使用 x-api-key，同时带有 anthropic-version。因此，检查时要对照对应接口的示例，不能看到 401 就把所有请求都改成同一种认证头。这里说明的是文档示例，不表示不同工具或密钥分组可以任意互换。
可以按以下顺序做一次对照：
- 保留原来的状态码与脱敏后的错误信息，记下使用的客户端、接口类型及请求地址的域名和路径。
- 在本机重新复制当前 Key，确认填入的是目标工具要求的字段，不把整条认证头当作密钥值。
- 保持地址、模型和请求内容不变，重新发起一次相同的简单请求，记录错误是否变化。
- 仍然返回 401 时，再按官方建议考虑重建 Key。重建后仍失败，带上脱敏记录联系支持。
第三步是为了比较这次认证调整是否影响了结果，不是对成功率或扣费的保证。排查过程中不需要连续高频重试。
403 且提示额度不足：回到控制台核对
如果响应体提到余额、额度或订阅不足，就先检查控制台的余额和用量记录。官方文档列出的可能原因包括余额不足、套餐额度尚未恢复以及周限额已触发；这时反复重建 Key 并不能解释额度状态。
官方《额度与限制》说明，部分套餐有容量、恢复周期和周限额，实际权益以控制台展示及服务端配置为准。把以下几项分开记录：
| 要核对的项目 | 记录什么 | 下一步 |
|---|---|---|
| 错误提示 | 是否明确提到余额、额度或订阅不足 | 先确认本次错误是否进入额度分支 |
| 控制台状态 | 当前可见余额、用量及套餐限制信息 | 与失败请求的时间对照 |
| 恢复或周限额 | 是否仍在恢复周期内，是否有周限额相关提示 | 按实际显示的规则处理，不猜恢复时间 |
| 显示异常 | 控制台状态与错误提示有哪些具体不一致 | 保存脱敏记录并联系支持 |
不要只凭“订阅还有效”推断本次请求一定有可用额度，也不要根据错误码擅自推算固定恢复时间。如果确实需要调整套餐，应先核对实际权益与限制，再作决定。若只有 403、没有额度相关信息，先保留完整的脱敏错误描述，请支持协助判断，不直接认定必须升级套餐。
错误改变后，停止沿用旧判断
认证调整后从 401 变成另一个状态码，要按新的错误信息继续排查。例如，官方说明将 429 与同时请求过多、工具自动并发和短时间重试过快联系起来。看到新错误，就记录这次改了什么、何时验证，以及新响应是什么；不要把所有结果都归入“Key 无效”。
如果简单 API 请求已经成功，而 Claude Code 或 Codex 仍然失败，可继续阅读本站工具接入四步核对，对照目标工具的密钥分组、启用状态与地址填写方式。该教程处理工具与成功请求之间的配置差异，本文处理拿到 401 或额度相关 403 后的分支选择。
联系支持前，准备一份不含密钥的记录
建议记录：失败时间、客户端与版本、接口类型、请求域名和路径、状态码、脱敏错误描述、已经调整过的单个项目，以及控制台可见的相关额度状态。地址中若有携带密钥的查询参数，分享前必须去掉；认证头和真实 Key 也不应出现在截图或日志里。
这份记录的价值是让下一位排查者看清“同样的请求在修改哪一项之后发生了什么变化”。401 先核对认证，额度相关 403 先核对控制台，未能确定的原因明确标为待确认，才能减少无依据的反复改配置。