dsh-magpie-lite

Expose your local magpie-lite gateway to DeepSeek Harness as a normal provider. Once installed, DSH's model picker gains a magpie-lite group listing every model you enabled in the gateway console — configure once, and DSH / Claude Code / Codex share the same model set.

Install

From the plugin marketplace (recommended)

DSH Settings → Plugin Marketplace → search dsh-magpie-lite → Install. This path uses the prebuilt npm package, so no allowBuilds approval is needed.

From the command line

dsh plugin --profile web add dsh-magpie-lite

Manually

Copy-Item -Path "<repo>\*" -Destination "$env:USERPROFILE\.dsh\profiles\node_modules\dsh-magpie-lite" -Recurse -Force

Then add dsh-magpie-lite to dsh.profile.bundles in profiles/desktop/package.json and restart DSH. Installing from source makes pnpm intercept build scripts, so you must add allowBuilds to the profile's pnpm-workspace.yaml yourself; the npm package is prebuilt and has no such step.

How it works

DSH model picker
   |  magpie-lite/deepseek-chat
   v
dsh-magpie-lite (this plugin)
   |  locates the gateway's config.json (see below)
   |  builds a pi-ai provider over openAICompletionsApi
   |  ctx.llm.registerAdapter(['magpie-lite'], adapter)
   v
magpie-lite gateway  http://127.0.0.1:19998/v1
   |  routes by provider/model prefix
   v
DeepSeek / GLM / Kimi / OpenCode Zen / OpenRouter / Ollama / Pollinations

The plugin never touches request payloads — protocol translation, streaming, and tool calls all belong to the gateway.

How the plugin finds the gateway

Gateways live in different places on different machines, so no path is hardcoded. Resolution order:

1. The MAGPIE_LITE_CONFIG environment variable — points at your config.json
2. $MAGPIE_LITE_HOME/config.json — a custom gateway install directory
3. The pointer file <DSH home>/magpie-lite.json — written by the gateway on startup, recording the absolute path of its config.json. This is the main mechanism, and it works wherever the gateway happens to be installed
4. <DSH home>/magpie-lite/config.json — the conventional location, as a fallback when the gateway is not running
5. A config.json shipped next to this plugin

<DSH home> is $DSH_HOME, else ~/.dsh.

While the gateway runs, the pointer is always current. When it does not, the plugin falls back to the conventional path, and reports the expected location instead of silently showing zero models.

Requirements

1. The gateway must be running. Install the magpie-lite gateway itself first — this plugin is only the bridge; the gateway does the actual forwarding. For autostart: powershell -ExecutionPolicy Bypass -File <gateway-dir>\register-autostart.ps1
2. At least one provider enabled. Open http://127.0.0.1:19998/admin, add a key, flip the switch. With none enabled the plugin still loads, just with an empty group (DSH hides empty groups).

Common tasks

Changed gateway config / added models

No DSH restart needed — the plugin watches config.json and re-registers (400 ms debounce).

Different port or gateway key

Edit port / gatewayKey in your gateway's config.json. The plugin reads the same file, so both stay in sync automatically. The pointer's baseUrl may lag if the gateway was last started with PORT=xxxx; the config's port is what the plugin ultimately uses.

config.json lives elsewhere

Set the environment variable MAGPIE_LITE_CONFIG to your config.json path, then restart DSH. When the gateway suite is installed elsewhere, set MAGPIE_LITE_HOME to that directory instead.

Diagnostics

The CLI runs standalone, no DSH needed:

node "$env:USERPROFILE\.dsh\profiles\node_modules\dsh-magpie-lite\lib\bin.js"

It prints the route, key fingerprint, and the models that will be registered. A count of 0 means the problem is on the gateway side, not DSH. It also prints which config.json it actually used — if that is not the file you expected, check MAGPIE_LITE_CONFIG, MAGPIE_LITE_HOME, and the pointer file.

Gateway logs: <gateway-dir>\data\gateway.watch.log (watchdog restarts) and data\boot.log.

Known limits

• The model list comes from config.json, not live upstream queries. Whatever the gateway's Models page shows is what gets registered.
• Only the text modality is declared. Whether images work depends on the upstream model.
• stop sequences are unsupported — a pi-ai-wide limitation, not specific to this plugin.

Free-model naming

Free models carry a （免费） suffix on their display name (DSH's picker shows openai（免费）). The test is whether that provider declares free: true in config.json:

{ "id": "pollinations", "free": true, "models": ["openai", "openai-fast"] }

It has to be an explicit free: true — inference from "no apiKey filled in" would mislabel paid providers such as DeepSeek or Zhipu, whose keys are simply not entered yet. The suffix only changes the display name; the model id (provider/model) is untouched, so routing and calls are unaffected.