先把“请求成功”和“工具接入完成”分开验证
你按 AIGoCode 文档发出一次 API 请求，已经拿到回复；换到 Claude Code 或 Codex，却仍然报错。此时最有用的线索，是成功请求与失败工具之间有哪些配置差异。
一次请求成功，能够说明它所用的地址、认证信息和请求内容在那次调用中有效。工具实际选择了哪个供应商、使用哪个分组的密钥、怎样填写服务地址，还需要分别核对。不要仅凭一个成功响应，就把另一端的问题全部归到模型或网络上。
这篇指南按“确认成功样例 → 核对目标工具 → 核对地址与认证 → 按错误继续排查”的顺序，帮助你缩小 AIGoCode 工具连接失败的范围。具体安装和配置文件内容仍以对应工具文档为准。
第一步：记下成功请求究竟验证了什么
先保留一份不含密钥的记录：用了哪个接口、哪个模型，以及怎样判断成功。AIGoCode 的第一次请求分别提供不同协议的例子；这些例子并不能替代工具自身的验证。
| 你已经完成的验证 | 可以确认的范围 | 下一步仍需核对 |
|---|---|---|
| OpenAI Compatible 的聊天请求收到回复 | 这次聊天请求的配置跑通了 | Codex 当前选中的供应商和工具配置是否正确 |
| Claude Messages 请求收到回复 | 这次 Messages 请求的配置跑通了 | Claude Code 是否使用对应分组密钥，并启用了目标供应商 |
| 查询模型列表得到返回 | 该查询返回了当前 Key 可用的模型列表 | 工具所选模型以及实际对话是否能成功 |
认证文档说明，不同 API Key 返回的模型列表可能不同。因此，排查模型不可用时，记录测试所用的 Key 与工具配置是否对应即可；给他人描述问题时不要发送 Key 原文。
这里也不要推导“Codex 必然使用聊天请求示例的同一个 endpoint”。成功样例与工具接入是两个需要核对的配置对象。
第二步：按目标工具核对分组和启用状态
AIGoCode 当前的两份工具文档分别给出了以下接入要求：
| 目标工具 | 创建密钥时核对的分组 | 使用 CC Switch 导入后要完成的操作 |
|---|---|---|
| Claude Code | Claude Code（专用） | 在 CC Switch 的 Claude Code 页面，对 AIGoCode 供应商点击“启用” |
| Codex | Codex | 在 CC Switch 的 Codex 页面，对 AIGoCode 供应商点击“启用” |
先打开与你实际使用工具对应的Claude Code 文档或Codex 文档，核对密钥创建时的分组，再确认导入后有没有完成“启用”这一步。
文档把“一键导入”和“启用供应商”列为相邻但分开的操作。如果你只记得看到导入完成提示，建议继续检查对应工具页面上的启用状态。这个检查无需先重新安装工具。
这张表用于对照官方接入步骤，不据此判断所有分组密钥能否互通。也不要因为两个工具都由 CC Switch 管理，就假定在其中一个页面启用供应商已经完成了另一个工具的配置。
第三步：逐项对照地址和认证，别整套照搬成功样例
Base URL 文档把统一服务根地址列为 https://api.aigocode.app，并区分根地址与带协议路径的地址。它同时提醒，很多客户端会自行拼接 /v1、/v1beta 或具体 endpoint，填写方式应以对应工具教程为准。
对照时，把地址拆成三项看：服务域名、协议路径、具体接口路径。重点检查成功请求里的完整 URL，是否被原样填进了只要求服务根地址或协议地址的字段。出现 404 时，官方文档把 /v1 或 /v1beta 多填、少填列为常见排查方向。
认证也要和所用接口一起核对。首次请求文档的 OpenAI Compatible 示例使用 Authorization 请求头；Claude Messages 示例则展示了 x-api-key 和 anthropic-version。因此，一个协议的成功样例不能直接充当另一个接口或工具的完整配置模板。
建议只比较这些非敏感信息：
- 测试请求和失败工具各自使用的服务地址。
- 密钥是否填在该工具教程要求的字段里，复制时是否带入多余空格。
- CC Switch 中核对的是 Claude Code 页面还是 Codex 页面。
- 工具选择的模型名称是否与正在排查的配置对应。
如果选择手工配置，请回到对应工具文档查看具体字段。不要在缺少依据时，猜测环境变量与配置文件的覆盖顺序，或同时改动多处配置。每核实、修正一项后，再用同一个工具验证，比较错误是否发生变化。
第四步：根据工具这次返回的错误选择下一步
继续失败时，保留 HTTP 状态码和响应体中的错误信息。官方错误码说明建议先看状态码，再看响应体。下面按该文档整理排查方向，单个状态码不能证明唯一原因。
| 看到的现象 | 优先核对 |
|---|---|
401 或提示 Key 无效 | Key 是否完整、是否仍有效、是否填错工具字段；认证方式按所用接口或工具文档核对 |
403 且伴随余额、额度或订阅提示 | 控制台余额和用量信息，不要先反复更换服务地址 |
413 | 输入、文件、历史消息或上下文是否过大；减少本次输入后再验证 |
429 | 是否同时开了多个工具或会话，或短时间重试过快；先降低并发、等待片刻 |
5xx | 记录错误信息，稍后重试；持续影响使用时联系支持 |
例如，已经收到明确的 413 后，下一次测试可以先缩短输入；遇到 429 时，可以先减少同时运行的请求。把验证动作与错误对应起来，比一次改动密钥、地址和模型更容易判断是哪项变化起了作用。
最后，在出问题的工具里完成一次验证
两份接入文档都要求进入代码项目目录后启动对应工具：Claude Code 使用 claude，Codex 使用 codex，并以工具能正常读取项目、给出回复作为接入完成的判断依据。回到最初失败的那个工具完成这一步，才能结束这次排查。
你可以保留一张简短记录：目标工具、密钥分组、服务地址的填写方式、所选模型、最后一次错误，以及这次只调整了哪一项。记录和求助材料均不包含真实 API Key。
如果接下来要在同一项目中组合两套工具，可继续阅读Claude Code 写，Codex 查：两个 AI 协作时的四个边界。先分别验证接入，再检查组合工作流，排查范围会更清楚。