dsh-unified-model

Switch model and reasoning effort across every DeepSeek Harness session at once — one control, all conversations, effort included.

中文

DeepSeek Harness stores the model choice per session. The shipped default-model setting only covers sessions that have not chosen one yet, and /model only ever changes the session you are in. So there is no built-in way to move a whole session history onto one model/effort pair at once.

This plugin adds that missing control to the composer row:

[⇉ All sessions]  [ deepseek-v4.1-flash ▾ ]
                   ^ the shipped model picker, untouched

In a narrow window the button collapses to its glyph so it stops competing for room with the model picker:

[⇉]  [ deepseek-v4.1-flash ▾ ]

The same control stays reachable either way — the full name lives in the button's title and aria-label, so the icon-only form is not an unlabelled mystery.

Open it, pick a provider, a model and a thinking effort, and choose the scope:

Option	Effect
Every session	writes the selection into every session that can hold its own
Every other session	same, but leaves the session you are looking at untouched
Also make this the default	additionally writes the deployment default, so sessions created later start on it

A live done/total counter runs while the batch is in flight, and the result reports what changed, what already matched, and what failed.

Why effort is included

Most "apply a model to all sessions" attempts stop at the model, because effort looks like it belongs to a different layer. It does not:

• sessionController.selectModel() takes { provider, model, reasoningEffort? }.
• The selection it commits is appended to the session log as a model/selection event, and that event's schema carries reasoningEffort.
• The modelSelection projection re-reads it, and selectionFor() restores it after a restart, so the effort survives.

Verified on a live profile: a written session log contains

{"type":"model/selection","seq":4,"data":{"provider":"tencent-intranet","model":"deepseek-v4.1-flash-ioa","reasoningEffort":"max"}}

That is why this plugin compares provider and model and reasoningEffort when it decides whether a session already matches. A plugin that compares only the first two will report success while silently leaving effort unapplied.

Scope and limits

Case	Behaviour
Ordinary sessions	Updated — the target of the control
Subagent sessions	Not touched. They follow their parent's routing and the host rejects per-session selection for them. Counted separately in the result so they are never mistaken for failures
A session already carrying the target selection	Skipped, no write. A repeat click on an already-unified history finishes in milliseconds
A session whose log is corrupt or locked by another process	Reported as failed with the host's own reason, and the rest of the batch continues

The batch runs on the Host, not in the browser, so closing the tab does not interrupt it. The client half only starts the run and polls its progress.

How it works

It does not patch a shipped plugin, rewrite session logs, or edit projection caches. It calls the same public host API the built-in /model dialog calls:

sessionController.list({})                  → every session, with its current selection
sessionController.selectModel({ sessionId, provider, model, reasoningEffort })
sessionController.modelCatalog()            → provider groups and each model's published efforts
agentDefaultModel.saveSelection({ … })      → the deployment default, when requested

Because the write path is the official one, session state stays in the official format, uninstalling changes nothing, and a future Harness that renames these methods costs you this plugin only — never the rest of the app.

Three route exist, all behind the composition's connection trust fence:

GET  /unified-model/state    → catalog, default, every session's selection, current run
POST /unified-model/apply    → { provider, model, reasoningEffort?, scope, excludeSessionId? } → { runId }
GET  /unified-model/status   → the live run, or the last one
POST /unified-model/default  → write the deployment default

Read before write

selectModel resumes each cold session, which is by far the most expensive part of the operation. So the plugin reads every session's selection from list() first and skips matching ones. Measured on a 55-session profile: the first run wrote 36 sessions in 2.7 s; the immediate repeat skipped 53 and finished in 56 ms.

Validate before writing

An unknown model or an effort the model does not publish makes the adapter reject the request. Both are checked against modelCatalog() before the first session is touched, so a typo fails the request instead of failing 60 sessions one by one:

400 model-unknown       the catalog does not list p/m
400 effort-unsupported  p/m publishes low, medium, high, xhigh, max; ultra999 is not one of them

The client offers exactly the levels the model publishes, so the two never disagree.

Install

dsh plugin --profile <your-profile> add dsh-unified-model

Or from a checkout:

dsh plugin --profile <your-profile> add link:/path/to/dsh-unified-model

Restart the app afterwards — bundle patch layers and client bundles both load at startup.

Configuration

None. The control appears in the composer row; there is nothing to set up.

Requirements

• DeepSeek Harness 0.2.0 or newer.
• The web UI (the control lives in a composer slot).

Development

npm test      # node --test; covers the selection reader and the skip rules
npm run check # node --check on both halves

index.js is the Host half (routes, the batch). client.js is the browser half (the chip and the panel). test/selection.test.mjs pins the one decision that matters: whether a session counts as already correct.

License

MIT