用户求助：通过sub2api接入商汤SenseNova时Claude Code报错模型不存在

背景

在 AI 开发与应用实践中，开发者常利用中间件工具（如 sub2api）来统一 API 接口标准，从而实现对不同后端大模型服务的无缝切换。sub2api 能够将非 OpenAI 兼容格式的 API 转换为 OpenAI 兼容格式，使得支持 OpenAI 接口的客户端（如 Claude Code）能够调用其他厂商的模型服务。

近期，在 LINUX DO 社区中，有开发者分享了一个具体案例：尝试通过 sub2api 将商汤（SenseNova）的 API 接入 Claude Code 时，虽然基础连通性测试（发送 "hi"）正常，但在实际调用模型时却遭遇了 There's an issue with the selected model 错误。这一案例揭示了跨平台 API 兼容性及环境变量配置中潜在的技术陷阱。

核心内容

该案例的核心在于开发者试图绕过 Claude Code 对 Anthropic 原生接口的依赖，通过 sub2api 代理商汤（SenseNova）的 API 端点，以实现在 Claude Code 环境中使用商汤模型或解决特定网络/访问限制问题。

1. 环境配置与初步测试

• 工具链：使用 sub2api 作为中间代理，后端对接商汤的 SenseNova API（端点：https://token.sensenova.cn/v1）。
• 连通性验证：在 sub2api 层面直接发送 "hi" 请求，服务器回复正常，证明 sub2api 与商汤 API 之间的网络连通性和基础鉴权是成功的。
• 对比参照：开发者确认 sub2api 添加 OpenAI 官方的 Codex 服务并开启 /v1/messages 调度后，Claude Code 运行正常。

2. 故障现象 当 Claude Code 尝试通过环境变量指向 sub2api 端点时，报错如下：

● There’s an issue with the selected model (claude-opus-4-7[1m]). It may not exist or you may not have access to it. Run /model to pick a different model.

这表明 Claude Code 客户端在初始化或请求模型时，无法识别或访问指定的模型 ID。

3. 关键配置细节分析 开发者提供的 .env 配置存在明显的逻辑冲突和配置错误，这是导致问题的直接原因：

• 环境变量指向：
  • ANTHROPIC_BASE_URL: 指向 sub2api 的地址。
  • ANTHROPIC_AUTH_TOKEN: 指向 sub2api 的鉴权 Token。
• 模型 ID 严重错位：
  • 配置中设置了 ANTHROPIC_DEFAULT_HAIKU_MODEL、ANTHROPIC_DEFAULT_SONNET_MODEL、ANTHROPIC_DEFAULT_OPUS_MODEL 以及 CLAUDE_CODE_SUBAGENT_MODEL 全部指向 claude-opus-4-8[1m] 或 claude-opus-4-8。
  • 错误点 1：claude-opus-4-8 并非 Anthropic 官方发布的标准模型 ID（截至当前主流版本为 Opus 3 或 Sonnet 3.5 等，且命名规范通常为 claude-3-opus-20240229 等格式，opus-4 尚未广泛公开或命名如此）。
  • 错误点 2：即使假设存在该模型，Claude Code 在通过非 Anthropic 原生接口（即经过 sub2api 代理商汤 API）调用时，后端商汤 API 并不支持 Anthropic 的专有模型 ID 格式。商汤 API 通常使用其自身的模型命名规范（如 SenseChat-5 等）。
  • 错误点 3：sub2api 的作用是将请求转发给商汤 API，但 Claude Code 客户端硬编码了 Anthropic 的模型名称。当 Claude Code 发送请求时，它携带的是 Anthropic 格式的模型 ID，而商汤 API 无法识别这些 ID，或者 sub2api 未能正确地将 Anthropic 的模型 ID 映射为商汤支持的模型 ID。

4. 问题本质 报错信息明确指出模型不存在或无权限。在通过 sub2api 代理非 Anthropic API 的场景下，Claude Code 客户端发出的请求中包含了它认为合法的 Anthropic 模型 ID。由于后端是商汤 API，商汤 API 返回的错误信息可能被 sub2api 或 Claude Code 客户端解析为“模型不存在”，从而触发该 UI 提示。此外，配置中大量使用不存在的 claude-opus-4 系列模型 ID，进一步加剧了识别失败。

关键要点

• API 兼容性陷阱：sub2api 等中间件主要解决 HTTP 协议和 JSON 格式的兼容，但不自动处理模型 ID 的语义映射。客户端（Claude Code）发送的模型 ID 必须能被后端（SenseNova API）识别，或者中间件需具备强大的模型 ID 转换规则。
• 模型 ID 有效性：配置中使用的 claude-opus-4-8 等模型 ID 极可能是不存在的或错误的。Anthropic 的模型命名有特定规范，随意编造或过时的 ID 会导致客户端直接报错。
• 环境变量覆盖逻辑：ANTHROPIC_DEFAULT_*_MODEL 环境变量用于指定默认模型。如果这些变量指向的模型在后端不可用，Claude Code 将无法启动或运行。
• 连通性不等于功能正常：sub2api 能回复 "hi" 仅证明 HTTP 通道和鉴权有效，不代表模型推理接口和模型 ID 映射正确。
• 跨厂商调用的局限性：试图用 Anthropic 的客户端（Claude Code）直接调用非 Anthropic 的模型（商汤），需要确保中间件能完美处理模型名称的转换，否则客户端会因找不到“自己的”模型而报错。

意义与影响

• 对开发者的启示：在使用 API 代理工具时，必须仔细检查模型 ID 的映射关系。不能仅依赖连通性测试，还需验证模型列表接口（如 /v1/models）返回的内容是否与客户端期望一致。
• 工具链选择的考量：Claude Code 是为 Anthropic 模型深度优化的客户端，强行将其用于其他厂商的模型，除非有完善的模型 ID 转换层，否则会遇到大量兼容性问题。对于多模型切换，建议使用更通用的客户端（如 OpenWebUI、Text-Generation-WebUI 等）而非特定厂商的 CLI 工具。
• 配置严谨性：环境变量配置需严格遵循 API 文档。错误的模型 ID 不仅导致功能失效，还可能掩盖真正的网络或鉴权问题，增加排查难度。
• 社区协作价值：此类案例在社区中分享，有助于其他开发者避免在类似“跨厂商 API 代理”场景中踩坑，强调了在复杂技术栈中验证每个环节（网络、鉴权、模型映射、客户端配置）的重要性。