[UX] Session model switching should not overwrite the deployment default

[NOirBRight]

Summary

In 0.1.0-rc.7, choosing a model in one Web session also overwrites the deployment-wide agent-default-model setting. These appear to be different user intents:

• the session picker chooses the model for the addressed conversation;
• the deployment default chooses the initial model for future sessions and other entry points.

Please consider making session.selectModel session-local and moving default changes to an explicit settings action (or an explicit “Set as default” action).

Current behavior

1. Note the current agent-default-model value in settings.yaml.
2. Open an existing Web conversation and select another model.
3. The addressed session switches as expected.
4. The selected route is also written to agent-default-model, so subsequently created sessions inherit it.

The Host path currently updates the session selection and then awaits the deployment-default write:

session.selectModel → dsh-host-apiproxy → saveDefaultModelSelection → ctx.agentDefaultModel.saveSelection → settings.yaml

Relevant official sources:

• session.selectModel implementation
• ApiProxy wiring to ctx.agentDefaultModel.saveSelection
• Agent Note documenting that the picker writes the default
• Introducing commit: f2d1a296

Why this is surprising

A user may keep a stable default for new work while selecting specialized models for individual conversations. With the current behavior, visiting an old session and changing its model silently changes future-session behavior.

The Settings write is also on the interactive response path. In one local reproduction, session.models completed in about 1.7 ms, while a no-op session.selectModel took about 2.14 s because a stale external Settings writer lock made the default save wait for its timeout. The stale lock was not created by DSH, but a session-local model switch should not depend on deployment-settings persistence in the first place.

Expected behavior

• session.selectModel changes only the addressed session.
• agent-default-model changes only through an explicit deployment-default configuration action.
• Failure or contention in the Settings provider cannot delay an otherwise valid session model switch.

An optional combined “Switch and set as default” action could be added later, but it should be explicit.

Related discussions

I did not find a Discussion dedicated to this picker/default coupling. It is mentioned as a side effect in #1581, and the current behavior is used as a workaround in #455. Those reports focus on subagent inheritance from a stale creation-time route, so this request is related but distinct.

Environment

• @deepseek-ai/dsh@0.1.0-rc.7
• Web UI

[denial123789]

I verified this boundary against rc.7 (99f6f02) and found four distinct state lifetimes that are useful when diagnosing the impact:

1. the bundle composition default;
2. the Settings-backed deployment default;
3. the live session selection;
4. the durable route recorded in the next request/header.

The current session.selectModel path assigns the session selection first, then awaits saveDefaultModelSelection(selected). A Settings failure is caught and logged, so it does not undo the session switch. Without a Settings provider, that save is a no-op. With the ordinary Web composition, however, the accepted selection is written under agent-default-model, including the resolved reasoning effort.

For rc.7 operators, the safest sequence is:

• record the deployment default before a temporary specialist-model switch;
• verify the next request/header, not only the picker label;
• assume every accepted Web selection changed the future-Agent default;
• restore the intended default after the specialist turn;
• verify a new Session or subagent from its own first request header.

That last point matters for cost investigations because the visible parent picker is not sufficient evidence for a child or future Agent's actual route.

I turned the source path, four state lifetimes, and acceptance gates into a visual runbook here: https://sandbaseai.github.io/deepseek-harness-handbook/session-model-default.html

Independent community handbook, not an official DeepSeek AI project.