dsh-vision-proxy

A host plugin for DeepSeek Harness that gives a text-only model eyes.

The harness rejects image uploads for models without the image modality, and a text-only model cannot read an image anyway. This plugin bridges the gap by delegating image understanding to a second, vision-capable model on any provider the harness already routes:

• Proxy provider — registers a vision-proxy route with one synthetic model (-vision) that advertises image input. Select it in the model picker and attached images work normally: each image is described by the vision model, the description is injected into the request as text, and the request is forwarded to the real main model.
• vision tool — the model can also call it directly with a local image path and an optional question, for images that never entered the conversation.

The main model and the vision model are configured independently. Any provider works in either role — the plugin only needs llm to route it, exactly like your other models.

Install

The package is a plain Cordis plugin with no build step. Two ways to mount it:

From npm or a clone — install the package into your profile and add a loader row:

cd ~/.dsh/profiles/web
npm i dsh-vision-proxy        # or: npm i 

In cordis.patch.yml:

- insert:
    - id: vision-proxy
      name: 'dsh-vision-proxy'

Local development — junction the repo into the profile's node_modules and add the same row:

New-Item -ItemType Junction -Path "$HOME\.dsh\profiles\web\node_modules\dsh-vision-proxy" -Target "C:\path\to\vision-proxy"

Node resolves the junction's real path, so dependency resolution starts at the repo location. If your profile keeps its @deepseek-ai packages hoisted one level up (~/.dsh/profiles/node_modules, the pnpm layout), junction that directory into the repo's parent node_modules as well:

New-Item -ItemType Junction -Path "C:\path\to\vision-proxy\..\node_modules\@deepseek-ai" -Target "$HOME\.dsh\profiles\node_modules\@deepseek-ai"

An npm-installed copy (npm i ) does not need this — the package then lives inside the profile tree where the hoisted packages resolve naturally.

Restart the harness. The picker gains a provider with one entry per text-only model the harness can route ().