Repository navigation
[Feature]: 正式建模模型发现模式 / Formalize provider model discovery modes #210
Description
[Feature]: 正式建模模型发现模式 / Formalize provider model discovery modes
Problem / pain point / 问题
当前代码已经承认 /models 不是通用前提，但模型发现仍然大多围绕“provider 应该有 listing endpoint”来组织。
实际上 provider 至少分成几类：
- 标准
/models - 静态已知模型
- 手工输入 model ID
- inference-only endpoint，没有 listing
- imported config，仅有一个已知默认模型
Without formal discovery modes, the product keeps re-learning the same provider-specific edge cases.
Proposed solution / 方案
引入 modelDiscoveryMode，例如：
modelsmanualstatic-hintinfer-only
并用它驱动：
- connection tests
- model picker UX
- import defaults
- diagnostics wording
Alternatives considered / 备选方案
- 继续让每条 provider 路径单独处理 discovery
- 逻辑会不断重复
Scope / 范围
Provider / model
Acceptance criteria / 验收标准
- provider entry 可声明 discovery mode
models:v1:list-for-provider会尊重该 mode- Settings UI 能表达 manual/static 而不是强依赖远程 discover
- diagnostics 不再把“没有
/models”视为统一失败 - built-ins 与 imports 都有合理 mode
Likely touchpoints / 可能涉及
apps/desktop/src/main/connection-ipc.ts- settings model picker UI
- importers for Codex / OpenCode / Gemini / Claude Code
Activity
Sun-sunshine06 commentedon Apr 23, 2026
Parent epic / 所属总 issue: #214
github-actions commentedon Apr 23, 2026
感谢反馈，这个缺口在当前实现里是存在的。按仓库现状，我没有找到
modelDiscoveryMode或等价字段；目前更接近“modelsHint+ 统一/models拉取 + 若干局部 fallback”的状态，而不是正式建模 discovery mode。已验证的现状：
ProviderEntry目前只有defaultModel和可选modelsHint，没有声明式 discovery mode。models:v1:list-for-provider会先返回modelsHint，否则直接请求远端/models。list-for-provider。/models不是通用前提”的情况做了局部处理：404 且 baseUrl 已带版本段时，不再统一提示“补/v1”；openai-codex-responses也被明确标记为没有可 discover 的/models，通过modelsHint走静态提示。defaultModel；仓库里只有 ChatGPT Codex 这条 provider 明确带了modelsHint。这意味着你提的方向和当前代码是一致的：现在已经有几种 discovery 行为散落在不同位置，但还没有被抽成统一的 provider capability / mode。
Relevant code:
packages/shared/src/config.ts:130—ProviderEntry目前有defaultModel/modelsHint，未定义 discovery modeapps/desktop/src/main/connection-ipc.ts:727—models:v1:list-for-provider先返回modelsHint，否则请求远端/modelsapps/desktop/src/renderer/src/components/AddCustomProviderModal.tsx:125— 自定义 provider 的自动发现 + 手动 model fallbackapps/desktop/src/renderer/src/components/Settings.tsx:439— Settings provider row 挂载时直接拉list-for-providerpackages/shared/src/diagnostics.ts:83— 404 且 baseUrl 已带版本段时，不再统一归因为缺少/v1packages/shared/src/base-url.ts:107—openai-codex-responses明确没有可 discover 的/models，要求走modelsHintapps/desktop/src/main/codex-oauth-ipc.ts:41— ChatGPT Codex provider 当前用静态modelsHintapps/desktop/src/main/imports/claude-code-config.ts:204— Claude Code import 只落defaultModelapps/desktop/src/main/imports/gemini-cli-config.ts:259— Gemini import 只落defaultModelapps/desktop/src/main/imports/opencode-config.ts:324— OpenCode import 只落defaultModel补充一下项目阶段：README 里当前还是
v0.1.3，并且把 provider/API config、model picker、diagnostics 列为正在打磨的项，所以这类 provider capability 抽象还在较早期的演进阶段（README.md:248）。open-codesign Bot
Sun-sunshine06 commentedon Apr 23, 2026
补一个来自 #214 讨论的提醒：模型发现这条线不只是 mode 建模问题，也直接影响 Settings / provider 管理的交互形态。
有个外部建议我觉得对这里很有指导意义：
最后一点尤其重要：即便拿到了 provider 列表或
/models，auth shape、wire 支持、runtime compatibility 仍然可能不同，所以 UI 不应该把“能列出来模型”误当成“这条 provider 路径就一定能稳定运行”。feat(shared,desktop): add provider capability profiles (#215)
github-actions commentedon May 1, 2026
感谢补充。这个 issue 和之前 bot 的分析方向是一致的 — 当前
ProviderEntry还没有声明式 discovery mode，但行为上已经散落在modelsHint、远端/models、手写 fallback 等处。你提到的“connection settings 和 model 选择保持靠近”很重要，当前 Settings provider 行在挂载时直接拉list-for-provider（Settings.tsx:439）就有这个问题。epic #214 应该能统筹这些。Open-CoDesign Bot
feat(providers): formalize model discovery modes
feat(providers): formalize model discovery modes (#422)
fix(diagnostics): plumb connection-test attemptedUrl (#422 follow-up) (…