在使用gemini-3.1-pro-preview时，重定向模型会出现503错误，gemini-cli 的 customtools 模型已发生重定向，但后续仍按原始模型名校验，导致请求失败

[flowing-water1]

问题描述

我目前通过 claude-code-hub 作为中转服务给 Gemini CLI 分发请求。

在 Gemini CLI 中，官方实际使用的模型名是：

gemini-3.1-pro-preview-customtools

如果不做模型重定向，上游会返回 503，但从错误体来看，真实原因其实是 model_not_found。

随后我尝试在 provider 中配置模型重定向：

gemini-3.1-pro-preview-customtools -> gemini-3.1-pro-preview

从日志看，重定向已经成功发生；但请求后续仍然失败，并出现：

ProviderSelector: No providers support the requested model

而这里日志里的 requestedModel 仍然是原始模型名 gemini-3.1-pro-preview-customtools。

这让我怀疑：模型重定向虽然已经执行，但后续某一段 provider 支持性校验仍然使用了原始模型名，导致请求被错误拦截。

运行环境

• 部署方式：Docker Compose
• 镜像：ghcr.io/ding113/claude-code-hub:latest
• 本地版本参考：0.6.4
• 发现时间：2026-03-19

复现步骤

1. 配置一个 gemini provider，通过中转/分发上游转发请求
2. 使用 Gemini CLI 发起请求
3. Gemini CLI 请求模型为 gemini-3.1-pro-preview-customtools
4. 在 provider 中配置模型重定向：
   • gemini-3.1-pro-preview-customtools -> gemini-3.1-pro-preview
5. 再次发起请求

实际表现

情况 1：未配置重定向

请求会直接失败，返回 503，但上游错误体显示实际是 model_not_found。

日志片段：

requestedModel="gemini-3.1-pro-preview-customtools"

Provider <provider> returned 503: new_api_error:
No available channel for model gemini-3.1-pro-preview-customtools under group <group> ...
Upstream: {"error":{"code":"model_not_found","message":"No available channel for model gemini-3.1-pro-preview-
customtools under group <group> ...","type":"new_api_error"}}

### 情况 2：已配置重定向

日志显示模型重定向已经成功执行：

originalModel="gemini-3.1-pro-preview-customtools"
redirectedModel="gemini-3.1-pro-preview"
msg="[ModelRedirector] Model redirected"

但随后仍然失败，并出现：

requestedModel="gemini-3.1-pro-preview-customtools"
msg="ProviderSelector: No providers support the requested model"

## 期望行为

我期望以下任一行为成立：

1. claude-code-hub 对 Gemini CLI 的 -customtools 模型名自动做兼容处理/归一化
2. 一旦模型重定向已经生效，后续 provider 支持性校验、转发逻辑也应统一使用重定向后的模型名，而不是继续使用原始模型名

## 怀疑相关位置

根据现象，问题可能与以下模块之间的协作有关：

- src/app/v1/_lib/proxy/model-redirector.ts
- src/app/v1/_lib/proxy/provider-selector.ts

从日志看，ModelRedirector 已经把：

gemini-3.1-pro-preview-customtools -> gemini-3.1-pro-preview

但后续 ProviderSelector 仍然基于原始模型名报：

No providers support the requested model

## 附加日志片段

下面是我本地容器中的实际日志（已做适度脱敏）：

{"requestedModel":"gemini-3.1-pro-preview-customtools","msg":"ProviderSelector: Selection decision"}

{"statusCode":503,"error":"Provider <provider> returned 503: new_api_error: No available channel for model gemini-3.1-
pro-preview-customtools under group <group> ...","msg":"ProxyForwarder: Non-retryable client error, stopping
immediately"}

{"originalModel":"gemini-3.1-pro-preview-customtools","redirectedModel":"gemini-3.1-pro-
preview","msg":"[ModelRedirector] Model redirected"}

{"requestedModel":"gemini-3.1-pro-preview-customtools","msg":"ProviderSelector: No providers support the requested
model"}

[coderabbitai]

⚠️ Possible Duplicate Issue(s)

• 重定向的模型(可供用户请求的模型名)，在"决策链"中，未被识别为可用模型 #786

🔗 Related PRs

#517 - feat: 新增 /v1/models 端点，聚合返回用户可用模型列表 [merged]
#528 - test(models): 为 available-models 工具函数添加单元测试 [merged]
#633 - Fix provider exhaustion after model redirect (refs #629) [merged]
#693 - fix: 修复 buildProxyUrl 重复拼接版本前缀的问题（Gemini） [merged]
#759 - fix(proxy): 修复请求卡死（AgentPool 驱逐阻塞） [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[github-actions]

Thank you for reporting this issue with detailed logs and analysis.

Analysis:

Based on my investigation of the codebase, this behavior is actually by design, not a bug. The model redirection and provider selection logic work as follows:

1. Provider selection happens FIRST - in provider-selector.ts (lines 706, 853), the selector uses session.getOriginalModel() to find providers whose allowedModels list contains the requested model

2. Model redirection happens LATER - in forwarder.ts (line 1820), after a provider is selected, ModelRedirector.apply() rewrites the model name for the upstream API call

This is explicitly documented in provider-selector.ts (lines 98-112):

/**
 * 核心逻辑（统一所有供应商类型）：
 * 1. 未设置 allowedModels（null 或空数组）：接受任意模型
 * 2. 设置了 allowedModels：仅当原始请求模型命中 allowedModels 时才支持
 * 3. modelRedirects 仅在供应商已被选中后用于改写上游模型，不参与调度放行
 */

Root Cause:

Your provider's allowedModels likely contains only the redirected model (gemini-3.1-pro-preview), but the selector checks against the original model (gemini-3.1-pro-preview-customtools). Since they don't match, the provider is filtered out.

Workaround:

Add the original model name to your provider's allowedModels list:

allowedModels: ["gemini-3.1-pro-preview-customtools", ...]

Combined with your existing modelRedirects configuration:

modelRedirects: { "gemini-3.1-pro-preview-customtools": "gemini-3.1-pro-preview" }

This will:

1. Allow the provider to be selected (matches allowedModels)
2. Redirect the model for the upstream call (applies modelRedirects)

Alternatively:

If you leave allowedModels empty (null or []), the provider will accept any model, and the redirect will work as expected.

Affected code:

• src/app/v1/_lib/proxy/provider-selector.ts (lines 113-121) - providerSupportsModel() function
• src/app/v1/_lib/proxy/model-redirector.ts (lines 20-129) - ModelRedirector.apply() method

Test reference:

• tests/unit/proxy/provider-selector-model-redirect.test.ts - confirms this is intended behavior

---

Automated response from Claude AI

[chuanshuojibi]

我现在也是重定向失败，把gpt定向claude，请求会没有该模型

[ding113]

我现在也是重定向失败，把gpt定向claude，请求会没有该模型

您好，重定向功能不负责请求格式转换，只能在相同请求格式中进行重定向。