dsh-profile-switch

A dsh plugin: named model profiles you can switch and configure interactively through the host's native ask-user flow — one implementation that works on the TUI and the web surface, and fails fast with guidance on headless.

A model profile is a snapshot of your whole model configuration:

• the default model + think level (a saved /model selection), and
• optional per-subagent model/thinking overrides.

Switching between contexts (work ↔ personal) becomes one command instead of a /model + per-agent tour.

"profile" means two different things in dsh — this plugin is the model kind. A dsh profile (~/.dsh/profiles/<name>/, dsh --profile <name>) is the boot-time plugin composition; it cannot change while the process runs. The model profiles this plugin switches live in ~/.dsh/model-profiles.json, apply at runtime, and are scoped to the workspace tree that binds them.

Install

dsh plugin --profile <your-profile> add @aiwayds/dsh-profile-switch

The plugin mounts with inject: ['commands', 'userQuestions'] — both are dsh-base services, so it coexists with any surface and any plugin stack.

Commands

/profile-switch

One question: which profile this workspace tree binds to. Answering applies the profile in layers:

1. Live default model — when a live-selection channel exists: on the TUI through dsh-tui-pi's selection bridge, on the web through the session controller. The current conversation continues on the new model immediately. Without a channel the summary says so; the route still lands through the tree pin on the next session.
2. Tree binding — writes .dsh-profile into the current directory (nearest file up the tree wins, .nvmrc style), so every NEW session in this tree assembles its initial selection from the profile. Other trees are untouched: a switch is workspace-scoped, never machine-global.
3. Subagent overrides — written nowhere at apply time. Each agent's runtime model/thinking is composed at spawn from the agent file's frontmatter baseline ⊕ this pinned profile's overrides (recomputed on every dispatch, including continuations), which is what keeps a switch fully workspace-scoped.

The switch deliberately does NOT write the global agent-default-model setting — that stays /model's write, and crossing tree boundaries is exactly what a profile switch must not do.

The list also carries (unbind this tree) when the tree is bound: removes the pin (guarded — a hand-decorated pin file is never clobbered; the plugin refuses and says so).

/profile-cfg

The configuration wizard — an operation menu, then the matching flow:

Every model choice is a three-step narrowing chain of separate ask-user questions — provider → that provider's models → that model's think levels — because each step's options depend on the previous answer. All three lists are read live from the installed llm adapters (listProviders / listModels / resolveModelInfo), so think levels are exactly what the adapter serves — never hardcoded (the llm-deepseek route rejects medium; only the adapter knows what a model accepts). A provider that lists nothing falls back to typing a model id; a model with no selectable efforts skips the think step.

Cancel anywhere (Esc / closing the question) aborts the wizard with nothing saved — the store is written exactly once, at the end.

Subagent overrides (with dsh-subagent-registry)

When dsh-subagent-registry is installed, the new/edit wizards add a multi-select over your discovered agents (~/.dsh/agents/*.md), then the same provider → model → think chain per selected agent — with (inherit) leading every step. Composing semantics:

• a recorded non-empty value wins over the agent file's frontmatter;
• an empty entry (both steps inherited) records an explicit inherit;
• agents absent from the profile compose from the baseline.

Without the registry the overrides would have no consumer, so the per-agent section is skipped with a note and profiles simply hold the main default model — detection is a contract-member probe (composeAgentRuntime / readModelProfilesDoc / workspaceProfileName), the same convention dsh-tui-pi established.

Surfaces

On a surface with no ask-user answerer (headless runs one task and exits), the commands fail fast with guidance pointing at the non-interactive path: write <workspace>/.dsh-profile and edit ~/.dsh/model-profiles.json directly. Nothing hangs.

Storage & files

• ~/.dsh/model-profiles.json — the store ($DSH_HOME honored). Versioned (version: 1), self-healing (a corrupt/unknown file degrades to the seeded work / personal / other profiles, never throws), atomically written (tmp sibling + rename). This file is a shared contract: dsh-subagent-registry reads it (spawn-time composition) and dsh-tui-pi's session bootstrap reads it (new-session seeding from the pin). Schema:

  {
    "version": 1,
    "current": "work",            // informational, last applied anywhere
    "profiles": [
      {
        "name": "work",
        "defaultModel": { "provider": "zai-coding-cn", "model": "glm-5.3", "reasoningEffort": "high" },
        "agents": {
          "workhorse": { "model": "volc-ark-plan/deepseek-v4-flash", "thinking": "high" },
          "oldfox": {}              // empty entry = explicit inherit
        }
      }
    ]
  }

• <workspace>/.dsh-profile — the tree pin: one line naming the profile; blank lines and # comments allowed. The plugin overwrites it on a switch ONLY when it parses as exactly one entry line — a hand-decorated file is refused and surfaced, never clobbered.

Relation to dsh-tui-pi

The model-profile feature moved here from dsh-tui-pi (which carried it as TUI-only panels). Pairing:

• with a dsh-tui-pi that provides the dshTuiModelSelection bridge: /profile-switch also live-switches the current TUI session's default model;
• with an older/newer tui-pi without the bridge: everything else works; the live leg degrades to "next session in this tree" and the summary says so;
• the per-agent editing entry in tui-pi's /agents manager writes the same store with the same schema — both editors coexist;
• dsh-tui-pi ≥ 2.18.1 recommended on the TUI. tui-pi 2.16.0–2.18.0 dropped these command names from its never-aborting dispatch list while moving the panels here, so a /profile-cfg session longer than 90s echoed a spurious aborted due to timeout (the panel itself kept working; 2.18.1 restored the dispatch). On web/headless surfaces no such guard exists and any plugin version pairs with anything.

No manual profile wiring is expected anywhere: dsh plugin add reconciles the bundle entry, the bundle patch mounts the plugin, and the commands register on every surface the profile boots.

Uninstall

dsh plugin --profile <your-profile> remove @aiwayds/dsh-profile-switch

The plugin owns no daemons and holds no host resources, so removal is clean on the next boot. Your data is intentionally preserved:

• ~/.dsh/model-profiles.json — delete it if you want the store gone;
• <workspace>/.dsh-profile pins — delete per tree (rm .dsh-profile); a pin naming a missing profile simply binds nothing.

Development

pnpm install
pnpm build && pnpm check && pnpm test   # unit suite (builds first)
node scripts/smoke-boot.mjs             # real-host boot gate (needs global dsh)
pnpm contract                           # write↔read handshake with the registry
                                        # (auto-skips where no registry resolves)

The contract check proves the deployed three-repo shape on real files: the plugin's store write (pin + per-agent overrides) composed back through the registry's composeAgentRuntime — override wins, explicit-inherit and baseline fallback hold, and the probe leg confirms registryDetected() resolves through the profile's sibling node_modules exactly as it does in a live deployment. On machines/profiles without the registry it degrades to a documented skip, so it can run anywhere.

scripts/link-dsh-closure.mjs re-points node_modules/@deepseek-ai/* at the global dsh CLI's own closure so typecheck and tests see exactly one cordis. CI runs the same steps on Node 22/24 plus the boot smoke, and a daily schedule watches for upstream rc/stable drift.

License — MIT.