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.
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.
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: thatdsh's actual plugin loader accepts this exact shape end-to-end (e.g.dsh plugin --profile <name> 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.
dsh plugin --profile <your-profile> add lynkr-dsh-pluginOn 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-autoThen:
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).- Make sure Lynkr is running:
lynkr start(see the Lynkr repo). - Select the
lynkrprovider indsh'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.
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.
npm install
npm run buildMIT