Expose per-model image-input capability in the web Models editor

[Marker689]

Problem

When using a model that is actually vision-capable (e.g. deepseek-v4-flash-vision-exp, or third-party models like Claude/GPT through llm-pi-ai), sending an image fails with:

The current model does not support images; switch to a model that does
(MODEL_DOES_NOT_SUPPORT_IMAGES)

The model picker gives no hint about which models accept images, and the Models settings page cannot express it.

Root cause

dsh gates image input on each model's declared modalities (inputModalities). The web Models editor (dsh-client-ui-settings-models) only lets you edit per model:

• id
• name
• contextWindow / maxTokens (behind the row's disclosure)

It never exposes the modality list. For llm-pi-ai the field is input (it falls back to ["text"] when absent, so a model row created from the UI is automatically text-only); for llm-deepseek it is inputModalities (plus imagePixelBudget / imageMaxBytes / imageDetail). So even a known vision model gets treated as text-only and images are rejected — with no way to enable them from the UI.

Current workaround

Hand-edit $DSH_HOME/settings.yaml:

llm-pi-ai:
  providers:
    local:
      models:
        - id: deepseek-v4-flash-vision-exp
          input: [text, image]

This works but is non-obvious (the field name differs per provider, and a row re-saved through the UI can drop the field). See also discussion #112.

Proposed change

1. Add a per-model "Supports images" toggle in the web Models editor that writes input: [text, image] for llm-pi-ai and inputModalities: [text, image] for llm-deepseek. Optionally expose the image limits (imagePixelBudget, imageMaxBytes, imageDetail).
2. Preserve the modality fields when a model row is edited/re-saved via the UI, so a custom input is not lost.
3. Optionally surface a vision-capability badge in the model picker so "switch to a model that does" is actionable.

This removes the need to hand-edit settings and makes image capability clearly configurable per model from the web UI.

[mackwan84]

I ran into the same missing control and implemented a focused patch in my unofficial fork:

• Commit: configure model input capabilities
• Download the patch
• Base: official master at 49a606bc5b5934603f22a26957a07dc799ab0291 (0.1.2-alpha.5).

The pi-ai model row's advanced settings now offers three choices:

Choice	Saved model configuration
Inherit defaults	Remove the entry's input override
Text only	input: [text]
Text and images	input: [text, image]

Inheritance needs its own choice: clearing an override should restore the installed model's modalities or the provider fallback, rather than explicitly disabling images. Existing empty arrays, reversed modality order, and image-only declarations are displayed without rewriting them during unrelated edits. Image-only entries have a disabled display option to preserve the existing declaration. The shared editor covers both adding a provider and editing an existing one, including read-only mode and English/Chinese copy.

One clarification from current master: known catalog models can already inherit image support, and the editor already preserves existing input fields when editing other fields. The missing piece addressed here is the explicit per-model control. This patch leaves the resolver, conservative defaults, model discovery, and image admission unchanged; it does not add controls for the direct llm-deepseek adapter. Selecting image input is a user declaration, not an endpoint capability probe.

Screenshot from the isolated local Web configuration test, after saving and reopening the model. The selected option is Text and images (文本与图片).

Local validation on macOS passed:

• 90 provider-form tests, with 100% statements/branches/functions/lines for ModelListEditor.tsx in the focused coverage run.
• 12 real-Web configuration tests, including persistence to settings.yaml, reopening, removing the override, and replaying the updated accessibility snapshot.
• Production build, lint, typecheck, and all 32 doc-sync checks.
• Manual browser acceptance; bilingual README and Agent Note included.

The Web tests exercise configuration without making model API calls; they do not establish whether any particular endpoint accepts images.

I understand that external PRs are not currently accepted, so I am sharing the implementation here for evaluation. Would this narrowly scoped change be useful upstream? I would be happy to adjust it to maintainer feedback and open a PR if invited, or have the patch adopted directly.

[IndenScale]

I can reproduce the same issue with the following model:

deepseek-v4.1-flash-expires-on-0910

This model supports image input and works successfully with the same endpoint in OpenWebUI. However, in DSH the model is treated as text-only, and attaching an image fails immediately with:

MODEL_DOES_NOT_SUPPORT_IMAGES

The model is provided through an OpenAI-compatible route. Since its exact model ID is not present in the built-in catalog and the Models UI has no way to declare input: [text, image], there is currently no way to enable image input from the UI.

Environment: DSH v0.1.5-alpha.1, Web UI.

This suggests the issue also affects newly introduced or gateway-specific vision model IDs, not only the built-in catalog models.