Bug: "Fetch available models" returns stale bundled catalog for built-in providers (e.g. OpenRouter) instead of querying the live endpoint

[calvinmoltbot]

Summary

On the web Models settings page, clicking "Fetch available models" on a built-in catalog provider's card (e.g. OpenRouter) never queries the provider's live /models endpoint. discoverModels() short-circuits to the bundled static catalog whenever the request names an installed pi-ai provider, so the button effectively returns a stale snapshot instead of discovering what the provider currently advertises.

For OpenRouter specifically, the bundled snapshot (@earendil-works/pi-ai's generated openrouter.json) contains 276 models, while OpenRouter's live GET https://openrouter.ai/api/v1/models currently advertises 418. Models added upstream after the snapshot was generated are impossible to discover through the UI and must be entered by hand.

Environment

• dsh 0.1.1-rc.2
• @deepseek-ai/dsh-llm-pi-ai 0.1.1-rc.2
• @earendil-works/pi-ai 0.82.1
• macOS 15 (Apple Silicon), Node 22.x

Repro steps

1. Boot the web profile; open Settings → Models.
2. Open the OpenRouter provider card with an API key configured.
3. Click Fetch available models.
4. The candidate list is limited to the bundled catalog. Models that exist upstream but not in the bundled JSON — e.g. stealth/ox-alpha, google/gemini-3.7-flash — are absent.

Expected behavior

"Fetch available models" interrogates the provider's live endpoint (<baseUrl>/models) and returns what it currently advertises, falling back to the bundled catalog only when no base URL is known (or optionally, when the live request fails).

Actual behavior

discoverModels() returns early before any network call:

async function discoverModels(request, storedApiKey) {
    if (request.provider !== void 0) {
        const installed = catalogModels(request.provider);
        if (installed.size > 0) return [...installed.values()].map((model) => ({ ... })); // ← short-circuit
    }
    if (request.baseURL === void 0 || request.baseURL.length === 0) throw new LlmError(`pi-ai ships no catalog for provider "${request.provider ?? ""}"...`);
    // ...live fetch only reachable when provider is NOT an installed catalog route
}

The UI probe for a built-in card always carries provider and no baseURL (unless the user overrides it), so every fetch resolves from the static snapshot and the network path is unreachable for exactly the providers that ship a catalog.

Suggested fix

When the named provider's installed catalog also ships a baseUrl, prefer the live listing; keep the bundled list as a fallback when there is no base URL at all:

async function discoverModels(request, storedApiKey) {
    const baseURL = request.baseURL ?? catalogProvider(request.provider ?? "")?.baseUrl;
    if (baseURL === undefined) {
        // existing bundled-catalog fallback + "no catalog / set a baseURL" error path
    }
    return fetchLiveModels(baseURL, request, storedApiKey);
}

Optionally, catch a failed live fetch and degrade to the bundled snapshot rather than erroring, so offline use still gets the stale list.

I verified locally against this build that preferring the catalog baseUrl makes the OpenRouter card return the live 418-model listing, including models missing from the snapshot. Note only the host-side change is needed: catalogProvider(...) is already in scope in dsh-llm-pi-ai, and the stored-key closure already resolves the right credential per route.

Workaround

Manually add the missing model ids on the provider card, or patch discoverModels as above in the installed dsh-llm-pi-ai package (noting a local patch is overwritten by reinstall/upgrade).