dsh-vision-3090-fix
用于 DeepSeek Harness 的本地反向代理插件，将每个请求的图片数量限制为 1，适用于拒绝包含多张图片提示的自托管 vLLM 后端
插件会安装到这里；不确定时保持 web。
npx -y @deepseek-ai/dsh plugin --profile web add github:pureexe/dsh-vision-3090-fix#cd056e5950ea3eaebea01e001320f7a43a4d980fVision 3090 Fix 以 dsh-vision-3090-fix 发布，当前版本为 0.2.0。Plugin Hub 会校验它的 manifest，并保存精确安装来源，便于复现安装结果。
A DeepSeek Harness (dsh) plugin that fixes:
400: {"message":"At most 1 image(s) may be provided in one prompt. (parameter=image)","type":"BadRequestError","param":"image","code":400}
against a self-hosted OpenAI-compatible vision backend (e.g. syv-ai/qwen38-27b-rtx3090, a single-RTX-3090 vLLM deployment). vLLM serves these models with --limit-mm-per-prompt image=1, so any request carrying more than one image content part is rejected with a 400 — even across unrelated turns of the same conversation, and even across separate tool calls (e.g. a screenshot tool and a file-pull tool each returning one image) in the same turn.
Harness's shipped LLM adapters (dsh-llm-pi-ai, dsh-llm-deepseek) only offload images by accumulated byte size (maxRequestImageBytes / requestImageMaxBytes). They never cap by count. So a conversation where you attach one small image, get a reply, and then attach a second small image sends both images in the next request — comfortably under any byte budget, but two images, which this backend refuses outright.
It's a small local HTTP reverse proxy, started as an ordinary Cordis plugin effect (see docs/user/develop/basic/index.md#automatic-cleanup in the harness docs — ctx.effect() starts and stops it with the plugin's lifecycle). You put it in front of your existing provider's baseURL; everything else about how you already talk to the backend — dsh-llm-pi-ai's pure provider, its model list, its credential — stays exactly as configured.
For each forwarded request, the proxy:
messages array (standard OpenAI wire format).image_url content part across the whole array, including ones nested in tool-role messages (a returned screenshot, a pulled file).maxImagesPerRequest (default 1) with a stable text placeholder, in place.Authorization, untouched — the proxy never needs or sees your API key's meaning, just passes it through) and the rewritten body — to the real backend.A request already at or under the cap is forwarded completely unmodified.
dsh plugin --profile web add /path/to/dsh-vision-3090-fix
(or dsh plugin --profile web add github:pureexe/dsh-vision-3090-fix once pushed).
Configure it in your profile's cordis.patch.yml (e.g. ~/.dsh/profiles/web/cordis.patch.yml):
- id: vision-3090-fix
name: dsh-vision-3090-fix
config:
upstreamOrigin: http://10.204.100.243:1234 # scheme+host+port only, no path
listenHost: 127.0.0.1
listenPort: 8931
maxImagesPerRequest: 1 # match your server's --limit-mm-per-prompt
models: [qwen3.8-27b] # optional; omit to cap every model
baseURL in dsh-llm-pi-ai is set once per provider, not per model — every model listed under that one provider shares it. So if pure serves three models and you point its baseURL at this proxy, all three now go through the proxy, even though only one of them needs the cap. models (optional; empty means "cap everything") scopes the cap itself, not the routing: out-of-scope requests still take the extra local hop through the proxy, but are forwarded completely untouched — same bytes in, same bytes out, no behavior change from talking to the backend directly.
Then point your existing provider config at the proxy instead of the real backend — the only line that changes. For a dsh-llm-pi-ai route in settings.yaml:
llm-pi-ai:
providers:
pure:
displayName: pure
apiKeyEnv: PURE_API_KEY
api: openai-completions
baseURL: http://127.0.0.1:8931/v1 # was: http://10.204.100.243:1234/v1
models:
- id: qwen3.8-27b
# ...unchanged
Everything else — credentials, model list, agent-default-model, the Web UI's Models settings page — keeps working exactly as it did before, because dsh-llm-pi-ai still owns the pure route and is still the thing editing/reading that section. The proxy is invisible to it beyond the URL.
| Field | Default | Meaning |
|---|---|---|
upstreamOrigin | (required) | Scheme+host+port of the real backend, e.g. http://10.204.100.243:1234 — no path |
listenHost | 127.0.0.1 | Host the proxy listens on |
listenPort | (required) | Port the proxy listens on; point your provider's baseURL at http://<listenHost>:<listenPort>/v1 |
maxImagesPerRequest | 1 | Images kept per forwarded request; excess (oldest first) becomes placeholder text |
models | [] (every model) | Model ids the cap applies to (matched against the request's model field); every other model is forwarded byte-for-byte untouched |
verbose | false | Log the startup banner and each request that gets capped. Actual proxy errors (e.g. the upstream is unreachable) are always logged regardless — they aren't routine noise. |
npm install
npm test # unit + local end-to-end tests (fake upstream, no network)
To also run the end-to-end test against the real backend:
VISION_3090_FIX_LIVE_UPSTREAM=http://10.204.100.243:1234 \
VISION_3090_FIX_LIVE_API_KEY=<your-api-key> \
VISION_3090_FIX_LIVE_MODEL=qwen3.8-27b \
VISION_3090_FIX_LIVE_IMAGE=/home/pakkapon/a.png \
node --test test/live.test.js
That test starts a real instance of the proxy, first proves an uncapped two-image conversation gets the reported 400 from the real backend, then proves the same conversation succeeds once proxied through a 1-image cap.
chat/completions-shaped JSON; a provider using a different wire shape for images (not OpenAI's image_url content part) won't be recognized.MIT