Custom provider model discovery ignores reasoningEfforts from GET /v1/models

[huddhudd]

Summary

When configuring a custom OpenAI-compatible provider under Settings → Models, GET /v1/models may return per-model reasoningEfforts, but the harness discards that field. Adopted models therefore have no selectable thinking levels in the composer model picker.

Repro

1. Open Settings → Models.
2. Add a custom provider (OpenAI-compatible gateway) with a working baseURL + API key.
3. Click Fetch models.
4. Observe that the endpoint returns entries like:

{
  "id": "Fast",
  "name": "Fast：快速回复 · Grok 4.5",
  "contextWindow": 500000,
  "maxTokens": 131072,
  "reasoning": true,
  "reasoningEfforts": {
    "low": "low",
    "medium": "medium",
    "high": "high"
  }
}

5. Adopt the model into the provider profile and save.
6. Open the composer model picker for that model.

Expected

• Discovery/adoption preserves reasoningEfforts into the profile entry (llm-pi-ai.providers.<route>.models[i].reasoningEfforts).
• The model picker exposes the announced thinking levels (low / medium / high, etc.).

Actual

• No thinking-level control is offered for the adopted model.

Why

Two layers currently drop the field:

1. Host discovery normalization (dsh-llm discoverModels) rebuilds each discovered model as only { id, name?, contextWindow?, maxTokens? }, so extra fields from the endpoint never leave the service boundary.
2. Settings UI adoption (dsh-client-ui-settings-models adopt(candidate)) likewise copies only those four fields into the drafted profile row.

Separately, putting reasoningEfforts at the provider level in settings.yaml does not help: the pi-ai profile schema only recognizes per-model reasoningEfforts. A provider-level key is ignored during resolution, so the adapter still treats hand-declared models as non-reasoning.

Relevant references:

• LlmDiscoveredModel has no reasoningEfforts field
• pi-ai resolveModelReasoning(...) only reads entry.reasoningEfforts on each model entry
• Discovery listing parse currently ignores endpoint reasoningEfforts

Suggested fix

1. Extend LlmDiscoveredModel (and the wire DiscoveredModelView) to optionally carry reasoningEfforts.
2. Preserve it through llm.discoverModels instead of stripping unknown fields.
3. In the Models settings UI adopt() path, copy reasoningEfforts into the drafted model entry when present.
4. Optionally document that provider-level reasoningEfforts is not a supported profile field; per-model entries are required.

Workaround

Manually write per-model reasoningEfforts into settings.yaml, for example:

llm-pi-ai:
  providers:
    my-gateway:
      models:
        - id: Fast
          reasoningEfforts:
            low: low
            medium: medium
            high: high

Or use a temporary dynamic plugin that writes the same per-model fields via settings.mutate.

Environment

• Custom OpenAI-compatible provider (openai-completions)
• Endpoint announces reasoningEfforts on GET /v1/models
• Observed on Windows with current DSH web Models settings flow

[weijiafu14]

你把两层丢弃都定位到了，这个诊断我认。补一条你可能没试过的当下就能用的路：reasoningEfforts 是 llm-pi-ai profile 的官方字段，手写进 settings 是生效的——被丢掉的只是"自动发现 → 自动填"这一环，不是这个能力本身。

手写的形状

llm-pi-ai:
  providers:
    my-gateway:
      displayName: My Gateway
      api: openai-completions
      baseURL: https://your-endpoint/v1
      apiKeyEnv: MY_GATEWAY_KEY
      models:
        - id: your-model-id
          contextWindow: 131072
          reasoningEfforts:
            off:
            low: low
            high: high

冒号左边是 DSH 的档位名，右边是发到 wire 上的值（off 留空表示不发推理参数）。所以如果你的端点返回的是 {low, medium, high}，就照抄成三行映射即可。

这段形状我们在 examples/custom-gateways 里在真 DSH loop 上端到端跑过并进了发版回归——推理档位真上线，不是"schema 长这样"的推断。同一份 example 也顺带验了 input: [text, image] 和 compat 那几个字段。

一个观察：这是同一个模式的第三次出现

reasoningEfforts 在配置层是一等公民，在自动发现层被抹掉。这个形状我在社区里见过好几遍了——字段在 settings schema 里明明支持，但凡是"UI 帮你填"的那条路都只搬运最小四件套（id / name / contextWindow / maxTokens）。你把 adopt(candidate) 那一层指出来，正好是这类问题的公共病灶：归一化函数用了白名单，而白名单没有跟着 schema 一起长。

所以这条诉求写成"给 adopt 补字段"可能不如写成"发现层的归一化白名单应该与 profile schema 同源"——后者一次修完，下次 schema 加字段也不会再掉队。

边界

• 手写只解决你自己的端点。你要的"端点声明什么、DSH 就采纳什么"，需要改 dsh-llm 的 discoverModels 和 Settings 页，那是 DSH 自家的件，我们不修。
• 手写的代价是端点加了新模型你得手动跟——如果你的目录是动态变化的，这条路会很烦。

利益相关：我维护 pi2dsh。上面这段 YAML 是纯 DSH 官方配置，不需要装我们任何东西。只有在你的目录动态到手写跟不上、需要一个包实时拉 /models 并带着 modalities/推理档位注册路由时，才轮得到我们那条路——但那是另一个问题了，你这条按上面手写就能过。