dsh-model-capabilities

When you connect a custom or gateway model, DSH often shows a frustrating message: the reasoning slider says no selectable tiers are available, and image upload is simply rejected because the model does not support image input. The root cause is straightforward - the model never announced its reasoning or vision capabilities, and DSH can only rely on what the model reports. The old workaround was editing settings.yaml by hand, hunting down the right entry for each model, which is error-prone and easy to forget.

The model-capabilities plugin turns that into a small form. Under the Settings page, each model gets two fields. The reasoning tier selector offers inherit, disabled, or a custom checklist across seven levels from off to max, where you can also map each tier to the real name your gateway expects - for example, if your gateway calls a tier something different from the default. The vision toggle offers inherit, vision-capable, or text-only. Save, and both the reasoning slider and the image gate respect the new configuration immediately.

On the safety side, manual routes only get their models list updated; other fields stay untouched. Catalog routes receive a single-model modelOverrides entry rather than replacing the entire model directory. Every write includes a version check, so if two windows are editing the same model at once, a conflict prompt appears instead of a silent overwrite. Data lives in the native DSH llm-pi-ai config, not in plugin-private storage, so uninstalling the plugin will not wipe your settings.

This is for anyone running gateway models, local inference endpoints, or other manually registered LLMs who wants per-model control over reasoning depth and image acceptance. If you only use first-party catalog models and everything already works, you probably do not need this.