DeepSeek Harness Goes Multimodal: V4-Flash-Vision-Exp Guide
DeepSeek Harness now supports DeepSeek-V4-Flash-Vision-Exp for native image input. See the rc.8 to 0.1.1-rc.1 timeline, setup steps, limits, and vision plugins.
On August 21, 2026, DeepSeek shipped DeepSeek-V4-Flash-Vision-Exp, its first native multimodal model, and DeepSeek Harness (dsh) landed support for it the same day in 0.1.1-rc.1. Text capability matches plain V4-Flash, pricing is unchanged, and each image costs up to 384 tokens. Upgrade dsh, pick the Vision model under Settings → Models, and you can paste or @-reference images directly in a session — no OCR workaround plugin required anymore.
This guide covers what the model actually is, how dsh's multimodal support arrived across three recent releases, how to turn it on, and where the rough edges still are.
What DeepSeek-V4-Flash-Vision-Exp actually is
DeepSeek announced the model on its official account, describing it as an experimental multimodal release whose text abilities — including agentic reasoning and world knowledge — are on par with the existing V4-Flash model (x.com/deepseek_ai/status/2090730032574631962). Key specs from that announcement:
| Property | Value |
|---|---|
| Model name | DeepSeek-V4-Flash-Vision-Exp |
| Status | Experimental |
| Text capability | On par with V4-Flash |
| Max tokens per image | 384 |
| Pricing | Same as V4-Flash |
| API surfaces | Chat Completions, Messages, Responses |
| Image reuse | Files API (free) |
DeepSeek's own benchmark numbers, self-reported in the same announcement thread, put multimodal agentic performance close to Opus-4.8: ApexBench moved from 26.2 to 36.5, and Agents' Last Exam scored 27.3 against Opus-4.8's 25.7. Treat these as DeepSeek's own figures — they haven't been independently reproduced, and we're not aware of any third-party benchmark run on the vision variant yet. For general model documentation and API reference, see DeepSeek's official API docs.
How dsh's multimodal support arrived: rc.8 → 0.1.1-rc.1
The vision model didn't appear in isolation — dsh's multimodal plumbing was built out over three releases in five days, which is worth knowing if you're troubleshooting an older install:
| Release | Date | What changed |
|---|---|---|
0.1.0-rc.7 | 2026-08-17 | MCP and ACP gain support for persistent image attachments in session history |
0.1.0-rc.8 | 2026-08-19 | Multimodal infrastructure: the DeepSeek model adapter can be configured to send native image requests, /goal and /plan accept combined text+image input, and the @ mention menu can reference files and prior sessions |
0.1.1-rc.1 | 2026-08-21 | The DeepSeek adapter formally adds DeepSeek-V4-Flash-Vision-Exp as a selectable model — this is dsh's first minor-version bump past 0.1.0 |
Source: GitHub release notes for dsh-v0.1.1-rc.1 and dsh-v0.1.0-rc.8. Notably, DeepSeek's official account didn't post anything about the harness-side release — the rc.8 and 0.1.1-rc.1 version details circulated through third-party observation before the GitHub release notes confirmed them, which is normal for this project: dsh has no CHANGELOG and doesn't announce harness updates on social media the way it does model launches.
If you're still running anything at or below 0.1.0-rc.6, none of the image-handling code paths above exist yet — you're on pre-multimodal dsh, and an upgrade is required before any of the steps below will work.
Before this: the "pseudo-vision" era
Worth knowing if you've been running dsh since its first week: before native vision support existed, "getting dsh to look at a screenshot" meant routing images through a bridge plugin that ran OCR and pixel-level heuristics, then handed the extracted text to a text-only model — never true image understanding. A community post from @YinsenW_ (2026-08-19) called this out directly while covering the rc.8 release, noting the workaround was "kind of clever" but fundamentally a hack around the absence of a real multimodal model. With DeepSeek-V4-Flash-Vision-Exp now available as a first-class model choice, that bridge-plugin pattern is on its way out — though as covered below, some of those plugins remain useful for routing between vision-capable and text-only models rather than faking vision outright.
Getting started with Vision in dsh
Four steps, assuming you already have dsh installed:
-
Upgrade to
0.1.1-rc.1. If you're launching vianpx, pin the version explicitly so you know which one you're getting:npx @deepseek-ai/dsh@0.1.1-rc.1 webIf you installed globally, reinstall with the same version pin (
pnpm add -g @deepseek-ai/dsh@0.1.1-rc.1or your package manager's equivalent). See Upgrading DeepSeek Harness for the full rc.6 → rc.8 → 0.1.1-rc.1 upgrade checklist, including a couple of breaking changes unrelated to vision that you'll hit along the way. -
Select the Vision model. Go to Settings → Models, open the DeepSeek provider card, and pick
DeepSeek-V4-Flash-Vision-Expfrom the model list (or add it if your existing DeepSeek provider entry predates this release). No API key change is needed if you're already authenticated against DeepSeek's official endpoint. -
Attach an image. In a session, paste an image directly into the composer, or use the
@mention menu to reference an image file already in your workspace. Both paths route through the same DeepSeek adapter now configured for native image requests. -
Send a task that uses the image. A generic, low-risk way to test this: paste a screenshot of a UI you want changed and ask the agent to adjust the corresponding CSS or component code in your workspace. Because the model is experimental and per-image cost is capped at 384 tokens, keep test images reasonably sized and don't expect pixel-perfect fine detail extraction — treat early runs as a sanity check, not a benchmark of the model's ceiling.
If you're routing through a custom or self-hosted OpenAI-compatible provider instead of DeepSeek's official endpoint, the model has to be explicitly declared as accepting image input — dsh doesn't infer this. In $DSH_HOME/settings.yaml:
llm-pi-ai:
providers:
my-gateway:
apiKeyEnv: GATEWAY_API_KEY
api: openai-completions
baseURL: https://gateway.example/v1
models:
- id: legacy-chat
- id: vision-preview
input: [text, image] # undeclared models default to text-only and reject images
Any model missing the input: [text, image] declaration will reject attached images before the request even goes out. This applies to third-party gateways generally — DeepSeek's own official chat-completions route is configured for you once you select the Vision model in Settings, no manual YAML edit needed. Full provider configuration is covered in Custom Model Providers in DeepSeek Harness.
Known limitations
- Experimental status. DeepSeek itself labels the model experimental, not production-stable — expect behavior and pricing to potentially shift in future releases.
- Large images and payload growth. Oversized images, or sessions that accumulate many historical images, have caused request failures;
0.1.0-rc.8's release notes mention fixes to a batch of these issues, but the release notes text was truncated in our source and didn't list every case covered. If you hit a failure on a long-running session with several attached images, trimming older image attachments from context is worth trying first. - 384 tokens per image is a hard ceiling. Fine detail in dense screenshots or diagrams may not survive that budget — don't assume the model can read small text reliably.
- Custom providers need explicit configuration. As shown above, any non-DeepSeek-official model needs
input: [text, image]declared or image attachments are rejected outright. - No independent benchmark verification yet. The ApexBench and Agents' Last Exam numbers above are DeepSeek's own, from the announcement thread — we haven't seen a third-party reproduction.
Vision plugins in the FindHarness catalog
Even with native vision support, plugins still add value on top of it — routing between vision-capable and cheaper text-only models, generating images rather than just reading them, or bridging older workflows. A few worth knowing from our Vision, Voice & Multimodal category:
- dsh-vision-router — routes requests to a vision-capable model only when an image is actually attached, falling back to a cheaper text model otherwise.
- dsh-vision-toolkit — a broader toolkit of vision-related utilities for sessions that mix image and text work.
- dsh-image-gen — generates images inline from a session, the inverse direction of reading them.
- modlens — one of the original bridge plugins from the pseudo-vision era, still useful if you need to keep supporting text-only models alongside the new Vision model rather than switching everyone over at once.
Browse the full set at /categories/vision-multimodal, or the whole catalog at /plugins.
FAQ
Do I need a different API key for the Vision model?
No. If you already have a DeepSeek official API key configured under Settings → Models, selecting DeepSeek-V4-Flash-Vision-Exp uses the same credential — pricing is the same as V4-Flash, so there's no separate billing setup.
Does the Vision model replace text-only V4-Flash?
No — it's a separate, additional model choice. DeepSeek describes its text capability as on par with V4-Flash, not a strict upgrade, and it's explicitly experimental. Switch per-session or per-task rather than assuming it should be your new default everywhere.
Can I use vision with a self-hosted or third-party model through dsh?
Yes, but only if that provider's model entry declares input: [text, image] in $DSH_HOME/settings.yaml (or modelOverrides for a built-in provider). Without that declaration, image attachments are rejected before the request is sent. See the config example above and Custom Model Providers for the full setup.
What happened to the old OCR-based "vision" plugins?
They're not obsolete, but their role has changed. Before DeepSeek-V4-Flash-Vision-Exp, bridge plugins like modlens used OCR and pixel analysis to fake image understanding for text-only models — a workaround called out publicly as such by the community. With native vision now available, those plugins are more useful as a fallback path for text-only models than as the primary way to "see" images.
Is this the same thing as the multimodal support added in rc.8?
Related but not identical. 0.1.0-rc.8 (2026-08-19) added the underlying infrastructure — native image requests in the model adapter, image+text input to /goal and /plan, and @-mention file/session references. 0.1.1-rc.1 (2026-08-21) is what actually wires that infrastructure to a real vision-capable model. You need both — an install below rc.8 lacks the plumbing, and rc.8 alone has no vision model to plug into it.
Next steps
Start with DeepSeek Harness Quickstart if you haven't set up dsh at all yet, or Upgrading DeepSeek Harness if you're on an older rc build and need the rc.6 → rc.8 → 0.1.1-rc.1 path. For the config mechanics behind non-DeepSeek vision models, see Custom Model Providers in DeepSeek Harness, and for how image attachments persist through tool integrations, DeepSeek Harness MCP Guide. Once you're set up, browse vision-focused plugins in /categories/vision-multimodal or the full index at /plugins.