dsh-vision-router

dsh-vision-router

Turn vision on when you need it — eyes for text-only agents on DeepSeek Harness. Free out of the box, no key, no Python, one command.

DeepSeek keeps thinking; the built-in free vision chain and fourteen deep tools do the seeing. When an image matters, enable the composer’s “ Vision” control and use image turns like ordinary tool-calling turns — grounded, measurable, repeatable.

=22" />

Ecosystem: DSHPlugin.app · Awesome Omni DSH Plugins · dshpluginhub.ai · dsh.plus · dshplugins.ai · dsh-market

English · 中文

QQ community group: 1105463028

[!WARNING] Announcement (v2.1.7)

v2.1.7: Hardens remote/local capability boundaries, long-lived browser and persistent-cache resource ownership, DSH 0.1.5 connection/catalog compatibility, property-based fuzzing, and release provenance without raising the rc.8 Host floor. What’s new →

Contents

• Why this exists
• How it compares
• Design lineage
• Acknowledgements
• Quick start
• Free vision key channels
• Highlights
• How it works
• Tools
• Configuration
• Install and lifecycle
• Troubleshooting

Why this exists

Most DSH vision plugins bridge images to DeepSeek as text descriptions — lossy, one-shot, and blind to pixels. This plugin keeps the Host-canonical image pixels on the vision model's side and DeepSeek on the reasoning side, and makes looking at an image an ordinary tool call:

• One command install. The package ships its own composition patch (dsh.bundle.patch): dsh plugin add wires the row, the admission wrapper and the attachment limits automatically — zero manual file edits. Taking over the official DeepSeek route is an optional setting (stealth mode, off by default).
• Free by default. Vision tools end with a five-model OVHcloud anonymous fallback: no account, no key, 2 requests/minute per IP per model, roughly 10 RPM in theory across independent buckets. User-provided vision models run first.
• No Python. The whole pipeline — downscale, grounding, crop, pixel diff, palette, OCR, SVG trace, cutout, HTML screenshot — runs on sharp / potrace / tesseract / system Chrome.
• Continuous multi-step image work. An image turn is a text turn that calls tools: vision_ground → vision_crop → vision_describe → vision_pixel_diff → fix → screenshot again. The agent keeps iterating until the work is done.
• DeepSeek stays the brain. Text turns are untouched in model, cost and context. The vision model is only the eyes, called on demand; answers are cached by image content.
• Transparent to the user. Uploaded images keep rendering as images in the conversation UI; the rewrite that points the model at the vision tools happens only inside the model call, never in the session log.

How it compares

One-line take: most dsh vision plugins turn images into text descriptions for DeepSeek (description bridge — lossy); this plugin hands the image turn straight to a vision model (routing bridge — pixel-level), with a built-in keyless free fallback.

[!NOTE] On DSH 0.1.2-alpha.1+, attachments remain Host-owned. Vision Router consumes the Host-persisted canonical image: clean single-frame 8-bit sRGB/sRGBA images inside the configured normalization limits can pass through byte-identically, while images that need orientation, color-space, metadata, animation, or size normalization may be re-encoded. Pixel tools therefore promise the Host-canonical raster, not preservation of the uploader's original encoded bytes.

	Manual model switching	MCP vision bridge	dsh-vision-router
Image pixels	✅ available (when switched)	❌ text description only	✅ Host-canonical raster, on the image turn
Automatic	❌	✅	✅
Daily model untouched	❌ (whole session swapped)	✅	✅
Provider failure recovery	❌	❌	✅ fallback chains
Reusable structured queries	—	partial	✅ JSON mode + caching
Free out-of-the-box	❌	❌	✅ built-in keyless endpoint
Fits dsh composition	—	external server	✅ one plugin row

Difference from existing dsh community projects (all excellent, each with its own focus; descriptions reflect their READMEs as of 2026-08):

Project	Approach	What this plugin adds
dsh-vision-sidecar	Pre-describes images with an external VLM; the description joins the session as a message to DeepSeek; LLM7.io anonymous endpoint by default (OVHcloud listed as a no-key alternative)	Description bridge; this plugin adds image routing, with vision_describe covering descriptions on demand
dsh-vision-proxy	Wraps a provider route and transcribes images into text in the request stream	Transcription bridge; this plugin wraps no provider — it rewrites routing through agent/request waterfalls
dsh-vision-provider	Registers DeepSeek + Vision combined routes: images are described by the chosen vision model before reaching DeepSeek	Two-model bridge idea; this plugin adds automatic routing, fallback chains and tools on top
modlens	The first dsh vision plugin; reuses local Claude Code/Codex/OpenCode/Pi logins as vision engines	Engine-reuse idea; this plugin ships its own provider chain and depends on no other local CLI
dsh-vision-toolkit	Ten intent-aware visual tools (Q&A/OCR/pixel verification/UI restoration), called explicitly on demand	Broader tool set; this plugin adds whole-turn auto-routing and a keyless free fallback
dsh-tool-vision	An inspect_image tool plus an agent/pre-step waterfall bridge (pasted images become tool hints before entering the log)	Similar waterfall bridge; this plugin adds turn routing, fallback chains, caching and the free endpoint

