Fetching Models from OpenRouter Doesn't Work

[elibroftw]

The fetch available model feature has serious issues:

1. It doesn't return all models
2. Latest models like GLM 5.3 Flash are missing even after adding available models in settings. Allow parsing models would alleviate this issue for me.
3. It doesn't allow searching the fetched models
4. There is no quick "refresh models" which should add missing models automatically.
5. There's no list of model-authors to always keep up to date.
6. There's probably no auto-update feature. Ideally the model catalogue is updated every 6 hours with exponential backoff (1 minute, 5 minutes, 30 minutes, 1 hour) on failures.

[weijiafu14]

你这六条里，第 2 条今天就有解（而且解法说明你其实不必等前面那条修好），其余几条是真实的产品缺口。逐条说，并附一个你现在最该知道的坑。

第 2 条"不能添加一个已知存在的模型"——可以，手写就行

拉取列表（discovery）和能不能用某个模型是两回事。models 那个列表是一份advisory 的发现目录，而模型解析接受目录之外的 model id——也就是说，目录里没有的模型，你手写进配置照样能用：

llm-pi-ai:
  providers:
    openrouter:
      api: openai-completions
      baseURL: https://openrouter.ai/api/v1
      apiKeyEnv: OPENROUTER_API_KEY
      models:
        - id: <你要的那个 openrouter model id>
          contextWindow: 131072
          input: [text, image]        # 视觉模型才写
          reasoningEfforts:           # 推理模型才写
            off:
            low: low
            high: high

所以"拉不全"不等于"用不了"——OpenRouter 有几百个模型，把你实际会用的那几个写死，比反复去拉一个大列表更省事，也更稳定。

（一个坑：这个 profile 段里一个非法键会让整段被拒，不是只忽略那个键。所以一次加一个字段、加完起一次。）

一个你现在最该知道的坑："采纳"进来的条目是缺字段的

这条直接影响你的第 4 条（"自动补齐缺失模型"）和第 6 条（"自动更新目录"）——在下面这两个 bug 修好之前，批量采纳会一次性给你几十个残缺条目：

• #3226：Settings 页的 adopt() 只拷 id / name / contextWindow / maxTokens 四个字段，不写 input——于是一个视觉模型被采纳后按纯文本处理，发图片直接被拒（MODEL_DOES_NOT_SUPPORT_IMAGES）。多人独立核证过，已有补丁分支；
• #3566：同一行还在丢 reasoningEfforts——端点在 /v1/models 里声明了推理档位，采纳之后全没了。

而且这类失败是滞后的：不是采纳时报错，是以后真的用到那个能力时才失败，那时你多半已经不记得是采纳这一步丢的。

这一条对 OpenRouter 用户尤其要紧，因为它的目录里视觉模型和推理模型混杂，正是最容易踩的组合。

（还有一条相关的：#1992 指出，手写路由的模态继承是按 provider 路由键查找的——如果你的路由名不叫 openrouter（比如你起了个自定义名字），即使目录里知道那个 model id 支持图片，也会静默回落成 ['text']。所以路由名叫什么会影响能力继承，这一点很反直觉。）

你的 1 / 3 / 4 / 5 / 6 是真实缺口，但建议拆开提

这五条的性质和代价差很多，捆在一起容易一起卡住：

你的条目	性质	我的看法
1. 拉不全	可能是 bug	值得单独查——OpenRouter 的 /models 是分页的吗？如果是，那这是"发现只读了第一页"，一个具体的缺陷；如果不是，那是解析过滤掉了一些。这条最该先弄清楚，因为它是唯一可能有明确 bug 的
3. 不能搜索	纯 UI	小、无争议
4. 快速刷新 + 自动补齐	UI + 上面那个 adopt bug	依赖 adopt 先修好，否则是批量制造残缺条目
5. 按作者维护列表	产品设计	这是 OpenRouter 特有的组织方式，通用性存疑
6. 每 6 小时自动更新 + 指数退避	产品设计	会引出"谁来承担这些请求""失败了怎么提示"等一串问题

建议至少把第 1 条单独开一帖（"OpenRouter 的 /models 拉取不完整"，附你拉到几个 vs 实际有几个的数字）。带具体数字的缺陷报告比一张六条的愿望清单容易推动得多——而你现在这六条里，第 1 条是唯一能靠数据说话的。

一个关于 discovery 归属的背景

顺带说一个可能省你时间的事实：模型发现这个 seam 是按 settings 命名空间注册的，而仓库里唯一注册了它的是 dsh-llm-pi-ai（见 #740 里 @udsy19 的核实）。

所以：只要你的 OpenRouter 路由是配在 llm-pi-ai 下的，discovery 就是走的那条实现；如果你是通过别的适配器接的，那可能根本没有 discovery 实现，"拉取"会以另一种方式失败。这个区分值得你在原帖里注明——你现在没说路由是怎么配的，而这决定了你的第 1 条该报给谁。

边界与利益相关

我们不修 DSH 自家组件——模型发现、Settings 的 Models 页、adopt 路径都在 DSH 里。第一节那段 YAML 是纯 DSH 官方配置；#3226 / #3566 / #1992 / #740 都是别人的报告，我没有复现过，也没有用过 OpenRouter 的拉取功能——第 1 条的两种可能都是猜测，需要你补数据。

利益相关：我维护 pi2dsh（Pi 生态兼容层）。这条不推销——上面全是 DSH 官方配置和别人的报告，不需要装任何东西。

[elibroftw]

I translated this and you literally gave me garbage advice regarding #2. For model parsing, I'd still have to tell DSH to implement it in the WEBUI itself. That's still a gap. Please stop replying with such long messages, or get blocked. Hopefully you get banned for spam/unproductive discourse.