在 CC Switch 中配置 API 中转站时，HTTP 200 并不能直接证明模型接口已经接通。2026-07-24，我对 LinkAGI 的 4 条最终路径做了不带 Key 的请求验证：正确的 /v1/responses 与 /v1/messages 返回 JSON 401；重复的 /v1/v1/messages 返回 JSON 404；错误的 /responses 却返回 HTTP 200 和 HTML 页面。

LinkAGI 是供 Codex、Claude Code、Gemini CLI 与 OpenAI-compatible 客户端接入模型 API 的中转站，服务地址为 api.linktoagi.com。本文重点不是推荐某个模型，而是复现 CC Switch 中最容易被忽略的 Base URL 拼接问题，并给出可复用的检查方式。

这个案例的结论很简单：判断 API 是否连通，要同时检查 状态码、Content-Type 和响应体。如果只检查 status_code == 200，Web 前端回退页也可能被误判为 API 成功。

1. CC Switch 管配置，不提供模型接口

CC Switch 可以集中管理 Claude Code、Codex、Gemini CLI 等工具的 Provider、API Key、模型和配置文件，也可以在多套配置之间切换。它解决的是“怎样管理本地配置”，不是“怎样把错误路径自动修好”。

一次请求能否成功，仍取决于：

• Base URL 与客户端追加路径是否匹配；
• API Key 是否有效并被当前进程读取；
• 上游协议是否为 Responses、Messages 或其他格式；
• 模型名、令牌分组和余额是否允许此次调用。

截图来自 CC Switch 官方仓库。当前本机安装版本为 3.11.0，官方最新 Release 为 3.18.0，因此按钮位置以用户实际版本为准。本文讨论的地址拼接与 HTTP 判断不依赖具体 UI 布局。

2. Codex 与 Claude Code 为什么不能照抄地址

2.1 Codex / Responses

Codex 使用 Responses 协议时，目标路径是：

https://api.linktoagi.com/v1/responses

客户端会自动追加 /responses，因此 Base URL 应填：

https://api.linktoagi.com/v1

当前 Codex 官方手册给出的自定义 Provider 结构包含 model_provider、[model_providers.<id>]、base_url、env_key 与 wire_api。对应 LinkAGI 的最小结构可以写成：

model_provider = "linkagi"
model = "从实时模型广场复制"

[model_providers.linkagi]
name = "LinkAGI"
base_url = "https://api.linktoagi.com/v1"
env_key = "LINKAGI_API_KEY"
wire_api = "responses"

提供方配置应放在用户级 ~/.codex/config.toml。项目级 .codex/config.toml 不能覆盖 model_provider、model_providers 或 openai_base_url，这是“配置明明写了却没生效”的一个常见来源。

2.2 Claude Code / Messages

Claude Code 会继续追加 /v1/messages，所以 Base URL 使用根地址：

https://api.linktoagi.com

最终得到：

https://api.linktoagi.com/v1/messages

如果把 Codex 地址直接复制给 Claude Code：

https://api.linktoagi.com/v1

客户端再追加 /v1/messages 后，就可能得到错误的：

https://api.linktoagi.com/v1/v1/messages

3. 4 条路径的请求结果

测试没有携带 API Key，只用于验证公开路由与响应类型。它不会证明模型可用，也不会产生模型输出。

路径	HTTP	Content-Type / 结果	判断
/v1/responses	401	JSON	正确到达 Codex 鉴权层
/v1/messages	401	JSON	正确到达 Claude Code 鉴权层
/v1/v1/messages	404	JSON	/v1 重复
/responses	200	HTML	命中 Web 前端回退，不是 API 成功

3.1 为什么 401 在这里比 200 更有诊断价值

401 表示请求已到认证边界，但没有提供有效凭证。它不能证明模型名、分组、余额或上游状态正常，却能说明域名、TLS 和目标 API 路由至少没有停在网页层。

反过来，/responses 的 200 来自 HTML 首页。状态码看起来更“成功”，但内容完全不是客户端期望的 JSON。

