Blog · Guide
DeepSeek Harness vision on rc.8: three different “can see images” stories
August 20, 2026 · dshbase · updated for 0.1.0-rc.8
After dsh 0.1.0-rc.8, a lot of coverage says DeepSeek Harness “can see images now.” That sentence conflates three things that are not the same: the product narrative, the official model catalog, and the plugins that actually pass install tests. This page is the side-by-side: what marketing implies, what the repo still withholds, and what you should install today.
1. The rc.8 multimodal narrative
rc.8’s story is real as a harness story: image attachments in flows like /goal / /plan, Agent Store–style plugin discovery, and the idea that a text-only agent can still “borrow eyes.” Community write-ups often flatten that into “native vision works.” That oversell is the trap. The harness can route pixels; that does not mean DeepSeek’s official vision endpoint is open for everyday API use.
2. The catalog gap: deepseek-v4-flash-vision-exp
In the official tree you can find experimental vision wiring — names like deepseek-v4-flash-vision-exp and input: [text, image] — plus notes that the model stays out of the formal catalog until the endpoint is ready. So: scaffolding may be present; the public, catalogued, ready-to-point-at vision API is not. Do not configure a “official DeepSeek vision model” today and expect image understanding to just work. See also the short status note on the model setup page.
Honest info gap: we cite the public release / agents notes that say “not in catalog until endpoint ready.” We are not claiming insider ship dates. When the catalog lights up, this page will move the CTA — until then, plugins remain the working path.
3. The verified path: vision packs
What does work on a clean profile is the plugin path we already L1–L4 tested. Start from the scene packs, not from star count:
- Vision for text-only models — modlens (vision bridge / OCR+layout JSON), dsh-vision-toolkit (image Q&A, long-screenshot OCR), dsh-vision-router (routing / free vision chain).
- Artist & creative vision — same bridge + toolkit, plus design/GenUI slots (
dsh-openpencil,dsh-genui) when you need a creative surface, not just OCR.
Every pack slot on dshbase points at a plugins.json entry with test=verified. That is a different bar from Hub badges or “700+ dsh-plugin” store counts. How we define verified: audit methodology.
Delegation vs native overlays (still the useful split)
Delegation plugins send the image to a vision-capable endpoint (or a free chain) and return text/JSON for the text model — modlens, dsh-vision-toolkit, dsh-vision-router. Native overlays keep grounding inside dsh — dsh-vision-primitives (Set-of-Mark grid). UX glue: dsh-drop-to-path turns drag-and-drop into a path the text model can hand to a vision tool. Prefer packs for the default install set; reach for primitives only when you need precise pointing.
Upload rejection is still a separate bug
Third-party vision models (gpt-class, kimi, o-series, grok, …) can still fail image upload through the gateway even when the model itself is multimodal. That is an upstream round-trip issue, not proof that “DeepSeek officially sees.” Routing through a verified vision plugin remains the reliable workaround.
How to choose today
- Just need “read this image” → install the vision pack (start with modlens).
- Long screenshots / UI diffs / Artifacts → keep dsh-vision-toolkit in the pack.
- Routing / free chain → dsh-vision-router.
- Design / charts on top of vision → artist pack.
- Waiting for official API vision → watch the catalog; do not treat rc.8 marketing as “endpoint live.”
The bottom line
rc.8 made the multimodal story loud. The formal vision catalog entry is still gated. The path we verified is packs → modlens / dsh-vision-toolkit / dsh-vision-router (and friends), measured on clean profiles — not Agent Store headcount. Start at /packs/; read how we audit; browse install commands in the plugin directory.