Model list served/fetched by the harness is stale and incomplete — never refreshed from provider endpoints

[JIUSAN3]

Model list is stale/incomplete: the harness never refreshes provider model listings from the endpoints. In DSH 0.1.1-rc.2, the model selector only serves models hand-written in settings.yaml — a configured models list fully replaces the route catalog (resolveRouteModels in dsh-llm-pi-ai) — and the "fetch available models" action short-circuits to pi-ai's static built-in catalog for catalog-known providers instead of interrogating GET {baseURL}/models (discoverModels), while the official DeepSeek route ships a hardcoded 3-model catalog with no registerModelDiscovery at all. Live probe: opencode-go endpoint serves 33 models but the harness shows 3; zai-coding-cn serves 10 but shows 7; even the fetch action returns 16 entries, missing 17 models the endpoint actually serves. Please make discovery always query the live endpoint (falling back to the catalog on failure, merging catalog capacities onto endpoint ids) and register discovery for llm-deepseek.

[Mide69]

Checked your three claims against current source, all three are accurate, and this reads as deliberate design rather than an oversight, the comments spell out why.

resolveRouteModels (packages/llm/llm-pi-ai/src/catalog.ts:797) really does fully replace the catalog when models is configured. The doc comment says it outright: "A route with no configured models serves the installed catalog unchanged." And later in the same function, an error message for a conflicting modelOverrides entry literally says "models already replaces the served catalog."

discoverModels (packages/llm/llm-pi-ai/src/discovery.ts:195) really does short-circuit to the static catalog for a known provider, before ever reaching the live fetch(url) call. The comment right above it explains the reasoning: "A catalog route already has its answer, and a better one: the installed entries carry context windows and output caps no listing endpoint reports." So it is not skipping the network call by accident, it is preferring richer static metadata over a thinner live listing on purpose.

llm-deepseek (packages/llm/llm-deepseek/src/index.ts:91-111) ships exactly 3 hardcoded DEFAULT_MODELS (deepseek-v4-flash, deepseek-v4-pro, deepseek-v4-flash-vision-exp) and there is no registerModelDiscovery call anywhere in that file, confirmed by grep. So the DeepSeek route genuinely has no discovery path at all right now, live or catalog-merged.

Your ask (always query live, fall back to catalog, merge capacities onto endpoint ids) is a reasonable design direction, but it runs directly against the tradeoff the pi-ai comment explains: live listings are missing fields the static catalog has, so a naive live-first approach would lose data on every catalog-known provider unless it also does the merge you're describing. That merge doesn't exist today. Worth being explicit about that tradeoff if you take this to a feature request, since "just call the live endpoint" alone would be a regression for the exact metadata the current code protects.