dsh-more-models-thinking-level
在 DeepSeek Harness 中为 GPT、Gemini 和兼容 OpenAI 的提供商声明每个模型的推理工作量
插件会安装到这里；不确定时保持 web。
npx -y @deepseek-ai/dsh plugin --profile web add github:Henta111/dsh-more-models-thinking-level#f4ba5fe8b5ca25f7a1af02dfeb14239159e1988dMore Models Thinking Level 以 dsh-more-models-thinking-level 发布，当前版本为 0.1.1。Plugin Hub 会校验它的 manifest，并保存精确安装来源，便于复现安装结果。
An installable and removable DSH (DeepSeek Harness) bundle that exposes per-model reasoning (thinking) levels for GPT, Codex, Gemini and OpenAI-compatible models, so that models served through a custom gateway or relay can select a reasoning intensity that matches what the model actually supports.
The plugin does not patch Harness core files. Provider-native parameter conversion stays owned by the host's dsh-llm-pi-ai; this bundle only declares the model capabilities that let the host surface the reasoning-level picker in the first place.
DSH only shows a reasoning-level control for a model if that model carries a reasoning / reasoningEfforts capability declaration. Models in the bundled catalog — official OpenAI GPT models, Gemini, and the like — already declare it, so you can pick a level out of the box when you use an official provider.
The problem is custom gateways and relays. A relay (pptoken, one-api, new-api, LiteLLM, a self-hosted proxy, …) exposes whatever model IDs its backend offers. Many of those IDs — vendor-specific versions, -openai-compact style aliases, date-stamped snapshots, codex-* tool models, and so on — are missing from DSH's bundled catalog. For any model the catalog does not describe, DSH defaults to "no reasoning capability", so the picker offers no reasoning level at all.
This plugin fills exactly that gap: it writes the missing reasoningEfforts declaration into your model settings, so those custom-gateway models become selectable too.
Note: if you only use official providers with standard catalog IDs (e.g.
gpt-5.4,o3) via DSH's built-in provider route, the reasoning levels already exist and this plugin is unnecessary. Its value is confined to models that fall outside the bundled catalog — which is what most relays expose.
off / minimal / low / medium / high / xhigh.reasoningEfforts map into ~/.dsh/settings.yaml, e.g.:
reasoningEfforts:
off: null
minimal: minimal
low: low
medium: medium
high: high
xhigh: xhigh
null for off means "omit the parameter entirely"; false marks a model as non-reasoning.dsh-llm-pi-ai) turns that declaration into the model picker's options and performs the actual wire-value conversion per request.gpt-image-*) as non-reasoning (reasoningEfforts: false).From npm once published:
dsh plugin add dsh-more-models-thinking-level
Or directly from this repository:
dsh plugin add https://github.com/Henta111/dsh-more-models-thinking-level
Installing from npm registers the bundle but does not automatically edit your model settings. Run the included helper once for the target profile, then restart DSH:
powershell -ExecutionPolicy Bypass -File "$HOME\.dsh\profiles\desktop\node_modules\dsh-more-models-thinking-level\enable-capabilities.ps1"
The helper does the following (it creates a timestamped backup first):
gpt-image-* → reasoningEfforts: false (non-reasoning).gemini-* → reasoningEfforts: { off: null, minimal, low, medium, high }.gpt-*, codex-*, claude-*, qwen-*, deepseek-*, moonshot-* and arbitrary custom gateway IDs — → the full off…xhigh map.reasoningEfforts declarations are left untouched (the helper only fills in models that have none).dsh plugin remove dsh-more-models-thinking-level
Then clean up the declarations the helper added (a disable-capabilities.ps1 helper is included) if you want your settings file restored. See Limitations for why this cleanup is manual.
Please read these before installing — some materially affect whether you get the result you expect.
Not listed in the plugin marketplace. The marketplace registry is generated from awesome-dsh-plugin; because the corresponding PR has not been merged/reviewed yet, this plugin is not discoverable via dsh plugin search. Install it by name (npm) or by repository URL, and confirm it is registered in your profile before use.
The helper is not invoked automatically. Installing/enabling the plugin does not run enable-capabilities.ps1. You must run it manually once per profile, then restart DSH. Until you do, the plugin only adds the settings section and logs — your models will not gain reasoning levels.
The host entry is mostly a no-op. lib/index.js's apply only logs reasoning-adapter: enabled. All real capability comes from the declaration the helper writes into settings.yaml, not from plugin runtime code. Treat the "plugin" as an installer + documenter around a settings edit, not as a runtime adapter.
It persists edits to settings.yaml. The helper rewrites your settings file in place (after a backup), so it is not a stateless runtime override. If you later change providers, switch protocols, or remove the plugin, the injected reasoningEfforts and the default reasoning: medium remain until you clean them up. Ownership of these fields is a manual concern.
Model capability is guessed from the ID. The helper identifies models with a regex (exclude image models and Gemini, treat everything else as GPT-style). It cannot know whether a given model actually supports a level. If a relay exposes non-reasoning models (e.g. embeddings, vision-only, or plain chat models) under arbitrary IDs, they will receive a reasoning declaration too, and a strict gateway may reject the extra reasoning parameter.
Support ultimately depends on the gateway. A declaration only makes the level selectable. Whether the relay actually accepts the reasoning / reasoning_effort parameter — and the specific wire value — is decided by the gateway. Some strict gateways validate requests against a fixed schema and reject fields they do not recognize. The plugin cannot guarantee a chosen level actually takes effect on a given relay.
Windows PowerShell + desktop profile only. The helpers use Windows PowerShell syntax and path conventions, and default to the desktop profile. Non-Windows hosts or other profile names require manual adaptation.
This plugin only declares model capability; the actual request is sent by the host (dsh-llm-pi-ai) using the route's api. When a route uses openai-responses, DSH replays prior assistant messages as different input items, and the message items it builds carry a status field (e.g. status: "completed"), and reasoning items can carry status too.
Some relays validate the Responses API request against a fixed schema and reject such fields as unknown parameters. A typical error looks like:
invalid_request_error: [ObjectParam] [input[148].status] [unknown_parameter] Unknown parameter: 'input[148].status'
If you hit this, it is a host/route-vs-gateway compatibility issue, not the plugin's fault. Options, in order of usefulness:
api to openai-completions (chat/completions) if the relay supports /v1/chat/completions; that request shape does not carry these item-level fields. Note the reasoning wire format changes, so re-confirm the levels still map correctly.status on Responses input items has been fixed upstream, e.g. in LiteLLM).enable-capabilities.ps1 for the target profile, then restart DSH.invalid_request_error ... input[N].status. See Gateway compatibility above — it is a route/gateway field-compatibility issue, not the level mapping.reasoningEfforts declaration. See "Why you need it".medium; how do I change it? Edit the provider's reasoning: field in ~/.dsh/settings.yaml (the helper sets it to medium, and it persists even after uninstall).reasoningEfforts / reasoning: medium are still there. The helper edits settings.yaml in place. Run disable-capabilities.ps1 to remove the declarations the helper added.gpt-5.4, o3); those already declare reasoning.The level picker is driven entirely by the model's reasoningEfforts. You can edit ~/.dsh/settings.yaml directly, e.g.:
reasoningEfforts:
off: null
low: "low"
medium: "medium"
high: "high"
Each key is the logical level the picker shows; each value is the wire value the host sends for that level. null for off means "omit the reasoning parameter", false disables reasoning for that model. A model with an empty/absent reasoningEfforts keeps the host's default (which for a custom-gateway model is "no reasoning"), so if you add a new relay model by hand, give it a reasoningEfforts map as above or it will not be selectable.
MIT
The settings section is informational, not an editor. The client section explains the mapping and points at the model settings page; it has no provider/model visual editor. Fine-grained per-provider or per-model control is done by editing settings.yaml yourself.
Unfinished marketplace-readiness work. Configurable profile names, migrating capability config to the DSH Settings API, automated tests for GPT/Gemini/generic models, explicit error text when a gateway refuses a parameter, and removing the dependency on an early core-runtime patch are all still open.