Design lineage

The deep-vision tool layer and UI-restoration workflow in this project were informed by Anionex/agent-vision-toolkit and its native DSH implementation Anionex/dsh-vision-toolkit. In particular, this project drew on their intent-driven tool selection, progressive tool exposure, pixel-diff verification loop, and parts of the visual-tool decomposition and naming, including long-screenshot OCR, foreground extraction, and HTML screenshot tooling.

All code in dsh-vision-router is independently implemented. On top of those referenced design ideas, this project independently developed its turn-level/tools-first vision routing, DSH admission/wrapper integration, multi-backend provider and failure fallback chains, built-in free vision chain, attachment/image-memory handling, caching, and related runtime resilience mechanisms.

We appreciate Anionex's prior work and the broader DSH community. Clear attribution and independent iteration can coexist; both help keep the DSH ecosystem open, collaborative, and healthy.

Acknowledgements

This project borrows ideas from all of the above — especially the keyless free-endpoint exploration (LLM7.io and OVHcloud anonymous tiers) by dsh-vision-sidecar. Thanks to the authors of dsh-vision-proxy, dsh-vision-provider, modlens, dsh-vision-toolkit, and dsh-tool-vision.

Quick start

1. Install the plugin

For normal npm/npx installs, installation is a single command:

npx @deepseek-ai/dsh plugin --profile web add dsh-vision-router

[!WARNING] If this profile already loads community plugins manually through cordis.patch.yml, do not mix that legacy setup with dsh plugin add / dsh plugin list: current DSH CLI behavior can also append bundle-patch dependencies to dsh.profile.bundles, causing those plugins to register twice. Migrate the existing manual plugin rows to bundle-managed loading first, or keep using the manual installation path. See deepseek-harness discussion #2889.

[!NOTE] Third-party dsh-web-plugin-manager / dshpm v0.4.2+ is also compatible: its quality gate now correctly allows @deepseek-ai/schemastery as a runtime dependency. The official DSH CLI above remains the recommended install path.

If you run DeepSeek Harness from a source checkout with pnpm, use the workspace script instead — dsh is not necessarily on your shell PATH:

cd deepseek-harness
pnpm dsh plugin --profile web add dsh-vision-router

If you already installed the DSH CLI globally and dsh is on PATH, the shorter dsh ... form works too. After installation, start or reload DSH Web as you normally do.

[!NOTE] If you install the plugin into a Web process that was already running long-term, let that DSH Web process reload once so the plugin bundle itself is discovered. After the plugin is loaded, adding/removing models or changing wrapper scope hot-updates without further DSH restarts.

2. Pick your normal model, then enable “ Vision” when needed

The stock model selector in the lower-right corner still chooses your brain/conversation model — DeepSeek, Qwen, or any other ordinary route. Vision Router’s generated “+ Auto Vision” wrappers remain real Host routes for image admission, but are hidden from the stock picker and /model when ownership can be established safely.

When you need image input, explicitly click “ Vision” beside the composer:

• Vision: the ordinary model is active and Vision is off;
• Vision ✓: Vision Router has switched the session to that model’s internal vision wrapper;
• the mode persists across sends and does not auto-reset;
• turning it off switches back to the same ordinary model; choosing a different ordinary model turns Vision off;
• changing only reasoning effort keeps Vision on.

[!IMPORTANT] Pasting or uploading an image does not enable Vision automatically. Before sending an image, make sure the control shows Vision ✓.

The real wrapper route is still present underneath to satisfy DSH image admission. Hiding is presentation-only and fails open: if the browser cannot confidently prove a route belongs to Vision Router, that route remains visible rather than risking hiding a third-party provider.

3. Paste or upload the image

With “ Vision” enabled, paste or upload an image normally. By default the complete vision tool schema is stable from session start, so the agent can immediately use vision_describe, vision_ground, vision_crop, and the rest across multiple steps when needed.

If the session already contains images, DSH may reject switching from a vision wrapper back to a text-only route. Vision Router does not bypass that Host rule: it shows a transient error using the same interaction style as the stock model selector, keeps the real current model unchanged, and leaves Vision ✓ reflecting the actual state so the session stays usable.

The built-in anonymous OVH vision fallback is already configured, so normal image use needs no signup or API key. The lower-right chat picker selects only the brain/conversation model; vision backends do not belong there. Advanced options live under Settings → Vision Router: each vision-backend row may se