[Bug] Adding a model through the catalog picker drops hand-declared fields (reasoningEfforts gone, no effort levels for custom providers)

[GnaneshKunal]

Environment: dsh 0.2.1-rc.3, macOS 15.7 (Apple Silicon). Affected package: @deepseek-ai/dsh-client-ui-settings-models@0.2.1-rc.3.

What happens

Adding a model to a provider route through the catalog picker in Settings → Models creates that row with only the fields the catalog knows about. Anything the operator had declared on that model — reasoningEfforts in particular — is not part of the new row, and nothing reports it.

For a provider key whose model capability no catalog entry covers (a custom endpoint, a self-hosted gateway, a relay such as http://127.0.0.1:8791/…, or any provider added through the "Add provider" card), reasoningEfforts is the only way the model gets effort levels. Without it the model materializes as reasoning: false, and the composer shows "This model provides no reasoning effort levels." — no selector, no error, nothing in the log. The route still works, so the first sign of the problem is a missing control in the composer.

Why

lib/client.js (shipped bundle line ~862):

/** Adopt a candidate, preserving disclosed capacities and input types. */
function adopt(candidate) {
  return {
    id: candidate.id,
    ...(candidate.name === undefined ? {} : { name: candidate.name }),
    ...(candidate.contextWindow === undefined ? {} : { contextWindow: candidate.contextWindow }),
    ...(candidate.maxTokens === undefined ? {} : { maxTokens: candidate.maxTokens }),
    ...(candidate.inputModalities === undefined ? {} : { input: [...candidate.inputModalities] })
  };
}

and its only caller (~line 988, adoptPicked):

for (const candidate of candidates) {
  if (!picked.has(candidate.id)) continue;
  byId.set(candidate.id, byId.get(candidate.id) ?? adopt(candidate));   // existing rows win
}
onChange([...byId.values()]);

Rows already in the draft are preserved (byId.get(candidate.id) ?? adopt(...)), so simply adding another model keeps everything. The loss happens whenever the row is new: adding a model to a route for the first time, or removing a row and adding the same id back. A fixed field list is then the only source, and reasoningEfforts is not in it.

Reproduction

1. Add a custom provider whose installed catalog has no entry for the model (or use a plugin-created route — the effect is the same for any hand-written route).
2. Give one of its models a declared capability:

   models:
     - id: google/gemini-4-argon
       name: "Google: Gemini 4 Argon"
       contextWindow: 1048576
       maxTokens: 943718
       reasoningEfforts: { off: null, low: low, medium: medium, high: high, max: max }   # ← hand-declared

3. In Settings → Models, open that provider, remove the model row, then add the same id back with the picker (or add it to a route that had no models yet). Save.
4. The saved row is { id, name, contextWindow, maxTokens }. reasoningEfforts is gone and the composer offers no effort levels for it.

Recovery means re-declaring the levels by hand — either one level at a time in the per-model "reasoning efforts" editor, or by editing the profile patch YAML.

What would fix it

Either of these would remove the class of bug; I don't have the layout of the client internals to pick:

1. Keep the declaration. adopt(candidate) could merge a matching saved row (or the row captured at mount) instead of starting from the field list, so a remove-and-re-add round-trip is lossless.
2. Inherit the capability the way the adapter already does. A picked id that declares reasoningEfforts under any other provider key in the profile — or as a variant sibling (google/gemini-4-argon:flex → google/gemini-4-argon) — could adopt that map, the same evidence rule dsh-llm-pi-ai uses for a model's own declaration. For a custom provider the catalog cannot supply it, but the profile usually can.

A cheaper interim step would be to keep the operator aware: the row could show a warning like the existing modelReasoningNeedsLevel notice when its provider key has no catalog entry and it declares no levels.

Workaround being used today

I wrote a plugin (dsh-openrouter-plus) that watches the profile for app-boot/config-reload / settings/document-updated / llm/adapters-updated and re-fills reasoningEfforts on the routes it owns from exactly the evidence in option 2. It works, and it is what made the disappearance visible to me in the first place — but a plugin should not have to reconcile a config that its own editor just rewrote, and hand-written routes belonging to no plugin have no such safety net.

[GnaneshKunal]

Follow-up from the reporter: a plugin-side workaround now ships, and the upstream fix is still the right one.

I hit this while building dsh-openrouter-plus (a service-tier relay for OpenRouter) and worked around it with a plugin, in case it helps anyone hitting the same wall before this is fixed upstream:

• dsh-openrouter-plus watches the profile (debounced, on every config settle) and restores reasoningEfforts on relay-backed routes a moment after an edit like the one in this report lands. It never overwrites a declared map, never resurrects an explicit false, and writes nothing when there is nothing to do.
• The reason a plugin can do this at all: the only pre-persist rewrite point available to a third-party plugin is the Host internal/config waterfall, so the workaround lives on the Host side rather than fixing the card.
• Getting there required reading the catalog card's internals, because the settings.models.provider-card slot is observation-only ({ provider, configured, keyConfigured }, no setter, no draft), and the draft Base URL is private state in ProviderEditor. That asymmetry — a slot that renders inside a card it cannot influence — is the part I would most like to see addressed; it would let plugins like this one stop post-processing config.

The exact drop I traced, for whoever picks this up: adopt() builds the new provider object from a fixed field list, so any field the catalog does not know about is not copied. reasoningEfforts is the visible casualty; headers and other hand-declared per-model fields would go the same way.

Source for the workaround (MIT-ish, reference only, no obligation to look): https://github.com/GnaneshKunal/dsh-openrouter-plus