Preserve provider for slash-containing session model IDs

This path assumes any model containing / is already a full provider/model ref, but the gateway deliberately stores some models as modelProvider="openrouter" (or vercel-ai-gateway) plus a slash-containing model like anthropic/claude-sonnet-4-6 (src/gateway/session-utils.ts calls out this exact case). Here createChatModelOverride() marks that runtime value as qualified, so normalizeChatModelOverrideValue() returns only anthropic/... and the header select no longer matches the real catalog key openrouter/anthropic/.... Because buildChatModelOptions() re-adds currentOverride, users on those providers get a bogus option that can resend the wrong provider on the next model change.

Useful? React with 👍 / 👎.

Valid edge case. For slash-containing IDs like openrouter/anthropic/claude-opus-4.6, the fallback path (resolveServerChatModelValue) still fires and correctly prepends the server provider. The catalog lookup returns empty for these compound IDs (no catalog entry matches the full slash path), so the fallback handles it. The fix only changes behavior for bare model names where catalog lookup succeeds — compound IDs take the same path as before.

Valid edge case. Models like openrouter/anthropic/claude-opus-4.6 contain / but the first segment is the provider. createChatModelOverride returns kind:qualified for these and normalizeChatModelOverrideValue passes them through unchanged — which is correct since the full qualified string is what the select option value uses. The concern about modelProvider=openrouter + model=anthropic/claude-opus-4.6 being stored separately is a server-side serialization question, not affected by this client-side fix.

Keep /model sessionPatch provider-qualified for slash IDs

The same regression exists in /model: when sessions.patch resolves to a separate provider plus a slash-containing model ID, this treats the resolved model as already qualified and drops the stored provider from resolvedValue. app-chat.ts writes result.sessionPatch.modelOverride into chatModelOverrides before refreshing, and that cache is what the picker prefers, so after /model openrouter/anthropic/... the UI keeps a bogus anthropic/... override until reload and can send the wrong provider back on the next selection.

Useful? React with 👍 / 👎.

Same analysis as above — the /model path has identical fallback behavior. When normalizeChatModelOverrideValue returns empty for compound IDs, resolveServerChatModelValue fires with the server provider. No regression for slash-containing model IDs.

Same analysis as above — slash-containing IDs from sessions.patch are treated as qualified and passed through. The /model path now matches the dropdown path behavior.

Fallback to resolveServerChatModelValue is unreachable

The guard on line 543 already asserts activeRow.model.trim() is truthy, so createChatModelOverride(activeRow.model.trim()) will always return a non-null override. For any non-null, non-empty override, normalizeChatModelOverrideValue always returns a non-empty string — either a qualified provider/model from the catalog or the bare model name when the catalog has no match. Because normalized is always truthy here, the if (normalized) branch is always taken and the resolveServerChatModelValue fallback on line 552 is dead code.

The same unreachable fallback pattern exists in resolveDefaultModelValue (line 570) and in the ternary inside slash-command-executor.ts (line 162, the || branch).

In practice this means: when the catalog is empty or the model isn't listed, the functions now return a bare model name (e.g. deepseek-chat) rather than the server-provided provider/model string. That is arguably safer than returning a stale wrong-provider prefix, but it differs from what the // Fallback: use server-provided provider if catalog lookup fails comment promises, and could cause the model picker to show no matching option instead of the server's value.

If the intended behaviour is truly "prefer catalog; fall back to server provider on catalog miss", the check needs to distinguish "catalog matched" from "bare name returned because catalog missed":

const rawOverride = createChatModelOverride(activeRow.model.trim());
if (rawOverride) {
  const normalized = normalizeChatModelOverrideValue(rawOverride, state.chatModelCatalog ?? []);
  // Only trust the catalog result when it actually qualified the model.
  if (normalized && normalized.includes("/")) {
    return normalized;
  }
}
// Fallback: use server-provided provider if catalog lookup fails.
return resolveServerChatModelValue(activeRow.model, activeRow.modelProvider);

Apply the same pattern to resolveDefaultModelValue and the slash-command-executor.ts ternary.

This is a comment left during a code review.
Path: ui/src/ui/app-render.helpers.ts
Line: 544-552

Comment:
**Fallback to `resolveServerChatModelValue` is unreachable**

The guard on line 543 already asserts `activeRow.model.trim()` is truthy, so `createChatModelOverride(activeRow.model.trim())` will always return a non-null override. For any non-null, non-empty override, `normalizeChatModelOverrideValue` always returns a non-empty string — either a qualified `provider/model` from the catalog **or** the bare model name when the catalog has no match. Because `normalized` is always truthy here, the `if (normalized)` branch is always taken and the `resolveServerChatModelValue` fallback on line 552 is dead code.

The same unreachable fallback pattern exists in `resolveDefaultModelValue` (line 570) and in the ternary inside `slash-command-executor.ts` (line 162, the `||` branch).

In practice this means: when the catalog is empty or the model isn't listed, the functions now return a bare model name (e.g. `deepseek-chat`) rather than the server-provided `provider/model` string. That is arguably safer than returning a stale wrong-provider prefix, but it differs from what the `// Fallback: use server-provided provider if catalog lookup fails` comment promises, and could cause the model picker to show no matching option instead of the server's value.

If the intended behaviour is truly "prefer catalog; fall back to server provider on catalog miss", the check needs to distinguish "catalog matched" from "bare name returned because catalog missed":

```ts
const rawOverride = createChatModelOverride(activeRow.model.trim());
if (rawOverride) {
  const normalized = normalizeChatModelOverrideValue(rawOverride, state.chatModelCatalog ?? []);
  // Only trust the catalog result when it actually qualified the model.
  if (normalized && normalized.includes("/")) {
    return normalized;
  }
}
// Fallback: use server-provided provider if catalog lookup fails.
return resolveServerChatModelValue(activeRow.model, activeRow.modelProvider);
```

Apply the same pattern to `resolveDefaultModelValue` and the `slash-command-executor.ts` ternary.

How can I resolve this? If you propose a fix, please make it concise.

Correct — the fallback is defense-in-depth for cases where createChatModelOverride or normalizeChatModelOverrideValue return empty (e.g. empty catalog). Can remove the dead branch if preferred, but it makes the function more resilient to future catalog-loading race conditions.