3.2 可复用的 Python 检查

不要只判断状态码。至少确认 Content-Type：

import requests

url = "https://api.linktoagi.com/responses"
response = requests.post(url, json={}, timeout=20)
content_type = response.headers.get("content-type", "")

print("status:", response.status_code)
print("content-type:", content_type)
print("preview:", response.text[:120])

if response.status_code == 200 and "application/json" in content_type:
    print("收到 JSON，继续检查 API 字段")
else:
    print("不能认定 API 调用成功")

即使收到 JSON 200，也要继续核对返回字段和控制台使用日志。状态码检查只是第一层，不是最终验收。

4. CC Switch 中的建议配置顺序

第一次接入时，不建议同时配置多个应用。可以先完成 Codex：

1. 新增应用专属 Provider，命名为 LinkAGI Codex；
2. Base URL 填 https://api.linktoagi.com/v1；
3. 协议选择 Responses；
4. 从控制台创建独立 Key；
5. 从实时模型广场复制模型名；
6. 启用后完全退出并重启 Codex；
7. 用短请求验证，再到使用日志核对模型、状态、Token 和费用。

Codex 跑通后，再新增 Claude Code Provider：

1. 名称使用 LinkAGI Claude Code；
2. Base URL 填 https://api.linktoagi.com；
3. 使用另一个独立 Key，便于限额、撤销和排错；
4. 选择与令牌分组匹配的模型；
5. 启用后重启目标进程；
6. 确认最终请求路径为 /v1/messages。

5. 切换后仍然走旧地址怎么办

检查运行中的旧进程

部分 CLI 只在启动时读取配置和环境变量。CC Switch 切换成功后，已经运行的进程不一定自动刷新。完全退出目标 CLI，再从新终端启动。

检查环境变量覆盖

当前 shell 里遗留的 OPENAI_BASE_URL、OPENAI_API_KEY、ANTHROPIC_BASE_URL 等变量，可能覆盖配置文件。不要只看 CC Switch 当前卡片，还要检查实际启动进程继承了什么。

展开最终 URL

把 Base URL 和客户端追加部分完整写出来：

Codex:
https://api.linktoagi.com/v1 + /responses

Claude Code:
https://api.linktoagi.com + /v1/messages

如果看到了 /v1/v1/、/responses/responses 或只剩根域名，先修路径，不要先换 Key 或模型。

检查响应类型

• 200 text/html：通常是网页，不是模型接口；
• 401 application/json：到达鉴权层，继续检查 Key；
• 404 application/json：检查路径和协议；
• 模型相关 JSON 错误：再检查模型名、分组与当前状态。

6. LinkAGI 在这个流程中的位置

LinkAGI 提供 Codex、Claude Code、Gemini CLI 与 OpenAI-compatible 客户端的模型 API 接入，控制台用于创建 Key、查看模型实时价格和核对使用日志。CC Switch 则负责把这些配置写入和切换到本地工具。

实时模型与价格：https://api.linktoagi.com/pricing

中文文档：https://docs.linktoagi.com

问题反馈、商务咨询与企业技术支持位于文档的“关于与支持”页面。模型、号池与价格以实时页面为准。

本文只保留一个后续动作：打开 https://docs.linktoagi.com/cc-switch-api.html，按当前客户端复制正确 Base URL，再用“状态码 + Content-Type + 响应体”三项检查验证。

总结

CC Switch 能减少手工编辑配置，但不会替你理解客户端路径规则。对 LinkAGI 而言，Codex Base URL 保留 /v1，Claude Code 使用根地址；一个错误路径甚至可能返回 HTTP 200 和 HTML 页面。

因此，最小验收标准不应是“网页能打开”或“状态码是 200”，而应是：最终 URL 正确、响应类型符合协议、有效 Key 的短请求成功，并且控制台使用日志能够对应上这次调用。

实测日期：2026-07-24。CC Switch 界面图来自官方 GitHub 仓库。