dsh-model-capability-probe

自动探测模型路由支持的推理强度与上下文长度，并把结果写进 DSH 的模型配置页（Settings → Models 中的 provider 卡片）。

安装

npm 包名：dsh-model-capability-probe。

在 DSH 的 Settings → Plugins 中安装该 npm 包并启用；也可以先用 dsh plugin --profile web add dsh-model-capability-probe 安装，再到插件列表启用 bundle。

写入的 reasoningEfforts 直接复用 DSH 原版的模型选择器：composer 的模型菜单和 /model 命令会自动出现 Effort 档位，切换方式、顺序和样式与 DSH 自带模型完全一致，插件不另外实现一套切换 UI。

使用

1. 打开 Settings → Models。
2. 在已配置的 provider 卡片底部点击 自动探测。
3. 插件会：
   • 读取 provider 的 GET /models 元数据（有凭据时）；
   • 对每个模型发送少量极小请求（max_output_tokens: 16），枚举 none/minimal/low/medium/high/xhigh/max；
   • 用 models.dev 的目录校正档位、补全上下文长度；
   • 把结果写入该 provider 的 contextWindow 与 reasoningEfforts。
4. 结果会立即生效；原版模型选择器下一次打开时显示新的档位。

探测是手动的。已配置推理档位和上下文长度的模型不会重复探测，也不会下载 models.dev 目录；全部模型都已配置时，一次刷新通常约 1–2 秒（只访问 provider 的 /models）。新加入、还没有 reasoningEfforts 的模型才会发探测请求（每个模型约 8–15 秒，取决于网关延迟）。

探测/回退顺序

1. provider 自己的 GET /models（OpenAI 兼容、Anthropic 列表），读取 context_length、top_provider.context_length、limit.context 等字段。
2. Harness 的 llm.discoverModels()（适配器处理原生认证，例如 DeepSeek 账号）。
3. 主动请求探测：openai-completions 发 reasoning_effort，openai-responses 发 reasoning.effort，请求体里带的就是模型 ID。只探测还没有配置 reasoningEfforts 的模型；已配置的模型直接复用。只接受 HTTP 2xx，400/422/503 中明确“参数被拒绝”的响应视为不支持；超时、429、5xx 会重试一次，不会误删已有档位。
4. 轻量目录 https://models.dev/models.json?type=all（JSON 482 KB，压缩后约 54 KB）：按模型 ID 查上下文长度与 reasoning 布尔。它不再下载 5.8 MB 的完整 provider 目录。
5. 只有当某个未配置档位的模型探测失败/无法判定时，才回退到完整目录：
   • https://models.dev/api.json?type=all（含 reasoning_options）
   • https://models.dev/catalog.json?type=all
   • https://models.dev/models.json?type=all

档位以 模型 id 精确匹配，再按 / 后的模型名后缀匹配；上下文取候选值的众数（并列取较小值），避免个别 provider 的极端值。

off 的处理：只有探测确认 reasoning.effort: "none" 会被接受且响应里没有 reasoning 输出，或 models.dev 明确列出 none 时，才写入 off: none。这样原版的 “off” 是真正关闭推理，而不是“省略参数后仍按默认推理”。

写入规则

• llm-pi-ai 路由：写 providers.<id>.models[].contextWindow 和 models[].reasoningEfforts。
  • reasoningEfforts 的 key 是选择器档位，value 是发给网关的 wire 值；例如 { off: none, low: low, high: high, max: max }。
  • 只对用户层已经声明的 models 数组按索引写入，不会把 schema 默认值（如 compat）物化进配置。
• 没有 models 数组、但支持 modelOverrides 的路由（pi-ai 内置目录路由、DeepSeek 账号路由）：写 modelOverrides.<model>.contextWindow，不写推理档位。
• 其他 schema（例如 llm-deepseek API-key 路由）：只读不写；无法安全覆盖时返回 warning，不会破坏配置。
• 已存在的档位采用只增不减的合并策略：探测结果不会删除用户手写的档位，避免网络抖动造成配置回退。

性能

• 需要补全新模型时只下载 models.json（482 KB JSON / 约 54 KB 压缩），不再预取或下载 5.8 MB 的 api.json；全部模型已配置时连 models.json 也不下载。
• 完整 api.json 仅在“新模型探测失败”时按需加载，并缓存 30 分钟。
• 已配置 reasoningEfforts 的模型跳过主动探测，也不触发完整目录下载；这是全部模型已配置时只需 1–2 秒的原因。
• 新模型才发 7 个 16-token 的极小请求（约 8–15 秒）；单请求超时 8 秒、瞬时错误只重试一次。
• 复用 5 分钟内的探测结果；同一 provider 的并发重复点击共享同一次探测。
• 如需强制重新探测已配置模型，设置 reprobe: true。

配置

cordis.patch.yml 的 model-probe 行可覆盖：

- id: model-probe
  config:
    modelsDev: true                  # 关闭后只用 provider 元数据/主动探测
    modelFactsUrl: https://models.dev/models.json?type=all  # 轻量上下文目录
    reprobe: false                   # true = 连已配置档位的模型也重新探测
    modelsDevUrls:                   # 仅在探测失败时使用的完整目录回退链
      - https://models.dev/api.json?type=all
      - https://models.dev/catalog.json?type=all
      - https://models.dev/models.json?type=all
    probeTimeoutMs: 8000             # 单次探测请求超时
    probeConcurrency: 8              # 探测并发；网关限流时可降到 2–4
    probeCacheTtlMs: 300000          # 探测结果缓存（5 分钟）
    maxModels: 16                    # 单次最多探测的模型数
    cacheTtlMs: 1800000              # models.dev 缓存时间（30 分钟）

实现

• index.js：Host 半，注册两个 loopback-only 路由：
  • GET /api/model-probe/health
  • POST /api/model-probe/detect，body { provider, settingsNs }
• client.js：Client 半，在 settings.models.provider-card（按 settingsNs 分键）注册“自动探测”按钮，同源调用 Host 路由。
• cordis.patch.yml：插入 model-probe 行。

依赖：Host 侧只用 Node 全局 fetch 和 Cordis 服务；Client 侧只用 loader 提供的 react、ctx.remote.llm、ctx.locale、ctx.slots。

已知限制

• models.dev 的公开 API 只支持 ?type= 过滤，不支持按模型 ID 查询（API worker 只读取 type 参数）。所以无法做到“请求 URL 里带模型 ID 只取一条”；插件改为：用模型 ID 发实际模型请求做探测，上下文用 54 KB 的 models.json 按 ID 查找，完整目录只在探测失败时兜底。
• 推理档位是“网关接受 + models.dev 共识”的结果，个别网关会把未知档位静默映射到邻近档位；插件无法读取模型内部真实预算。
• 只对 openai-completions / openai-responses 做主动档位探测；Anthropic Messages 路由依赖 models.dev。
• 每次探测会产生少量计费 token（每个模型每个档位最多 16 个输出 token）。
• 浏览器端视觉呈现未做自动化截图验证；已通过 Client Slot 检查确认三个 settingsNs 的卡片注册均处于 active 状态。