dsh-model-caps

dsh-model-caps

Fetch a provider's real /models list, review the capability fields it exposes (context window, max output, image input), edit them on one page, then save them back into llm-pi-ai.

Unlike catalog lookups that match a model name against a static table, this plugin asks the configured upstream and shows only what the upstream actually returned. Missing fields stay blank instead of being guessed, and vision support can be proven by a real image probe.

Why

llm-pi-ai accepts contextWindow, maxTokens and input per model, but most OpenAI-compatible gateways return only an id from GET /models. Filling those fields by hand is error-prone, and name-based catalogs are wrong for private routes. This plugin keeps a human in the loop: fetch, inspect, edit, save.

Install

dsh plugin --profile web add github:qingshanjiluo/dsh-model-caps

Then restart the profile, or let dsh-hotswap mount it when it is already installed.

Use

1. Open http://127.0.0.1:3080/model-caps/ in the same browser session as the

Web UI (the cookie authenticates the page).

1. Pick a provider. The list comes from llm-pi-ai.providers.
2. Click Fetch upstream. The plugin calls GET {baseURL}/models with that

provider's key from apiKeyEnv -> the credential store.

1. Review the table. Fields sourced from the upstream payload are marked in the

notes column; blank means the upstream did not expose it.

1. Optionally select rows and click Probe vision: a 32x32 red/blue PNG is

sent and a model counts as image-capable only when it answers with a colour.

1. Edit any cell, then click Save. The plugin writes

llm-pi-ai.providers..models through settings.mutate, preserving fields it did not touch.

Page file\n\nThe editor UI lives in dsh/model-caps.html and is read from disk on every request, so a UI change takes effect on refresh without restarting DSH.\n\n## Settings panel\n\nThe browser half registers a 模型能力 page in the DSH settings panel (settings.section) that embeds the editor at /model-caps/, so the plugin is reachable without knowing a URL. The iframe keeps the panel thin; the editor is still served and versioned by the host half.\n\n## Endpoints

Method · Path · Purpose GET · /model-caps/ · The editor page GET · /model-caps/providers · Configured providers, apiKeyEnv, model counts POST · /model-caps/fetch · { provider } -> upstream rows merged with current config POST · /model-caps/vision · { provider, ids } -> per-model image support POST · /model-caps/save · { provider, rows } -> write the model list back

Parsed capability fields

The reader accepts the common spellings gateways use:

• context: context_length, context_window, max_context_length,

max_input_tokens, max_model_len, top_provider.context_length, limits.context

• output: max_tokens, max_output_tokens, max_completion_tokens,

top_provider.max_completion_tokens, limits.output

• image input: architecture.input_modalities, input_modalities,

modalities.input, capabilities.vision, supports_vision, vision

Safety

• The page and endpoints live behind the same authentication fence as the Web

UI; a request without a valid session is rejected.

• The upstream is only contacted for the provider you select, and only when you

press a button.

• Saving replaces the model list of that one provider. Entries that were not on

the upstream are shown marked and are dropped unless you keep them.

• The API key never leaves the host: the browser talks to DSH, DSH talks to the

provider.

License

MIT