All plugins

DSH / BUNDLE / CLIENT-UI

dsh-more-models-thinking-level

v0.1.1Henta111 / dsh-more-models-thinking-levelf4ba5fe8b5

InstallableBundlesUI & client pluginsCommunity · Topic auto-analysisWeb UI

Overview

dsh-more-models-thinking-level

Per-model reasoning effort declarations for GPT, Gemini and OpenAI-compatible providers in DeepSeek Harness

README / EN

Package documentation

Registry summary

Per-model reasoning effort declarations for GPT, Gemini and OpenAI-compatible providers in DeepSeek Harness

dsh.pub verifies the pinned bundle contract, runtime facts, and distribution semantics. The complete README remains in the source repository.

Read the full README on GitHub

LIMITATIONS

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