dsh-model-capabilities · Custom Model Capabilities & Vision Multimodal Declarations for DeepSeek Harness (DSH)

English | 中文

   

Custom Model Capabilities & Vision Multimodal Declarations for DeepSeek Harness (DSH)
Per-Model Reasoning Tiers · Multimodal Vision Declarations · Provider Archive & Restore · Models Settings Extension

A custom model capability extension for DeepSeek Harness (DSH) Web GUI and official desktop client: visually declare reasoning effort profiles per model, customize payload values, configure multimodal vision inputs, and toggle provider activation states directly inside the official Models settings view without restarting the host.

What it does

• Seats the official extension area: registers the Models page's settings.models.provider-card slot for the llm-pi-ai adapter family, so every custom-provider card (hand-declared gateways, OpenAI-compatible endpoints, and named vendors alike) gains a collapsible "Model capabilities" area. That slot renders one extension area per provider card, so when another plugin claims the same adapter family first this panel reports the collision (browser console, plus a Models-page notice naming the plugin that holds the seat) and takes the cards back by itself as soon as that plugin is unloaded.
• Provider disable/enable: one click archives a provider's profile in the plugin's own settings namespace and takes the route down through the official Remove-provider seam (unset on llm-pi-ai.providers.<route>); the provider leaves the model catalog that both the composer model picker and the subagent selection read — immediately, in every open surface, without a restart. Enabling restores the archived profile verbatim (API keys live in the credentials service and are never touched). Disabled providers are listed in a footer area on the Models page, where they come back.
• Reasoning efforts per model: a tri-state editor per model — undeclared (inherit), declared non-reasoning (reasoningEfforts: false, which stops the model picker from offering thinking levels), or an explicit level dict. Levels run from off through max; each enabled level carries a wire-spelling field (what the request actually sends, defaulting to the level name), plus a one-tap common low/medium/high preset. off may keep an empty wire value, meaning "supported, send nothing".
• Writes through the official wire: saves are a single path operation replacing the provider's whole models array in the llm-pi-ai settings namespace — the same whole-array override the official card performs. Fields this plugin does not edit (ids, display names, input modality claims, context windows, compat switches) survive every save, and the write applies live without a restart.
• Validates before the host refuses: the editor enforces the adapter's own acceptance rules (a level dict needs at least one level beyond off; every non-off level needs a non-empty wire value) and shows the reason a draft would be refused, instead of letting the host reject it after the fact.
• Conflict-safe: every save carries the revision the panel read at; if the configuration changed in another surface, the panel reloads and asks for a retry instead of overwriting.

Install

From the family bundle

The dsh-web-all aggregate bundle includes this plugin; mounting that bundle is enough.

Standalone (development)

git clone https://github.com/zhu1090093659/dsh-web.git
cd dsh-web
pnpm install
pnpm -r build
dsh plugin --profile web add link:$(pwd)/packages/dsh-model-capabilities

Restart dsh web. Open Web settings, Models; every custom provider card now carries the capability area below its catalog editor.

Configuration

The plugin's own settings entry holds nothing but the disabled-provider archive (its disabled field, generated by the host from the plugin's config schema); there is nothing to configure by hand. Capability declarations and the enable/disable state live in the official llm-pi-ai entry plus this archive, all editable on the Models page.

Semantics you should know

• Declarations are claims, not probes: nothing interrogates a gateway about what it accepts. A wire value the endpoint does not understand fails at request time — the field exists precisely because nothing can infer it.
• The panel edits declared models only: a route serving the built-in pi-ai catalog without a models array shows guidance instead of an editor, because the browser cannot enumerate that catalog. Add the model rows in the card's catalog editor first (an entry whose id matches a catalog model overrides it field by field), then declare capabilities here.
• Reasoning levels are selector vocabulary: the declared levels are what the composer's model picker offers for that model; the wire value is what rides the request. off with an empty wire value means the parameter is simply not sent when that level is chosen.
• Disable is archive-and-unset, in that order: the profile is written to the archive before the route goes down, so a failed step can leave a harmless duplicate archive but never a lost profile. Enabling refuses when the route has grown a new profile in the meantime, so a restore can never clobber newer configuration. While a provider is disabled, delegation to it fails closed at the host (NO_ADAPTER), not just in the UI.

Known limitations

• Input types are out of scope: the Models page's own model editor writes the input modality claim (alpha.2), so this plugin preserves that field rather than editing it — declaring image input happens in the catalog editor above.
• The DeepSeek direct adapter (llm-deepseek) is not covered: its catalog is fixed and its reasoning-effort control already exists on the Models page.
• A provider card whose route is still an unsaved draft dispatches no extension area; save the provider first.
• Only one plugin can extend the llm-pi-ai provider cards at a time. A colliding plugin never disappears silently: the Models page footer states that another plugin holds the extension seat and names it, and the panel returns by itself once that plugin stops loading.
• Disable works on profiles the user settings layer owns — exactly the hand-declared providers the Models page writes. A provider profile declared in the composition (base) layer cannot be taken down from the client: the settings merger guarantees user writes cannot remove it, so the toggle is not offered there.