lynkr-dsh-plugin
A DeepSeek Harness (dsh) plugin that registers Lynkr — a self-hosted, multi-provider LLM tier-routing gateway — as a custom OpenAI-compatible provider.
Lynkr sits in front of coding agents and chat clients and routes each request to the cheapest model tier that can actually handle it (classifying difficulty per-request), across 15+ providers — Anthropic, OpenAI, Azure OpenAI, Bedrock, Vertex, OpenRouter, Moonshot, Baidu, Z.AI, Ollama, DeepSeek, and more.
Unofficial / community plugin
This is not affiliated with or endorsed by DeepSeek. DeepSeek Harness's own repository does not accept external pull requests to its built-in provider catalog (see their CONTRIBUTING.md) — publishing a package tagged dsh-plugin is their documented path for community integrations instead, so that's what this is.
Verification status — please read before relying on this
This plugin was written against DeepSeek Harness's published documentation (docs/user/develop/basic/publish.md, docs/user/guide/providers.md), not against a live dsh install — I didn't have one available while writing it. What that means concretely:
- ✅ The TypeScript source (
src/index.ts) is syntax-valid (checked with Node's type-stripping loader). - ✅ The
settings.yamlshape it writes matches DeepSeek's own documented custom-provider schema verbatim. - ✅ The
package.json→dsh.bundle.patch→cordis.patch.yml→ plugin-row wiring matches their documented bundle-manifest schema verbatim. - ⚠️ Not yet confirmed: that
dsh's actual plugin loader accepts this exact shape end-to-end (e.g.dsh plugin --profile add lynkr-dsh-pluginsuccessfully loading and callingapply()). Their plugin API surface is explicitly a "developer preview... iterating rapidly with compatibility-breaking changes."
Because of that uncertainty, the plugin is written to fail safe: if anything about the load or the settings.yaml merge doesn't go as expected, it changes nothing and prints the exact YAML to add by hand instead (see "Manual setup" below — that path has no dependency on the plugin loader at all and will always work).
If you try this against a real dsh install, please open an issue or PR with what you found — first real-world confirmation gets a note here.
Install (once published)
dsh plugin --profile add lynkr-dsh-plugin
On next load, this adds to $DSH_HOME/settings.yaml:
llm-pi-ai:
providers:
lynkr:
apiKeyEnv: LYNKR_API_KEY
api: openai-completions
baseURL: http://127.0.0.1:8081/v1
models:
- id: lynkr-auto
Then:
1. export LYNKR_API_KEY=anything (Lynkr doesn't enforce auth on local requests by default — set this to whatever your instance actually expects if you've locked it down).
2. Make sure Lynkr is running: lynkr start (see the Lynkr repo).
3. Select the lynkr provider in dsh's model picker. Whatever model you pick there is a label — Lynkr's own tier router decides the real backend server-side based on request complexity.
It never overwrites an existing lynkr entry, and never touches any other provider's config.
Manual setup (no plugin required)
Skip the plugin entirely and just add the block above to $DSH_HOME/settings.yaml yourself. This is the fallback path the plugin itself prints if the automatic merge ever fails, and it's equally valid as your starting point.
Development
npm install
npm run build
License
MIT
