DSH Modality Declarations: V4.1 Flash Image-to-Text Downgrade

DeepSeek V4.1 Flash accepts text and images, but DSH decides whether to preserve an image from the local model catalog. Community source analysis found that the legacy deepseek-v4-flash ID can be routed by the provider to V4.1 Flash while DSH still treats its catalog entry as text-only and replaces the attachment with deterministic text.

The transformation happens before the request reaches the API. A vision-capable backend does not guarantee that the local Harness preserves image data.

Same backend, different local declarations

The current DeepSeek API model ID is deepseek-flash. During compatibility routing, legacy IDs may reach the same V4.1 Flash backend. Their DSH catalog declarations differ:

Two IDs can therefore reach the same provider route through different attachment-processing paths inside DSH.

How an image becomes text

DSH reads model capabilities before constructing the provider request. A model without image input enters the text-model compatibility path. The source path identified in the discussion is:

model ID
  → catalog inputModalities
  → projectImagesForTextModel
  → textOnlyImageText
  → text message sent to the provider

projectImagesForTextModel projects image content for a text model, and textOnlyImageText produces deterministic replacement text. The provider receives the transformed message rather than the original image block.

This path can complete without an error. The model returns a normal text response, so the visible symptom is often weak image detail, behavior consistent with not seeing the attachment, or a reply based only on replacement text.

Diagnose four layers

1. Selected model ID

Check the actual ID in Models, the Profile, or Session settings. A V4.1 Flash display name is not enough. The current ID should be:

deepseek-flash

2. Catalog declaration

Verify that the model entry explicitly contains:

{
  "inputModalities": ["text", "image"]
}

Custom providers and manually copied legacy entries are common places for this field to be missing.

3. Provider request

In a safe test environment, inspect the request structure or debug output. A vision request should contain an image content block or file reference. Replacement text alone shows that the downgrade happened inside DSH.

4. Effective provider route

Confirm the effective model and current price on the provider side. Compatibility aliases can continue to work, but new configurations should use the current ID to reduce divergence between local capabilities and backend routing.

Fixes

Use deepseek-flash

Create or edit the model configuration with the current ID and verify that both text and image inputs are declared. Changing only the display name does not update capabilities.

Remove duplicate legacy entries

Several aliases that reach V4.1 Flash create nearly identical choices in the model picker. After confirming that no Session depends on an old entry, remove manually added duplicates or label their capability and purpose clearly.

Retest in a new Session

Model capabilities are selected as part of Session or run configuration. After editing the catalog, start a new Session, upload an image with unambiguous details, and ask a question that cannot be answered without those pixels.

Compare payloads

Run the same image through the legacy ID and deepseek-flash, then compare message structures. The test is whether the image block survives, not whether the final wording looks similar.

Minimal regression test

Prepare one image containing:

• random text absent from the filename;
• a spatial relation between two objects;
• a clear color.

Ask for each detail and record the model ID, DSH version, inputModalities, request content-block types, and response. These checks distinguish actual vision input from attachment replacement quickly.

Why this class of bug is easy to miss

A model ID acts as both a provider route and a local capability key. The provider can map a legacy ID to a new model while the local Harness still uses an old catalog entry to decide how images, audio, and files enter a message. Server compatibility keeps the request reachable; it does not update the client's payload construction.

Audit each layer during model migration:

Relationship to v0.1.6-alpha.1

v0.1.6-alpha.1 improves V4.1 image resizing, token estimates, and default request quality. Those changes operate on the image path; they do not replace a correct modality declaration. A text-only catalog entry can still route the attachment through text projection first.

Related reading

• DeepSeek V4.1 Flash in Harness
• DeepSeek Harness vision-model configuration
• DeepSeek Harness v0.1.6-alpha.1 update
• DeepSeek V4.1 Flash API, architecture, and benchmarks

FAQ

Why change the old ID if it already routes to V4.1 Flash?

Provider routing and DSH capability declarations are separate layers. The old ID can reach V4.1 Flash while the local catalog still classifies it as text-only.

Does a successful request prove that the image was sent?

No. The text-projection path produces a valid message and a normal API response. Inspect content blocks or test details that can only come from the image.

Can I add inputModalities to the old entry?

A custom provider entry can declare the missing capability, but new configurations should prefer deepseek-flash so the model ID, catalog, and provider route stay aligned.