dsh-model-order
在“设置”>“模型”中重新排序任意 llm-pi-ai 路由的模型列表；编写器模型菜单也会遵循相同顺序。
插件会安装到这里；不确定时保持 web。
npx -y @deepseek-ai/dsh plugin --profile web add github:Wany-i/dsh-model-order#2247993a8ea52a8b19b3451dc4b23db96212314fModel Order 以 dsh-model-order 发布，当前版本为 0.1.0。Plugin Hub 会校验它的 manifest，并保存精确安装来源，便于复现安装结果。
Reorder your models in DeepSeek Harness — in Settings, where you can see them. The composer's model menu follows the same order, because it is the same order.
English | 中文
dsh-model-order adds an ordering area to every provider card on Settings → Models for llm-pi-ai routes. Move a model up, down, to the top or to the bottom; sort the list by name; or put it back the way it was. The order you set is the order the composer's model menu shows.
Features · Compatibility · Install · Quick start · Configuration · Permissions & data · How it works · Troubleshooting · Development
| Feature | Description |
|---|---|
| ↕ Move one step | Up / down buttons swap a model with its neighbour |
| ⇈ Move to an end | Send a model straight to the top or the bottom |
| 🔤 Sort by name | Natural ordering, so m2 lands before m10; case-insensitive and stable |
| ↩ Undo / restore | Put the order back — see the two restore paths |
| 🔒 Order lives in your config | The order is the models array you already have; no second place to keep in sync |
| 🧩 No official file touched | Contributed through the extension slot the Models page declares for outside plugins |
In DSH there is exactly one source of truth for model order: the models array of a provider's configuration. Everything downstream preserves it:
cordis.patch.yml providers.<route>.models: [ … ]
│
▼ dsh-llm-pi-ai · resolveRouteModels() keeps the configured order
▼ ctx.llm.listModels(provider) keeps it
▼ buildModelCatalog() keeps it, per provider group
▼ the Models settings page renders it, numbered 1, 2, 3 …
▼ the composer model menu renders it, "model order within each group is unchanged"
So the settings list and the composer menu are not two orderings that have to agree — they are the same ordering, read twice. That is why changing the order under Settings changes the composer, and why this plugin never needs to patch the composer at all.
"Restore" means different things depending on the route, and DSH's own adapter is what decides which:
| Route kind | Button | What happens |
|---|---|---|
pi-ai ships a catalog for it (anthropic, openai, …) | Restore default order | Removes the route's models list, so it falls back to the models pi-ai ships |
Hand-declared route (router, a relay, a self-hosted endpoint) | Undo this change | Puts the list back into the order it had when you opened the card — nothing is removed |
The second row is a safety gate, not a limitation. The pi-ai adapter refuses to resolve an empty model list for a route its catalog does not describe ("the installed catalog does not describe this route, so its models must be listed in configuration"). Unsetting models on such a route would leave it with zero models and a catalog error. So this plugin only offers the destructive reset where it is actually safe, and offers a non-destructive undo everywhere else. To use the real reset on a hand-declared route, delete its models entry yourself — you will be told immediately if it cannot work.
| Item | Value |
|---|---|
| DSH | web and desktop profiles, >=0.2.0-rc.1 <0.3.0-0 (verified against 0.2.0-rc.2) |
| Node | >=20 (build only; the plugin ships prebuilt) |
| Depends on | dsh-client-ui-settings-models (declares the slot), dsh-client-ui-settings (settings transport), dsh-client-ui-renderer (slot registry) |
| Applies to | llm-pi-ai routes. DeepSeek official, DeepSeek account and third-party adapter families are untouched |
# From GitHub (lib/ is committed, so no local build is needed)
dsh plugin --profile desktop add github:Wany-i/dsh-model-order
# Or from a local checkout
npm install && npm run build
dsh plugin --profile desktop add file:/absolute/path/to/dsh-model-order
Restart DeepSeek Harness afterwards, then hard-reload the page (Ctrl+F5) so the client half is re-fetched.
| Action | Command |
|---|---|
| Upgrade | re-run add, then restart |
| Remove | dsh plugin --profile desktop remove dsh-model-order |
router) and expand its card.If a card shows "This route has no model list of its own…" instead of the ordering area, that route has no
modelslist in your configuration and therefore serves the models pi-ai ships. There is nothing to reorder until you declare models for it — see below.
None. The plugin has no settings namespace and no persisted preferences of its own: the order it edits is your configuration, so there is nothing else to configure or keep in sync.
Add or edit models in the same card using the official editor; this plugin's area only changes their order.
models array of the route you reorder.id, name, contextWindow, maxTokens, input and any field this plugin does not know about are carried through byte-for-byte. Nothing is added and nothing is removed.cordis.patch.yml edit is refused rather than overwritten.settings.models.provider-card for plugins distributed outside its repository, dispatched with entryKey = settingsNs for every card that shows a provider row.llm-pi-ai). No official file is patched, and a deployment without that family dispatches the area nowhere.models array through ctx.configForms, and writes it back with a single { op: 'set', path: ['providers', route, 'models'], value: [...] }.The pure parts (src/order.ts, src/client/section.ts) hold no React and no DOM, so they are tested directly; tsconfig treats sources as erasable-syntax-only TypeScript so node can run them without a build step.
| Symptom | Cause and fix |
|---|---|
| The area does not appear at all | The client half is not loaded. Re-run dsh plugin --profile desktop add <spec>, restart DSH, then hard-reload the page. |
| The area never appears on any card | The pi-ai family is composed under a settings entry id other than llm-pi-ai. The dispatch key is that id, so PROVIDER_NAMESPACES in src/client/index.ts has to name it. The plugin renders nowhere rather than misbehaving. |
| The area appears on my routes but not on an unconfigured catalog route | Working as intended: a route you never configured gets no note, so the page is not buried in them. |
This route has no model list of its own | Working as intended: the route inherits the pi-ai catalog. Declare models on it to reorder. |
| Controls are disabled | The settings document is read-only, or the client is in memory mode (a non-loopback browser without Host persistence). |
The settings changed elsewhere… | Another writer bumped the revision; the list refreshed. Retry on the refreshed list. |
| Sorted list looks wrong | Ordering is natural and case-insensitive, by name when present, otherwise by id. |
| Restore is not offered for my route | It is hand-declared; use Undo this change instead, or remove models yourself. |
npm install
npm run verify # typecheck + build + all specs
npm run watch # rebuild on change
| Path | Contents |
|---|---|
src/order.ts | Pure ordering: move, sort-by-name, restore-to-capture |
src/client/section.ts | Pure shape knowledge: where models lives, and the write ops |
src/client/ModelOrderCard.tsx | The slot contribution |
src/client/index.ts | Registration and the settings face |
src/index.ts | Host half — deliberately empty |
test/order.spec.mjs, test/section.spec.mjs | Behaviour of the pure modules |
test/patch.spec.mjs | Packaging contract: patch ↔ manifest ↔ bundle |
test/bundle.spec.mjs | Integration: loads the built half and drives the registration chain |
Type declarations for the integration surface come from the published official packages, pinned to the same version as the runtime. If you target a different DSH release, align the @deepseek-ai/* devDependency versions with it.
The repository URLs in package.json point at Wany-i/dsh-model-order; change them if you publish under another account.