dsh-openrouter-plus

dsh plugin --profile web add dsh-openrouter-plus

dsh-openrouter-plus



**Service-tier routing and a live model list for OpenRouter — as a DeepSeek Harness plugin, with

no patched packages.**

DSH's OpenRouter support has two gaps, and neither one is reachable from a provider profile.

Routing. OpenRouter lets you steer where a request is served from: flex endpoints bill half

price on a slower pool, priority endpoints bill a multiplier for lower latency, and the throughput

or price comparators reorder the pool in between. @deepseek-ai/dsh-llm-pi-ai exposes baseURL and

headers on a provider profile, but no request-body fields

(discussion #9787).

Model discovery. Fetch available models is answered from the catalog baked into

@earendil-works/pi-ai, and for a catalog-backed route (openrouter) it answers before it reads

that route's baseURL. The snapshot only refreshes when pi-ai is published again, so every model

OpenRouter has added since then is invisible — on the build this plugin was written against, that was

65 of OpenRouter's 463 live models, including openai/gpt-6.1-terra,

moonshotai/kimi-k3.1-pro and x-ai/grok-4.20-multi-agent. Pointing the row at another endpoint

does not help: the provider name is what short-circuits, not the URL.

This plugin closes both gaps from the outside, and it never patches a shipped package. A **loopback

relay applies the routing preset to each request. Sync live models** reads the endpoint a route

points at and lists it, so you can tick the models you want and add just those. Both ride on schema

fields the profile already has, so both survive bun install -g upgrades and never touch

~/.bun/install/global.

The preset is chosen per session, at request time. One provider row keeps serving every preset, so

switching never mints a provider, a route or a model list.

  composer chip: this session runs on «priority»
      │
      ▼
  dsh-llm-pi-ai ──►  dsh-openrouter-plus relay  ──►  https://openrouter.ai/api/v1
      baseURL =           │ reads the session from x-session-id / prompt_cache_key,
  127.0.0.1:8791/t/<id>/v1  │ applies that session's preset to the body
                            └── /__openrouter-plus/* ──► OpenRouter Plus settings page
                                  ├ /models      reads the live listing
                                  └ /models/add  adds only the ticked models

What you get

• Sync live models. A provider row routed through OpenRouter Plus also gets a **Sync live

models…** button. It reads the endpoint that row points at and shows what it publishes *right

now* — including models added after the pi-ai catalog in your install was generated — with a

filter box and a checkbox per model. Tick what you want and only those are added; models the

route already declares are marked added and cannot be added twice. Nothing is rewritten:

hand-written names, context windows and effort maps are left exactly as they are. A row that is

not routed shows the switch alone: the button belongs to the opt-in, not to every llm-pi-ai card.

• One provider row, any preset. A routed provider keeps its key, protocol and models and gains

one thing: a composable preset that the relay applies to each request. No per-preset provider

copies, no sibling route per preset, no model list duplicated nine times.

• Pin one endpoint, not just a tier. A fourth thing the chip can set: a specific upstream

endpoint (relace/fp4, deepinfra/fp8/priority) read from the model's live listing. A pin is a

hard pin — provider.only plus allow_fallbacks: false — so a request goes to that endpoint or

surfaces the upstream error, instead of quietly landing somewhere else. Picking one disables

the Tier and Precision cells and shows the endpoint's own values, because the endpoint already

decided both.

• Speed beside the price. Each endpoint row in that menu can also state how fast it is — output

tokens per second and milliseconds to the first token, OpenRouter's own rolling 30-minute

percentiles — read with your key on the first request that names the model, and refreshed as you

use it. Five facts do not fit one 220 px row, so Settings → OpenRouter Plus carries a checkbox per

fact and a choice between the median and the median-plus-p90.

• Pinned base URLs for what a chip cannot cover — /v1 (no pin), /default/v1 (Standard),

/flex/v1 (Flex), /priority/v1 (Priority), /ultrafast/v1 (Ultra). Paste one into an

OpenAI-compatible provider route and that preset applies to every Session on the route,

subagents included, and survives a restart. The relay still serves the older names

(/auto/v1, /fast/v1, /scale/v1); the settings page lists one mount per preset so it never

offers the same choice twice.

• Its own settings page (Settings → OpenRouter Plus) showing relay state, one pinned base URL

per preset with a copy button, live request/token counters per preset, the measured effective

multiplier, spend in USD (today, the retained window, cost per preset), and recent requests.

The same page is the bundle's body on its Plugins card

(Plugins → Installed → OpenRouter Plus, in the sidebar's plugin manager), beside the version and

the Uninstall button — so the plugin is configurable from where it was installed, not only from

the nav row it added.

• A preset chip in the composer — next to the model selector, a compact chip shows the preset

this Session will actually apply and switches it in one click. The switch is per session: it

changes what the next request from this conversation carries, so two conversations can sit on

Flex and Priority at the same time. It shows up on a brand-new Session

…(truncated)