DSH Vision Toolkit: image Q&A and OCR for text-only DeepSeek Harness agents
[dsh]为纯文本模型设计更强大的视觉工具箱：一行安装使用、粘贴图片直接识别、多张图片问答、截图到前端UI 还原等｜DeepSeek Harness-native integration for agent-vision-toolkit: image Q&A, long-screenshot OCR, UI restoration, grounding, pixel diff, Artifacts, and Web UI.
At a glance
- What is it?
- A DeepSeek Harness plugin that gives text-only models eyes through an external vision provider, with a bundled Skill that decides when to inspect, ground, OCR or diff. It installs with one command, but the vision model is not included.
- Who is it for?
- Adopt it if you already run DeepSeek Harness in Web or Headless profiles and need paste-to-ask image handling, long-screenshot OCR or screenshot-to-UI work inside the same session, and you are willing to configure a vision provider. Do not adopt it if you want a self-contained local vision model, if you are not on Node ^22.19.0 or >=24.0.0, or if you cannot send screenshots to a third-party API.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 2 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap this fills for text-only agents in DeepSeek Harness
A text-only model in DeepSeek Harness can read a file path but cannot see what is at that path. The usual workaround is to leave the harness, describe the image by hand, and paste a summary back into the conversation. DSH Vision Toolkit removes that round trip by routing image input through a separately configured vision provider and exposing the result as tools the agent can call mid-task.
The README frames the target user narrowly: people running DeepSeek Harness who want image Q&A, long-screenshot OCR, UI restoration and GUI visual tasks without changing their model or their workflow. The project describes itself as the first comprehensive vision-tool plugin in the DeepSeek Harness ecosystem, initiated before internal beta and built during the beta with reference to the upstream agent-vision-toolkit repository. That upstream project is a separate codebase; this one is the native integration layer.
The distinction matters. A generic image-captioning wrapper answers "what is in this picture". The README is explicit that the model here is meant to extract evidence around the current task, such as where an error appears or where a button sits. That is a different prompt contract, and it is why the project ships a Skill rather than only a set of functions.
Two layers: the visual tools and the DeepSeek Harness integration
The repository describes the project as having two layers. The first is the visual tools plus a Skill: the agent learns when to inspect, ground, OCR, crop, trace or compare pixels. The second is the native integration, where those capabilities live inside Profiles, sessions, Settings, Artifacts and the Web UI.
The Skill is the part that is easy to underestimate. Without it, a model with vision tools tends to call the wrong one, or call one and then fail to check the answer. The README says the bundled Skill tells the agent what to look at for different visual tasks, which tool to choose, how to proceed, and how to verify the result. The build script list in package.json includes a verify-skill step, which suggests the Skill is treated as a build artifact with its own validation rather than loose documentation.
The integration layer is what makes the tools usable from inside a session. According to the README, pasting an image in DSH Web switches the text-only model to its (Vision Toolkit) variant automatically, keeping native thumbnails, session history and workspace paths intact, and Web can preview artifacts. A 2026-08-19 update changed this to transparent routing by default: the model selector keeps one entry per model under its original name, and image input (paste, history, read_image) works without manually switching variants. Disabling "Transparent variant routing" in advanced settings restores the explicit entries. That setting is the first thing to check if the automatic switch does not happen for you.
Installing the plugin and asking your first image question
The README gives a single install command for the Web profile. It is run through the dsh CLI, which must already be present, and the package name is scoped.
dsh plugin --profile web add @anionex/dsh-vision-toolkitAfter installation, the README says to configure a vision provider in Settings, under a section named Vision Toolkit. Until a provider is configured, the tools have nothing to call. The project does not ship a model; it ships the plumbing and the prompts. The README links a screenshot-based guide, added on 2026-08-20, for getting an API key through the Inferera entry and configuring the Gemini 3.7 Flash vision model, and it notes that Settings links directly to this guide.
Once a provider is set, the intended first use is to paste an image into the DSH Web conversation and ask a question about it. The README's own example of the shape of that question is task-directed rather than descriptive: where is the error, or where is the button. The model is expected to return evidence tied to that question, not a caption.
The package declares its runtime requirements in package.json: Node ^22.19.0 or >=24.0.0, and pnpm@11.7.0 as the package manager. The build scripts reference a python-bootstrap step, and the 2026-08-16 release note mentions first-time isolated-runtime setup for Python, including added Microsoft Store Python support on Windows. If you are installing on Windows and the isolated runtime setup fails, that release note is the relevant one to read.
Where the toolkit is the wrong tool
The most obvious limitation is the one the README states by omission: this plugin does not include a vision model. Every image you send goes to whichever provider you configure in Settings. If your screenshots contain credentials, customer data or unreleased interfaces, you are sending them to a third party, and that decision belongs to whoever owns the data, not to the plugin.
There is a second, subtler failure mode. The 2026-08-17 release note records a fix for Qwen and Gemini bounding-box coordinate order. That tells you something about the tool surface: grounding output depends on the provider returning coordinates in the order the toolkit expects, and providers differ. If you configure a provider that the project has not exercised, expect to verify coordinate handling yourself before trusting a crop or a click target.
Finally, this is a DeepSeek Harness plugin. It is not a general-purpose computer vision library, not a standalone CLI you can pipe screenshots into from a shell script, and not useful to anyone who is not running DeepSeek Harness. The installation path is a dsh plugin command against a profile. If your agent framework is something else, the upstream agent-vision-toolkit repository is the thing to look at instead, and even that assumes an agent that can call tools.
How it compares with the upstream agent-vision-toolkit
The honest alternative is the project's own upstream: Anionex/agent-vision-toolkit. The README describes the relationship plainly. The upstream gives an agent more than image captions: it can read, locate, crop, trace, rebuild and verify visual work. DSH Vision Toolkit is its native DeepSeek Harness integration, bringing that workflow into Web and Headless Profiles.
So the difference is not capability, it is placement. Choosing upstream means you assemble the tool wiring yourself and decide how images enter the conversation. Choosing this plugin means the wiring is done for you: Profiles, sessions, Settings, Artifacts and the Web UI already know about the tools, and pasting an image in Web routes it automatically. The cost of that convenience is a dependency on DeepSeek Harness and on the plugin's release cadence, which is fast. Three releases appear in the recent list between 2026-08-31 and 2026-09-10 alone, at v0.1.40, v0.1.43 and v0.1.44, and package.json declares 0.1.45. A fast cadence in the 0.1.x range means the surface is still moving.
If you are outside DeepSeek Harness and want the same methodology, upstream is the correct starting point. If you are inside it, the plugin is the shorter path and the one that keeps artifacts previewable in the Web UI.
Maintenance, licence and what upgrading costs you
The repository is not archived, and the last push was on 2026-09-14. That is recent, and the release history backs it up: v0.1.44 on 2026-09-10, v0.1.43 on 2026-09-08, v0.1.40 on 2026-08-31. The recent updates section reads like a changelog of behavioural changes rather than documentation edits, including the 2026-08-19 switch to transparent variant routing and the 2026-08-17 default model change to Gemini 3.7 Flash.
That cadence is the upgrade cost. A default model change and a routing behaviour change in the same month means an upgrade can alter what your agent does without you touching configuration. The transparent routing change in particular has a user-visible escape hatch, the "Transparent variant routing" toggle under advanced settings, which is worth knowing about before you upgrade rather than after.
The licence is MIT, declared in package.json and shown as a badge in the README. MIT is permissive: it allows commercial use and modification, and it comes with no warranty. That is a statement about the licence text, not advice about your situation; if you redistribute the plugin or bundle it into a product, read LICENSE and the dependency licences in pnpm-lock.yaml yourself. The repository also carries SECURITY.md and CODE_OF_CONDUCT.md, which tells you where to send a vulnerability report rather than leaving you to guess.
Editorial conclusion
Adopt it if you already run DeepSeek Harness in Web or Headless profiles and need paste-to-ask image handling, long-screenshot OCR or screenshot-to-UI work inside the same session, and you are willing to configure a vision provider. Do not adopt it if you want a self-contained local vision model, if you are not on Node ^22.19.0 or >=24.0.0, or if you cannot send screenshots to a third-party API. Before committing, verify three things: that your chosen provider returns bounding boxes in the coordinate order the toolkit expects, that the Python runtime bootstrap succeeds on your machine (Windows users on Microsoft Store Python should check the 2026-08-16 fix), and whether you need to disable transparent variant routing in advanced settings to get the explicit (Vision Toolkit) model entries back.
Frequently asked questions
How do I install DSH Vision Toolkit?
The README gives one command: dsh plugin --profile web add @anionex/dsh-vision-toolkit. After that, configure a vision provider under Settings, in the Vision Toolkit section, before the tools can do anything.
Does DSH Vision Toolkit include a vision model?
No. The README describes it as an integration that routes image input to a provider you configure in Settings. The 2026-08-20 update added a guide for getting an API key and configuring the Gemini 3.7 Flash vision model, and Settings links to that guide.
Which Node version does DSH Vision Toolkit need?
The engines field in package.json declares Node ^22.19.0 or >=24.0.0, and the package manager is pnpm@11.7.0. The build scripts also run a python-bootstrap step for the isolated runtime.
Community notes