lynkr-dsh-plugin

Readme

# lynkr-dsh-plugin

A [DeepSeek Harness](https://github.com/deepseek-ai/deepseek-harness) (`dsh`) plugin that registers **[Lynkr](https://github.com/veerareddyvishal144/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`](https://github.com/topics/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.yaml` shape 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 <name> add lynkr-dsh-plugin` successfully loading and calling `apply()`). 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)

```bash
dsh plugin --profile <your-profile> add lynkr-dsh-plugin
```

On next load, this adds to `$DSH_HOME/settings.yaml`:

```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](https://github.com/veerareddyvishal144/lynkr)).
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

```bash
npm install
npm run build
```

## License

MIT