模型明明能用，菜单里却没有：Hermes Copilot /model 选择器为什么藏起新模型

有一种模型接入问题很容易被误判：你以为模型不可用，其实只是选择器没把它列出来。

NousResearch/hermes-agent issue #16708 讲的就是这个问题。

用户通过 Hermes 官方支持的 Copilot device-code flow 登录，auth.json 里已经有 OAuth access_token。实际调用模型也能工作。

但 /model 选择器在选择 copilot provider 时，只显示一小段 hardcoded fallback list，不显示当前账号可用的新模型，比如：

claude-opus-4.7
claude-sonnet-4.6
gpt-5.5
grok-code-fast-1

结果用户会误以为这些模型不存在。

但真相是：

模型能点菜，菜单却没更新。

现象：直接输入模型 ID 能用，/model 菜单却看不到

issue 的复现路径很典型。

1. 新安装 Hermes

没有配置 gh CLI，也没有设置：

COPILOT_GITHUB_TOKEN
GH_TOKEN
GITHUB_TOKEN

2. 使用 Hermes 自己的登录流程

运行：

hermes auth add copilot

通过 device-code flow 登录后，auth.json 里会出现类似：

credential_pool.copilot[0].access_token

这个 token 通常是 OAuth token，例如 gho_...。

3. 打开 `/model` 选择器

在 Hermes 里输入：

/model

选择 copilot provider。

4. 结果只看到 fallback list

选择器没有显示当前 Copilot catalog 里的新模型。

但如果用户直接输入：

/model claude-opus-4.7

模型是可以工作的。

这就说明：

不是模型不能用，而是 picker 获取 catalog 的认证路径错了。

根因：Copilot catalog resolver 只看 env，不看 auth.json

issue 指向的核心函数是：

hermes_cli/models.py::_resolve_copilot_catalog_api_key()

它在获取 Copilot model catalog 时，只检查这些环境变量：

COPILOT_GITHUB_TOKEN
GH_TOKEN
GITHUB_TOKEN

但它没有 fallback 到 auth.json 里 Hermes 自己 device-code flow 生成的 OAuth access_token。

这就造成了很奇怪的割裂：

Hermes 登录流程拿到的 token，可以用于实际 Copilot 调用；
但 /model catalog fetch 却不用这个 token。

于是 live model fetch 失败。

失败后，选择器退回到 hermes_cli/models.py 里硬编码的小列表。

用户看到的就不是完整菜单，而是 fallback 菜单。

为什么这比“列表不全”更严重？

表面上看，这只是 /model 菜单少了几个选项。

但对用户来说，它会影响判断：

用户不知道账号已经能用新模型；
以为 Copilot provider 不支持某些模型；
以为需要换 provider；
以为企业账号或 preview 模型没开；
以为 Hermes 与 Copilot 兼容不完整。

更关键的是，很多用户不会手动输入完整模型 ID。

他们信任 /model 菜单。

如果菜单没列出来，模型对用户来说就等于不存在。

Codex resolver 已经有正确模式

issue 里提到一个很重要的对照：Codex catalog resolver 已经有正确模式。

它会：

1. 先查 env var； 2. 再调用 runtime credential resolver； 3. 从 auth.json 中读取 credential。

也就是说，Hermes 并不是不知道怎么做 fallback。

Copilot catalog resolver 只是没有复用同样模式。

所以修复方向非常明确：

Copilot catalog resolver 应该 mirror Codex pattern。

修复方向：env 优先，auth.json 兜底

issue 给出的修复思路很小：

当前行为

只查 env vars：
COPILOT_GITHUB_TOKEN / GH_TOKEN / GITHUB_TOKEN

应该变成

1. 先查 env vars；
2. 如果没有，读取 auth.json；
3. 遍历 credential_pool.copilot[]；
4. 返回第一个 access_token。

这保持了向后兼容：

