Fix DeepSeek Harness model list incomplete & adopt missing fields

DeepSeek Harness fetching an incomplete model list from OpenRouter and missing the latest models — one fact first: the models list is only an advisory discovery catalog, so "incomplete" is not "unusable"; model ids outside the catalog work fine when hand-written. The real trap is adoption: Settings' adopt() copies only id / name / contextWindow / maxTokens, dropping input (vision models rejected with MODEL_DOES_NOT_SUPPORT_IMAGES) and reasoningEfforts. Hand-write the config and patch adopted entries to fix it; the incomplete fetch itself is a product gap / suspected pagination bug and needs a numbers-backed report of its own.

What the incomplete model list looks like

The symptom: the "available models" fetch is incomplete, the latest models are missing, and there is no search, quick refresh, or auto-update. A reporter hit it in practice (discussion thread) with six items:

1. The fetch does not return all models;
2. The latest models (such as GLM 5.3 Flash) stay missing even after adding available models in settings;
3. The fetched models cannot be searched;
4. There is no quick "refresh models" to add missing ones automatically;
5. There is no per-author model list to keep up to date;
6. There is probably no auto-update (ideally every 6 hours with exponential backoff on failures).

The first two are fetch/parse problems, the last four are product gaps — but what actually makes a model unusable is usually the adopted entries losing fields, not the incomplete fetch.

Root cause 1: the models list is an advisory discovery catalog

Fetching a list (discovery) and "can I use a model" are two different things: the models list is an advisory discovery catalog, and model resolution accepts model ids outside the catalog — a model missing from the list works fine when hand-written into the config (source). Example:

llm-pi-ai:
  providers:
    openrouter:
      api: openai-completions
      baseURL: https://openrouter.ai/api/v1
      apiKeyEnv: OPENROUTER_API_KEY
      models:
        - id: <the openrouter model id you want>
          contextWindow: 131072
          input: [text, image]        # vision models only
          reasoningEfforts:           # reasoning models only
            off:
            low: low
            high: high

OpenRouter has hundreds of models; hardcoding the few you actually use is more reliable and more stable than repeatedly fetching a big list. One pitfall: a single invalid key in this profile section rejects the whole section (not just that key) — add one field at a time and start up after each.

Root cause 2: adoption drops fields

This is the sneakier trap than "incomplete fetch": Settings' adopt() copies only id / name / contextWindow / maxTokens and does not write input (#3226, independently verified by multiple people, patch branch exists) — an adopted vision model is treated as text-only and image sends are rejected (MODEL_DOES_NOT_SUPPORT_IMAGES). The same line also drops reasoningEfforts (#3566) — the endpoint declares reasoning tiers and they are all gone after adoption.

These failures are lagging: not an error at adoption time, but a failure later when the capability is actually used — by then you have usually forgotten that adoption was the step that dropped it. This matters especially for OpenRouter users: its catalog mixes vision and reasoning models, exactly the combination easiest to trip.

One related note: #1992 points out that hand-written route modality inheritance is looked up by provider route key — if your route name is not openrouter (say a custom name), even when the catalog knows the model id supports images, it silently falls back to ['text']. The route name affects capability inheritance.

Troubleshooting: hand-write + patch adopted entries

Work through "hand-write works → check adopted entries → check the route name" and do not wait for the fetch feature to be fixed. Step by step:

1. Hand-write the model: add the models you actually use under llm-pi-ai.providers.<name>.models (see the example above), one field at a time, starting up after each;
2. Check the route name: keep the route key openrouter or use the official name, to avoid a custom name silently falling back to ['text'] (#1992);
3. Inspect adopted entries: if an adopted vision model is rejected on image sends (MODEL_DOES_NOT_SUPPORT_IMAGES), manually add input: [text, image]; for reasoning models add reasoningEfforts (#3226 / #3566);
4. Confirm the discovery owner: the model discovery seam is registered by settings namespace, and the only registration in the repo is dsh-llm-pi-ai (#740) — make sure your OpenRouter route sits under llm-pi-ai; otherwise there may be no discovery implementation at all.

The incomplete fetch itself: report separately, lead with numbers

Of the six items, item 1 "incomplete fetch" is the one worth investigating separately — the only one with a possibly clear bug. The community's advice (source):

1. Open a separate post for "incomplete fetch" with numbers (how many fetched vs how many actually exist), and first confirm whether OpenRouter's /models is paginated — if it is, "discovery only read the first page" is a concrete defect; if not, parsing filtered some out;
2. Items 3 and 4 (search, quick refresh) depend on adopt being fixed first — otherwise they mass-produce broken entries; raise them but deprioritize;
3. Items 5 and 6 (per-author list, auto-update) are product design and raise questions like "who bears the requests" and "how failures surface" — suggest filing them separately.

Notes

1. "Incomplete" is not "unusable" — hand-write the common models first and do not stall on the fetch feature.
2. If an adopted vision/reasoning model is rejected on images or misses tiers, check the adopt field loss (#3226/#3566) first, then the route name (#1992).
3. Change hand-written config one start-up at a time — an invalid key rejects the whole section, so do not batch edits.
4. Model discovery runs through the llm-pi-ai implementation; confirm route ownership before deciding who to report the bug to.

Sources: Discussion #4685, #3226 (adopt drops input), #3566 (adopt drops reasoningEfforts), #1992 (route key and modality inheritance), #740 (discovery ownership)