Settings UI "Models" page only lists adapter-registered configurable providers, hiding llm-pi-ai profile routes

[shao-zhijie]

Summary

When ~/.dsh/settings.yaml declares providers via two different mechanisms
(top-level llm-deepseek adapter vs llm-pi-ai.providers.* profile routes),
the Settings → Models page only surfaces the first one. The chat input
dropdown, however, shows both providers — leaving the user thinking one of
them "doesn't exist" until they expand the dropdown and discover it works.

This is a UX inconsistency: the same model is selectable in chat but absent
from the page that exists to manage credentials and base URLs for it.

Reproduction

1. Fresh ~/.dsh/settings.yaml with two providers:

   llm-deepseek:
     baseURL: https://api.deepseek.com/v1
     apiKeyEnv: DEEPSEEK_API_KEY
     models:
       - id: deepseek-chat
       - id: deepseek-reasoner
   
   llm-pi-ai:
     providers:
       MiniMax:
         api: openai-completions
         baseURL: https://api.minimaxi.com/v1
         apiKeyEnv: MINIMAX_API_KEY
         models:
           - id: MiniMax-M3

2. Open DSH Desktop → Settings → Models.

3. Observe: only the DeepSeek card is shown. The MiniMax provider is
   absent from this page, with no place to view or edit its baseURL / API key.

4. Open any chat → model dropdown.

5. Observe: BOTH DeepSeek and MiniMax sections appear; all 3
   models are selectable and the API actually works.

Expected

Settings → Models should show both providers as cards, with edit affordance
for API key and baseURL on each — mirroring the chat dropdown. The user
should not have to expand a chat input to discover a provider that is already
configured in their settings.yaml.

Root cause (observed in source)

packages/llm/llm-deepseek/src/index.ts calls
ctx.llm.registerConfigurableProviders() with one hardcoded entry:

const PROVIDER = 'deepseek-official'
ctx.llm.registerConfigurableProviders([
  { provider: PROVIDER, displayName: 'DeepSeek', ... },
])

packages/llm/llm-pi-ai/src/index.ts builds its list from catalogProviderIds()
(a closed set in catalog.ts: openai / deepseek / openrouter / together / baseten / zai / qwen / chat-template / ...) plus profile-declared routes. A
user-declared route like MiniMax in llm-pi-ai.providers.MiniMax: becomes a
profile entry, but the Settings UI only iterates the top-level adapter
registration, not the union of adapter-registered + profile-declared routes.

In other words: Settings → Models reads from registerConfigurableProviders()
results; the chat dropdown reads from ctx.llm.listProviders() which DOES
include profile routes. The two views diverge.

Suggested fix

Settings → Models should aggregate from ctx.llm.listProviders() AND the
profile-declared entries from llm-pi-ai's directoryEntries(), not just
registerConfigurableProviders() results from top-level adapters.

This way, every provider that is actually wired to a model — whether it came
from a built-in adapter or from llm-pi-ai.providers.<name> in the user's
profile — gets a card in the Models page.

A less invasive fix would be: only render the llm-pi-ai profile-declared
entries that have at least one model listed, so a partially-typed user route
does not show up.

Environment

• DSH Desktop v2.0.5 (Electron)
• macOS 26.6.2 (arm64)
• DSH source: packages/llm/llm/src/index.ts (listProviders()), plus
  per-adapter registerConfigurableProviders() calls.
• Workaround in the meantime: open a chat and use the dropdown. The
  dropdown already shows all providers correctly.

[argszero]

Source-checked on master d347e70390 — the Models page should surface pi-ai-declared providers in the current wiring, so your screenshot points at one of two concrete failure branches rather than a missing feature. Details:

The code chain (verified):

• The page store joins llm/listProviders + llm/listConfigurableProviders with the settings mirror's namespaces (ui-settings-models/src/client/store.ts:2-3, load() ~:170-190).
• Rows render as cards only when configured — the row's settingsNs namespace resolves in the mirror AND getPath(namespace.value, settingsPath) is defined (store.ts:197-208); everything else is dormant, reachable only via the page's "+ Add provider" flow (ModelsSection.tsx:291-293: configured vs addable).
• llm-pi-ai registers every catalog route and every declared profile into that configurable directory — settingsNs: 'llm-pi-ai', settingsPath: ['providers', <name>] (llm-pi-ai/src/index.ts directoryEntries :110-140; shipped since d6126c25f2, Aug 5 — already in your 0.1.2-alpha.2).

So a MiniMax profile declared under llm-pi-ai.providers in settings.yaml should become a configured card on master's wiring. The asymmetry you see is by construction in one direction only: the chat dropdown lists live routes (the LLM model registry), which never consults the configurable directory — but the Models page listing does include declared pi-ai providers, so the directory side is not the gap.

Two discriminating branches — which one matches?

1. MiniMax appears under "+ Add provider" (dormant) but never as a card → the directory row exists but configured === false → the resolved namespace value no longer contains providers.MiniMax, even though your settings.yaml declares it. That is the documented silent section-revert family: a settings.yaml shape that fails llm-pi-ai section validation collapses the whole namespace (custom providers go collectively invisible on exactly this page) — see [UX/FR] settings.yaml 校验失败时前端静默丢弃提供商且无任何提示 #5820/[bug] llm-deepseek Config namespace silently reverts to DEFAULT_MODELS (and every other field default) when one required sibling field (thinking/reasoningEffort) is missing #5761 (frontend reports the same symptom; the fix direction is visible per-field parse errors instead of whole-section skip). Tell me: is MiniMax selectable in the add flow? Any error banner? What does your llm-pi-ai section look like in the settings editor (does it render at all)?
2. MiniMax is absent even from the add flow → the directory or the mirror never carried it. Which dsh-web-app build is this (0.1.2-alpha.2?), and does the Settings page have an llm-pi-ai section entry at all? If the llm-pi-ai namespace isn't mirrored to the web settings surface, that's a wiring bug worth its own thread.

If you can confirm branch 1 with the add-flow observation + whether the llm-pi-ai section renders, I can map it precisely onto the revert family and give you a today-workaround (validate the MiniMax entry against the pi-ai provider schema — api enum, models[] shape — or temporarily move it to an adapter-registered provider).