Menger-8/dsh-gateway-presets

Fixes thinking-intensity selection when DeepSeek Harness is pointed at a third-party OpenAI-compatible gateway (Volcengine Ark, relays, self-hosted servers). Without it the reasoning-level picker has no option at all, and forcing the option on by hand makes every request fail with a 400 because gateways disagree about the system role (system vs developer), the reasoning-parameter format and the output-cap field — and the harness can only guess from the URL, which says nothing for a private gateway. The plugin adds a hostname-keyed "gateway dialect table" over nine compat switches (thinkingFormat, supportsReasoningEffort, supportsStore, supportsDeveloperRole, maxTokensField, requiresToolResultName, requiresAssistantAfterToolResult, requiresThinkingAsText, requiresReasoningContentOnAssistantMessages) plus per-model reasoningEfforts declarations, so installing it, mounting it and writing down your gateway makes thinking intensity selectable and correct.

Other ★ 3 updated 2026-08-14 ✅ runtime-tested
View on GitHub ↗

Install

pnpm add @menger-8/dsh-gateway-presets

README quick start: add the package with pnpm, then mount it in cordis.yml and declare your gateway under config.providers (baseURL, apiKeyEnv, models with reasoningEfforts levels such as off/high/max), then start dsh web as usual. The plugin registers its own pi-ai adapter into the harness LLM seam, so stock DeepSeek Harness works with no core patches; on builds that consume the llm-gateway-compat-presets service (the Menger-8 fork) it also provides that service. Note: a registry check on 2026-09-12 returned 404 for @menger-8/dsh-gateway-presets on registry.npmjs.org, so verify the package is published (or install from the repository) before relying on this command. The README also documents a PowerShell probe tool (tools/probe-gateway.ps1) for contributing a new gateway dialect.

Compatibility

DeepSeek Harness; the plugin ships its own adapter so no core patch is required. Volcengine Ark (*.volces.com) is the first probe-verified dialect entry. @deepseek-ai/cordis and the harness provide the runtime.

Details

Recent updates

The README frames gateways as a data problem: contributing one is "one probe run, one data entry" — run tools/probe-gateway.ps1 (the key stays in $DSH_HOME/.credentials.yaml and is never printed), keep only what the probe proves (a 400 on the developer-role request means supportsDeveloperRole: false; an accepted thinking.type answer means thinkingFormat: deepseek), then add the entry to src/builtin.ts with the evidence named in its comment and open a PR. Upstream adoption of the core preset mechanism is tracked in Discussion #564 of the deepseek-harness repository.

FAQ

Why do my gateway requests fail with a 400 about the developer role?
The gateway rejects the developer system role that the harness guessed from the URL. The plugin's dialect table sets supportsDeveloperRole: false for *.volces.com (pre-verified) and for any hostname you add under config.presets, so requests go out with the dialect the gateway actually accepts.
Does it require changes to DeepSeek Harness itself?
No. The plugin registers its own pi-ai adapter into the harness LLM seam, so stock DeepSeek Harness works as-is. On forks that consume the llm-gateway-compat-presets service it additionally provides that service.
How do I add my own gateway?
Run the bundled probe, keep only the switches the probe proves, and add one entry to src/builtin.ts naming the evidence. The README describes the three steps and asks for the probe output in the PR description.

More plugins in Other

Browse more in Other

Guides for Other plugins