DSH 从 OpenRouter 拉取模型列表不全是什么原因？/models 分页只读了第一页吗？

models 列表是一份 advisory 的发现目录，拉取不全可能有两类原因：OpenRouter 的 /models 是分页接口而发现只读了第一页（具体缺陷），或解析过滤掉了一些（[来源](https://github.com/deepseek-ai/deepseek-harness/discussions/4685)）。这个本身需要带数字单独报 bug，但「拉不全」不等于「用不了」。

目录里没有的模型能用吗？在 providers. .models 手写 id 怎么写？

能。模型解析接受目录之外的 model id——目录里没有的模型，手写进配置照样能用：在 llm-pi-ai 的 providers. .models 下写 id/contextWindow/input/reasoningEfforts 即可。

为什么采纳的视觉模型发图被拒（MODEL_DOES_NOT_SUPPORT_IMAGES）？adopt() 丢了什么字段？

Settings 页的 adopt() 只拷 id/name/contextWindow/maxTokens 四个字段，不写 input（[#3226](https://github.com/deepseek-ai/deepseek-harness/discussions/3226)）——视觉模型被采纳后按纯文本处理，发图就被拒；同一行还丢 reasoningEfforts（[#3566](https://github.com/deepseek-ai/deepseek-harness/discussions/3566)）。

手写模型配置要注意什么？为什么路由名不叫 openrouter 会静默回落成 ['text']？

两件事：profile 段里一个非法键会让整段被拒（不是只忽略那个键），所以一次加一个字段、加完起一次；手写路由的模态继承按 provider 路由键查找，路由名不叫 openrouter（如自定义名）时即使目录知道该模型支持图片也会静默回落成 ['text']（[#1992](https://github.com/deepseek-ai/deepseek-harness/discussions/1992)）。

拉取不全本身怎么处理？怎么给 OpenRouter 模型列表缺失报 bug？

单独开一帖报 bug 并附数字（拉到几个 vs 实际有几个），先确认 OpenRouter 的 /models 是否分页——分页则是「发现只读第一页」的具体缺陷；未修前用「手写常用模型 + 补全采纳条目」过渡。

DeepSeek Harness 模型列表拉不全？手写模型配置与采纳丢字段排查

DSH 从 OpenRouter 拉取模型列表不全、最新模型缺失——先明确一个事实：models 列表只是 advisory 的发现目录，「拉不全」不等于「用不了」，目录外手写 model id 照样能用。真正的坑在「采纳」：Settings 的 adopt() 只拷 id / name / contextWindow / maxTokens 四个字段，丢 input（视觉模型发图被拒 MODEL_DOES_NOT_SUPPORT_IMAGES）和 reasoningEfforts。手写配置 + 补全采纳条目即可解决；拉取不全本身是产品缺口/疑似分页 bug，需带数字单独上报。

DSH 模型列表拉不全长什么样

症状是「可用模型」拉取不完整、最新模型缺失，且没有搜索、快速刷新、自动更新。 报告者实跑遇到（讨论原文），列举了六条：

拉取不返回全部模型；
最新模型（如 GLM 5.3 Flash）在设置里加了可用模型仍然缺失；
拉取到的模型不能搜索；
没有「快速刷新」自动补缺；
没有按作者维护的模型清单；
没有自动更新（理想是每 6 小时 + 失败指数退避）。

前两条是「拉取/解析」问题，后四条是产品缺口——但真正让你「用不了」的，往往是采纳丢字段，而不是拉取不全。

根因一：models 列表是 advisory 发现目录

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

yaml

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 段里一个非法键会让整段被拒（不是只忽略那个键）——一次加一个字段、加完起一次。

根因二：采纳（adopt）丢字段

这是比「拉不全」更隐蔽的坑：Settings 页的 adopt() 只拷 id / name / contextWindow / maxTokens 四个字段，不写 input（#3226，多人独立核证、已有补丁分支）——于是视觉模型被采纳后按纯文本处理，发图片直接被拒（MODEL_DOES_NOT_SUPPORT_IMAGES）。同一条代码还丢 reasoningEfforts（#3566）——端点声明了推理档位，采纳之后全没了。

这类失败是滞后的：不是采纳时报错，而是以后真的用到那个能力时才失败，那时你多半已经不记得是采纳这一步丢的。对 OpenRouter 用户尤其要紧——它的目录里视觉模型和推理模型混杂，正是最容易踩的组合。

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

排查步骤：手写 + 补全采纳条目

按「手写可用 → 检查采纳条目 → 核对路由名」三步排查，先别等拉取功能修复。 按步骤操作：

手写模型：把实际要用的模型写进 llm-pi-ai.providers.<name>.models（见上文示例），一次加一个字段、加完起一次；
核对路由名：路由键保持 openrouter 或用官方名，避免自定义名导致模态静默回落 ['text']（#1992）；
检查采纳条目：被采纳的视觉模型若发图被拒（MODEL_DOES_NOT_SUPPORT_IMAGES），手动补 input: [text, image]；推理模型补 reasoningEfforts（#3226 / #3566）；
确认发现实现归属：模型发现 seam 按 settings 命名空间注册，仓库里唯一注册了它的是 dsh-llm-pi-ai（#740）——确认你的 OpenRouter 路由配在 llm-pi-ai 下，否则可能根本没有 discovery 实现。

拉取不全本身：分条上报，先带数字

六条里值得单独查的是第 1 条「拉不全」——这是唯一可能有明确 bug 的。 社区建议（来源）：

单独开一帖报「拉取不完整」：附「拉到几个 vs 实际有几个」的数字，先确认 OpenRouter 的 /models 是否分页——分页则「发现只读了第一页」是具体缺陷；不分页则是解析过滤掉了一些；
第 3、4 条（搜索、快速刷新）依赖 adopt 先修好，否则是批量制造残缺条目；可提但优先级放后；
第 5、6 条（按作者维护、自动更新）是产品设计，会引出「请求谁承担」「失败怎么提示」等一串问题，建议拆开提。

注意事项

「拉不全」不是「用不了」——先手写常用模型，别卡在拉取功能上。
采纳的视觉/推理模型发图被拒或档位缺失，先查 adopt 丢字段（#3226/#3566），再查路由名（#1992）。
手写配置改一次起一次，非法键会让整段被拒，别批量改。
模型发现走 llm-pi-ai 的实现，确认路由归属再决定 bug 报给谁。

来源：Discussion #4685、#3226（adopt 丢 input）、#3566（adopt 丢 reasoningEfforts）、#1992（路由键与模态继承）、#740（discovery 归属）