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