dsh-plugin-model-hub
A DeepSeek Harness web plugin that adds a
Model Hub settings page for configuring:
- every provider's profile fields (
displayName, api, baseURL, models) in
settings.yaml,
- per-provider and per-model context windows (
defaultContextWindow on the
provider, contextWindow on each model — the value the web UI shows as the
context budget, so a 1M-token model displays 1M instead of the 256K pi-ai
default),
- per-provider API keys (stored through the credentials service, never
written into
settings.yaml),
- per-provider API-error retry/backoff tuning (max retries, initial/max
wait, jitter, retryable error codes) — the knobs
dsh-llm-retry executes,
- the default Agent model, and
- declaring brand-new pi-ai provider routes (an OpenAI-compatible gateway or any
protocol
dsh-llm-pi-ai supports).
Why this page exists
The built-in Models settings page reads and writes through the loopback-only
settings mirror, which is deliberately unavailable when the GUI is served
over insecure HTTPS or a non-loopback origin ("settings are unavailable in this
browser"). This plugin does not depend on that mirror: every read and write
goes straight over the wire through the stock settings, credentials, and
llm RPC domains, so the page works on any origin the harness itself can reach.
How it works
The package is a dual-face cordis plugin:
- host half (
lib/index.js) — a stub entry that exists so the package is a
real loader entry in the profile. The web app's client-modules scan only
discovers client bundles for packages that are active loader entries declaring
dsh.client.
- client half (
lib/client.js) — the browser page and its data layer,
registered into the settings.section slot. It talks to the harness through
the stock RPC domains; no custom transport is needed.
Install
The plugin ships with a bundle patch (cordis.patch.yml) that inserts one
loader row, model-config. Two equivalent install paths:
1. Via dsh plugin (recommended)
From a checkout at <checkout>:
dsh plugin --profile web add file:/path/to/dsh-plugin-model-hub
dsh plugin runs pnpm add in the profile directory, then reconciles the
profile's dsh.profile.bundles layer list: any dependency whose manifest
declares dsh.bundle (this one does) joins the bundle layers automatically.
For local development, prefer a symlinked spec so source edits take effect
without reinstalling:
dsh plugin --profile web add link:/path/to/dsh-plugin-model-hub
2. Manually
- Add
dsh-plugin-model-hub to the profile's dsh.profile.bundles in
~/.dsh/profiles/web/package.json and make it resolvable from the profile
(e.g. pnpm --dir ~/.dsh/profiles/web add file:/path/to/dsh-plugin-model-hub),
or
- merge the row from
cordis.patch.yml into the profile's
~/.dsh/profiles/web/cordis.patch.yml yourself.
Then restart the profile (dsh web) — the client-modules scan runs at
activation, so a fresh boot is required to pick up a new bundle.
Using the page
The Model Config section appears in Settings (next to the built-in
sections). For each provider row you can:
- see whether a credential is configured,
- edit profile fields and models,
- enter or replace the API key (leaving it blank keeps the stored one),
- override the retry policy — unset fields keep
dsh-llm defaults
(normal mode, 5 retries, 500 ms → 10 s exponential backoff, 10% jitter),
- delete a provider whose profile is user-defined (and its stored key).
Development
npm test # data-layer tests (node:test, no browser needed)
The test harness loads lib/client.js in a VM with a fake wire api, so the
store, write paths, and retry-policy building are covered without a browser.
License
MIT
