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.

Why you need it

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.

What it does

Declares per-model reasoning levels: off / minimal / low / medium / high / xhigh.
Writes a reasoningEfforts map into ~/.dsh/settings.yaml, e.g.:
```
reasoningEfforts:
  off: null
  minimal: minimal
  low: low
  medium: medium
  high: high
  xhigh: xhigh
```
Each entry maps a logical level (left) to the provider-native wire value (right) the host should send. null for off means "omit the parameter entirely"; false marks a model as non-reasoning.
The host (dsh-llm-pi-ai) turns that declaration into the model picker's options and performs the actual wire-value conversion per request.
Marks image models (gpt-image-*) as non-reasoning (reasoningEfforts: false).
Adds a small "Reasoning adapter" settings section that explains the mapping. (This section is currently informational only — see Limitations.)

Install

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 }.
every other non-image model ID — including gpt-*, codex-*, claude-*, qwen-*, deepseek-*, moonshot-* and arbitrary custom gateway IDs — → the full off…xhigh map.
Existing reasoningEfforts declarations are left untouched (the helper only fills in models that have none).

Remove

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.

Limitations

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.
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.