AI Agent Hub
Back to plugins
🤖

dsh-openrouter-providers

Model Inference Updated 2026.08.25

Run the following command in DeepSeek Harness:

dsh plugin install MoRanYue/dsh-openrouter-providers

Paste the following prompt into your AI chat to install this plugin:

Visit https://github.com/MoRanYue/dsh-openrouter-providers to obtain the plugin source, then follow the README to add it to your profile dsh.profile.bundles list and restart DeepSeek Harness to enable OpenRouter provider routing configuration.

About this plugin

OpenRouter aggregates providers like DeepInfra and Together, routing requests automatically by default. In practice, you often need to pin specific providers, try them in a strict priority order, or cap quantization at int8 to reduce latency and cost. dsh-openrouter-providers gives DeepSeek Harness users a fine-grained routing remote — every OpenRouter request carries the provider parameters you configured, no code changes required.

Open the OpenRouter Providers panel under Plugins → Plugin Settings, enter provider slugs one per line, pick either Allow-only or Priority-order mode, and optionally set a quantization ceiling (int4 / int8, etc.). Once saved, the plugin automatically injects provider.only, provider.order, or provider.quantizations into the body of every OpenRouter request. Settings persist through the DSH settings service into a local config file and survive restarts, so you never have to re-enter them. The plugin also attaches App Attribution headers so your traffic appears as DeepSeek Harness OpenRouter on the OpenRouter leaderboard instead of an unknown client.

Ideal for teams that rely on specific OpenRouter-backed providers and want to avoid unpredictable routing to unavailable or high-latency nodes; developers who need to enforce a quantization ceiling to manage inference cost; or anyone who wants a deterministic degradation chain from fast to stable providers. Keep in mind that image input is not supported, and in Allow-only mode a request will fail outright if every listed provider is offline — this is OpenRouter fallback behavior by design.

Use Cases

  • Pin specific providers to avoid unpredictable routing to unavailable or high-latency nodes
  • Set priority order for graceful degradation from fast to stable providers
  • Cap quantization precision (int8/int4) to reduce inference latency and per-token cost

Best For

  • Developers who rely on specific OpenRouter-backed providers for daily inference
  • Team engineers who need to control inference cost and latency
  • Platform leads who want deterministic provider degradation instead of random routing