DeepSeek Harness Vision Models: Fix Image Support Errors

When an OpenAI-compatible vision model is added to DeepSeek Harness, DSH can still report that the current model does not support images—even when the upstream model can process them. The usual cause is the DSH model capability declaration: a model entry must explicitly include the image input modality before a Session will accept an image attachment.

This guide uses the official @deepseek-ai/dsh-llm-deepseek documentation and source, plus a community issue report, to explain configuration and troubleshooting. The Web model-editor limitation described here was observed against v0.1.2-alpha.4; later versions may change the interface.

Locate the layer that rejects the image

An image passes through at least three checks before a model can use it:

1. The upstream model or compatible gateway must actually accept image input.
2. The DSH model catalog must declare both text and image for that model.
3. The image size, pixel budget, and transport must satisfy provider limits.

The DSH Session Controller checks the selected model's inputModalities first. If image is absent, it rejects the attachment before calling the model and returns the reason MODEL_DOES_NOT_SUPPORT_IMAGES. Upstream support alone therefore does not tell DSH that the model is multimodal.

Why custom models default to text only

The official llm-deepseek plugin accepts an inputModalities field whose current values are text and image. Its default is only text. A custom entry that includes an ID, name, context window, and output limit—but no modality declaration—therefore remains text-only.

In the alpha.4 Web model editor, the UI saved id, name, contextWindow, and maxTokens, but did not expose an image-capability field. This explains a common mismatch: the endpoint can see images, but the DSH catalog rejects them.

Declare vision support in a Composition

After confirming that the compatible endpoint supports images, add inputModalities to the model entry in the @deepseek-ai/dsh-llm-deepseek Composition configuration:

- name: '@deepseek-ai/dsh-llm-deepseek'
  config:
    apiKeyEnv: YOUR_API_KEY
    baseURL: https://your-openai-compatible-endpoint.example/v1
    models:
      - id: your-vision-model
        name: Your Vision Model
        inputModalities:
          - text
          - image
        contextWindow: 128000
        maxTokens: 8192
        imagePixelBudget: 4194304
        imageMaxBytes: 10485760

The numbers are structural examples, not universal recommendations. Match them to the real provider documentation. imagePixelBudget must be a positive integer or the supported low value; imageMaxBytes limits the size of one image.

One important rule: an explicit models list replaces the plugin's complete default model list; it does not append one entry. Copy every model you still need into the new list. A model list in Settings can likewise replace the Composition list, so export or back up the current configuration before editing.

How the official DeepSeek route behaves

The package documentation says that the direct deepseek-official route supplies a default catalog when models is omitted, including an experimental vision entry. This is different from adding an arbitrary model behind an OpenAI-compatible endpoint.

An unlisted model ID may still pass through to the upstream API, but the plugin treats that pass-through model as text-only. Successful text pass-through is not automatic vision-capability detection.

Troubleshoot in this order

1. Test the upstream API first

Use the provider's official example to send a small image with the same model ID, endpoint, and API key. Do not infer support only from a model name containing vision or a marketing page.

2. Verify the selected model

Make sure the Session is using the vision entry you edited, not a similarly named text model. After switching, start a small test Session to reduce interference from earlier state.

3. Inspect inputModalities

The entry must contain both text and image. If the model was later saved through the Web editor, check whether the UI discarded fields it did not display.

4. Reduce the test image

Start with a normal JPEG or PNG that is comfortably below provider limits. If the capability check passes but the request still fails, inspect imagePixelBudget, imageMaxBytes, MIME type, and upstream constraints.

5. Separate input from output

Current DSH image support centers on input attachments. The package documentation says direct external image URLs and assistant image output are unsupported. Supplying a durable Session attachment is different from asking the model to generate an image.

Security and compatibility notes

• Declare image only for models that genuinely support it; a false declaration merely moves the failure upstream.
• A self-hosted gateway may log or forward images. Remove credentials, personal information, and customer data from screenshots.
• Alpha configuration fields and interfaces can change. Repeat a small-image smoke test after upgrading.
• Treat a community workaround as version-specific guidance, not as a permanent UI contract; check the schema and official docs for the version you run.

Related reading

• DeepSeek Harness v0.1.1-rc.2: Vision, Files API, and security
• DeepSeek Harness v0.1.2-alpha.3: long chats and image delivery
• DeepSeek Harness security guide

FAQ

Why does DSH reject images when the model provider supports them?

DSH does not infer capability only from the model name. A custom entry defaults to text and must explicitly declare inputModalities: [text, image].

Can I configure this only in the Web UI?

The public alpha.4 report showed that its model editor did not expose inputModalities. If the field is still absent in your version, use its supported Composition configuration and verify that a later UI save preserves the field.

Does adding image guarantee vision requests will work?

No. It passes DSH's local capability check. The upstream model, compatible gateway, image format, and size must still support the actual request.