固定请求一个逻辑模型名时，AxonHub 会不会 fallback 到别的上游模型

Question（问题）

如果客户端始终请求同一个逻辑模型名，比如 gemini-3-flash-preview，而不同渠道后面实际挂的是不同上游模型，AxonHub 会不会按优先级 fallback？

Short Answer（简答）

会。
前提是 API key 白名单允许这个“逻辑模型名”，而模型 association 里确实挂了多个候选。

Facts（事实）

• 当前翻译 key 的 profile 里，modelIDs 只允许 gemini-3-flash-preview。
• 当前模型 gemini-3-flash-preview 的 association 至少挂了三条候选：
  • priority 0：渠道 2，实际模型 gemini-3-flash-preview
  • priority 1：渠道 3，实际模型 gemini-3-flash-preview-thinking
  • priority 2：渠道 4，实际模型 gemini-3-flash-preview
• model_access.go 检查的是请求模型名是否在 modelIDs 里。
• select_candidates.go 最后是按候选和 priority 选渠道，不是按 API key 白名单里的实际上游模型名选。

Interpretation（解释）

这意味着：
只要客户端请求的是被允许的逻辑模型名，后端就可以继续按模型 association 的 priority 去选实际上游。

所以“白名单只写逻辑模型名”和“后端可以 fallback 到 thinking 候选”这两件事并不冲突。

Related Pages（相关页面）

• AxonHub 的 API key profile 到底在管什么
• 同一把 AxonHub API key 能不能跨协议使用
• AxonHub

Open Questions（待解问题）

• 后续是否要把 thinking 候选留在翻译链路里，还是彻底剔除？
• 如果未来有更多 provider，逻辑模型名和实际上游模型名之间是否需要更明确的命名规范？

Next Checks（后续核查）

• 在真实请求日志里继续观察 fallback 命中情况。
• 如果翻译场景明确不想走 thinking，就从候选链里删掉对应渠道或降低可用范围。