如果用户显式设置 env var，仍然优先使用；
如果用户使用 Hermes 官方登录流程，也能正常拉取 catalog；
不需要新依赖；
不改变实际模型调用路径，只补齐 catalog fetch。

临时 workaround：直接输入模型 ID

issue 给出的临时解决办法是手动输入模型 ID：

/model claude-opus-4.7
/model gpt-5.5

如果模型本身对账号可用，直接输入可以绕过 picker 的 catalog 展示问题。

但这不是理想体验。

因为用户必须提前知道模型 ID。

而 /model 选择器本来就是为了让用户不需要记住完整 ID。

如何判断你是否踩到这个坑？

如果你符合下面条件，就很像 #16708：

使用 hermes auth add copilot 登录；
没有设置 COPILOT_GITHUB_TOKEN / GH_TOKEN / GITHUB_TOKEN；
auth.json 里有 credential_pool.copilot[0].access_token；
/model 选择 copilot 只显示少量 fallback 模型；
但手动输入新模型 ID 可以用。

排查顺序：

1. 看是否设置了 env token

env | grep -E 'COPILOT_GITHUB_TOKEN|GH_TOKEN|GITHUB_TOKEN'

2. 确认 auth.json 有 Copilot token

不要公开粘贴 token，只确认结构中有：

credential_pool.copilot[].access_token

3. 测试手动模型 ID

/model claude-opus-4.7

如果能用，说明问题更可能在 picker catalog fetch，而不是模型调用本身。

和 DeepAI API 中转站的关系

这个 issue 是 Copilot provider 的 catalog/auth fallback 问题，不是 DeepAI API 中转站问题。

DeepAI API 中转站适合在支持 OpenAI-compatible API 的客户端或工具中统一配置：

base URL；
API key；
model name；
OpenAI-compatible 请求格式。

但 GitHub Copilot provider 的 /model picker 是否能从 auth.json 读取 OAuth access_token，属于 Hermes Copilot provider 的内部逻辑。

因此不能说“换 DeepAI 就能修 Copilot 菜单”。

更准确的说法是：

DeepAI 解决 OpenAI-compatible 模型接入；Copilot catalog 展示由 Hermes Copilot provider 自己负责。

如果你的工具支持 OpenAI-compatible API，可以用 DeepAI 做统一模型入口；但如果你选择的是 Hermes 内置 Copilot provider，就要按 Copilot provider 的认证和 catalog 逻辑排查。

FAQ

为什么 `/model` 菜单里没有 `claude-opus-4.7`，但直接输入能用？

因为 picker 拉取 live catalog 时没有使用 auth.json 里的 Copilot OAuth access_token，fetch 失败后退回到硬编码 fallback list。

这是模型不可用吗？

不一定。如果 /model claude-opus-4.7 能成功，说明模型对账号可用，只是菜单没显示。

为什么 Hermes 自己登录生成的 token 没被 picker 用上？

旧逻辑中 _resolve_copilot_catalog_api_key() 只查 COPILOT_GITHUB_TOKEN / GH_TOKEN / GITHUB_TOKEN，没有 fallback 到 auth.json。

临时解决办法是什么？

直接输入模型 ID，例如：

/model claude-opus-4.7
/model gpt-5.5

DeepAI 能解决这个 Copilot picker 问题吗？

不能。这是 Hermes Copilot provider 的 catalog credential fallback 问题，不是 DeepAI 或 OpenAI-compatible API 问题。

总结

#16708 的核心教训是：

认证能用于调用，不代表也被用于 catalog。

Hermes 的 Copilot provider 里，实际模型调用可以使用 device-code flow 写入 auth.json 的 OAuth token，但 /model 选择器拉取 catalog 时只查环境变量，导致新模型被菜单隐藏。

对 Agent 产品来说，模型选择器不是装饰功能。它决定用户认为“有哪些模型可用”。

如果 catalog resolver 不走和 runtime 一致的 credential chain，用户看到的模型世界就会比真实世界小一圈。