企业官网建设流程全解析

9Router 报 Model not found（模型 ID 格式错误）怎么排查？

【免费下载链接】9routerUnlimited FREE AI coding. Connect Claude Code, Codex, Cursor, Cline, Copilot, Antigravity to FREE Claude/GPT/Gemini via 40+ providers. Auto-fallback, RTK -40% tokens, never hit limits.项目地址: https://gitcode.com/GitHub_Trending/9r/9router

在 9Router 中配置 Claude Code、Codex CLI 等工具后，请求返回 "Model not found" 或 "Invalid model" 错误，通常意味着三件事之一：模型 ID 拼写或格式写错了、对应的提供商没有连接、或者提供商处于未激活状态。本文按 9Router 官方故障排除文档给出的顺序，把这条排查路径走一遍：先确认服务在运行，再核对模型 ID 格式，然后用 API 列出真实可用的模型，最后检查并提供商重连。完成排查后，你能通过GET /v1/models接口确认目标模型确实存在，再回到客户端重发请求验证。

适用前提：9Router 已通过npm install -g 9router安装并用9router命令启动，API 地址为http://localhost:20128/v1，仪表板在http://localhost:3000。

先确认 9Router 本身在运行

如果服务没起来，客户端报的"模型不存在"其实是连不上服务时的误导信息。文档给出的健康检查命令：

curl http://localhost:20128/health

文档示例中的预期响应是：

{"status": "ok"}

如果这条命令都连不通，先回到"连接被拒绝"的排查：确认端口 20128 在监听（lsof -i :20128，Windows 用netstat -ano | findstr :20128），必要时重新启动 9Router。健康检查通过后，再往下走模型相关的排查。

核对模型 ID 的格式

9Router 的模型 ID 必须是[provider-prefix]/[model-name]两段式格式，中间用/分隔。故障排除文档给出的对照：

正确: cc/claude-opus-4-5-20251101 错误: claude-opus-4-5-20251101

最常见的错误就是漏掉提供商前缀（比如把claude-opus-4-5-20251101直接填进了 Codex CLI 或 Cursor 的模型配置里）。另外，集成文档特别强调模型名区分大小写，要用完整精确的模型名。文档中另一处示例错误为Error: Model 'cc/claude-opus' not found（文档示例），说明即使前缀写对了，模型名本身不完整（缺少日期版本后缀）同样会报 404。

各提供商前缀对应的正确模型 ID 可以查各层级的提供商文档，例如订阅层（subscription providers）中 Claude Code 的三个模型：

如果你用的是 Codex CLI（集成文档），前缀是cx，文档列出的可用模型为cx/gpt-5.2-codex和cx/gpt-5.1-codex-max。

用 /v1/models 列出真实可用的模型

改完格式后不要直接猜，用 9Router 自己的模型列表接口核对。命令来自故障排除文档，其中your-api-key需要替换为你在仪表板（Dashboard → Settings → API Keys）生成的 key，该 key 以9r_前缀开头：

curl http://localhost:20128/v1/models \ -H "Authorization: Bearer your-api-key"

判断方法：返回列表里能找到你请求的模型 ID（完全一致、大小写一致），说明格式没写错，问题在提供商连接；找不到，则回到上一节继续核对格式。如果这一步直接报 401 / Invalid API key，那是 key 的问题，按同一份文档的 "API Key Invalid" 一节处理（重新生成 key，确认带9r_前缀）。

检查提供商连接状态

模型 ID 正确但仍报 not found 时，按文档检查提供商：

Dashboard → Providers → Check status (green = active)

状态为绿色表示该提供商已激活。对应 "Model not found" 的三类原因——提供商未连接、模型 ID 拼写错误、提供商未激活——前两类在上两步已处理，剩下的处理方式就是重新连接：

Dashboard → Providers → [Provider] → Reconnect → Complete OAuth flow again

如果之前完成过 OAuth，这里会重新走一遍登录流程。Codex CLI 集成文档对 "model not available" 错误给出的是同一套核对项：模型名与 9Router 配置一致、提供商连接在仪表板中处于 active、该模型在你已连接的提供商范围内可用。

回到客户端验证

修复完成后，在原来的客户端重发一次请求即可。以 Codex CLI 为例，配置正确的OPENAI_BASE_URL和模型名后：

codex --model cx/gpt-5.2-codex "Write a function to sort an array"

能正常返回内容即说明 "Model not found" 已解决。若仍报错，按现象分流：401 走 API key 排查，连接失败走 20128 端口/防火墙排查，都在这份 故障排除文档 内有对应章节；OpenAI 兼容客户端侧的其他报错（超时、限流）可参考 其他工具集成文档 的 Troubleshooting 部分。

限制与注意

• /v1/models列出的模型只来自已连接且激活的提供商，未连接的提供商下的模型不会出现在列表里，不要据此推断"9Router 不支持该模型"。
• 文档没有提供"模型名模糊查询"之类的工具，列表核对时以精确字符串匹配为准。
• 本文的端口、路径和命令均基于本地部署（http://localhost:20128/v1）。如果你走的是云端 endpoint（如 Cursor 场景），把localhost:20128换成文档给出的云端地址即可，排查逻辑不变。

【免费下载链接】9routerUnlimited FREE AI coding. Connect Claude Code, Codex, Cursor, Cline, Copilot, Antigravity to FREE Claude/GPT/Gemini via 40+ providers. Auto-fallback, RTK -40% tokens, never hit limits.项目地址: https://gitcode.com/GitHub_Trending/9r/9router