dsh-ThirdApi-ThinkingMode

api_thinking is a community-maintained DeepSeek Harness (DSH) plugin. It is not a DeepSeek AI product.

The problem it solves

DSH's built-in model catalogue does not contain your third-party APIs. To get them into the model picker at all, you declare an llm-pi-ai route by hand and list its models: yourself.

But a hand-written models: list replaces the installed catalogue outright. Those models are neither in the catalogue nor declare reasoningEfforts, so dsh-llm-pi-ai treats them as non-reasoning and the composer offers no thinking levels.

Writing the levels into YAML fixes that once — and goes stale immediately: nobody adds them when the gateway ships a new model, and nobody updates them when upstream changes what it supports.

Yet an OpenAI-compatible gateway usually already publishes that capability in its own model listing. This plugin reads it and writes the result back into your configuration, so you stop maintaining that YAML by hand.

Features

• Automatic level sync — requests each route's model listing and writes the levels the endpoint publishes into the matching model's reasoningEfforts.
• New APIs just work — add a route, or add models to an existing one; no plugin change, no restart.
• Never invents capability — an endpoint that says nothing about reasoning is left exactly as it is; hand-written levels are never erased.
• Owns exactly one field — it owns reasoningEfforts and nothing else; comments, !!js expressions and every other field stay as they were.
• Idempotent — a sweep that finds nothing to change writes no file at all.
• Self-diagnosing — every load and every sweep records a status document, so there is always something to read when it misbehaves.

Screenshots

Once installed, the model picker offers the thinking levels a model actually supports.

Install

Requires a working DeepSeek Harness installation. The examples use the desktop profile — substitute your own profile name.

From the plugin page

Open Settings → Plugins in the DSH web UI, search for dsh-api-thinking and install it. An agent can also call the plugin manager's install_bundle directly.

From the command line

dsh plugin --profile desktop add dsh-api-thinking

Restart DSH and refresh the page afterwards.

Let an agent do it

Paste this to an agent that can run terminal commands and is connected to your DSH:

Install dsh-api-thinking into my DSH profile, confirm it is active, and tell me how to reload.

Uninstall

Switch it off or uninstall it from the plugin page, or remove the dsh-api-thinking dependency from that profile's package.json and delete it from the dsh.profile.bundles array.

Usage

It works as soon as it is installed — there is no switch to turn on. The plugin walks every route under the llm-pi-ai row:

What you want	How
Get thinking levels on a model	Configure the route and its models in Settings → Models and give it a moment
Add a new API	Add it in the model page; the levels follow on their own
Narrow the scope	Set routes to the route names you care about; the default covers every OpenAI-compatible route
Change the sweep cadence	Set intervalMs; 0 means "sweep once after load, then stop"
Find out why nothing happened	Read the status document — see Troubleshooting

Rules

A model's capability comes from the first matching field in the endpoint's model listing:

Purpose	Fields, in priority order
Selectable levels	reasoning_supported_efforts → supported_efforts → reasoning_efforts
Whether thinking can be turned off	can_disable_thinking → reasoning_can_disable
Whether it reasons at all	supports_reasoning → reasoning
A pinned effort	reasoning_effort → fixed_effort → effort

What gets written:

The endpoint says	Written reasoningEfforts
A selectable set	{ low: low, high: high, ... }, filtered to the levels DSH can name (off / minimal / low / medium / high / xhigh / max), in escalation order
No set, but one pinned effort	That single level — the picker shows what the model actually runs at (selecting it is a no-op). Turn off with fixedEffortAsLevel: false
Explicit supports_reasoning: false	false
It reasons, but publishes neither a set nor a pinned effort	The key is removed (writing false would claim it does not reason)
Nothing at all about reasoning	Left untouched
The model is not in the listing	Left untouched

The last two are deliberate safety design: LiteLLM, vLLM and most self-hosted gateways publish no capability data, and treating that silence as "no levels" would erase hand-written configuration. The plugin only ever acts on what the endpoint actually states.

includeOff defaults to off. When no level is selected, the pi-ai adapter sends the mapped off value as the default — so adding off to a model that allows disabling thinking would silently turn "provider default" into "no thinking". It has to be enabled explicitly.

Configuration

- insert:
    - id: api-thinking
      name: dsh-api-thinking
      config:
        entryId: llm-pi-ai
        routes: []
        intervalMs: 120000
        startDelayMs: 3000
        timeoutMs: 15000
        includeOff: false
        fixedEffortAsLevel: true
        log: true
        statusFile: ''

Option	Default	Meaning
entryId	llm-pi-ai	The profile row to read and write
routes	[]	Route names to manage; [] means every OpenAI-compatible route
intervalMs	120000	Re-sweep interval in milliseconds; 0 sweeps once after load
startDelayMs	3000	Delay before the first sweep, to let the profile finish loading
timeoutMs	15000	Per-endpoint model-listing timeout
includeOff	false	Expose off as a selectable level (see the caveat above)
fixedEffortAsLevel	true	Show a pinned effort as the single level
log	true	Log every change and every skipped route
statusFile	''	Status document path; '' means $DSH_HOME/api-thinking.status.json, false disables it

Overriding the bundle row: an override in your profile patch must repeat name: dsh-api-thinking word for word, or applyEntryPatches skips it silently.

When it runs

Trigger	When	What it covers
start	startDelayMs after load (3s by default)	Full calibration on boot or reload
config-change	After the profile patch changes (via the HMR config watcher, 2s debounce)	APIs, routes and models you just added or edited
interval	Every intervalMs (120s by default)	Backstop for upstream model and capability changes

Every sweep re-reads the row's providers from the composed profile layers rather than from the snapshot the plugin was instantiated with — which is what makes a route you just saved visible immediately.

Troubleshooting: why nothing happened

The host logger is not reliably reachable from a plugin, so every load and sweep writes its result to a status document (by default $DSH_HOME/api-thinking.status.json):

{
  "phase": "sweep", "reason": "interval", "wrote": true, "via": "patch-file", "error": null,
  "routes": [{ "route": "my-gateway", "models": 20, "listed": 51,
               "changes": [{ "id": "example-model", "to": { "low": "low", "high": "high" } }],
               "dropped": [], "error": null }]
}

Read these first:

Field	Meaning
phase	Current stage (apply / sweep)
error	Failure reason, including request errors the UI never shows
listed	How many models the endpoint returned
models	How many the route has configured
changes	Which models this sweep planned to change
wrote / via	Whether it wrote, and through which channel

A non-empty listed with an empty changes usually means the endpoint publishes no reasoning capability — see Rules.

Write channels

The plugin prefers the official channel and only falls back when it has to:

Channel	When	What
config-editor	Normal case	ctx.configEditor.edit() — the official path, with file locking, schema validation and Loader reconciliation
patch-file	When the above answers HMR transactions cannot be nested	Edits the profile patch directly; the same config watcher recomposes it

The fallback is unrelated to how the plugin was installed: a hot-reloaded plugin runs its apply() inside the very HMR transaction that replaced it, after which every write through the official channel is refused as a nested transaction. The fallback touches only the target models' reasoningEfforts (located by indentation, written to a temp file and renamed), leaving comments and every other field byte-identical.

Known limitations

• It reads the model listing as its only source of capability. An endpoint that publishes nothing about reasoning is left alone.
• Only protocols that can list models are supported: openai-completions, openai-responses, anthropic-messages.
• Models are matched by exact id; no aliases or fuzzy matching.
• The default meaning of off is constrained by the pi-ai adapter, which cannot express "selectable but not the default".
• The fallback channel does no schema validation, only structural location.
• Writing cordis.patch.yml at the same time as the settings page can in theory overwrite each other; the next sweep converges again (it is idempotent).

Feedback and contributing

Found a bug or have a suggestion? Please open an issue with your DSH version, the plugin version and reproduction steps.

npm test                              # 15 checks: pure logic, patch edits, composed config, real gateway catalogue
node tools/check_live.mjs             # live profile vs gateway, per model; drift should be 0
node tools/diff_gateway_profile.mjs   # "why is my new API missing": gateway vs profile, per model

The maintenance tools infer locations from the environment (DSH_HOME / DSH_PROFILE, or API_THINKING_PROFILE_DIR / API_THINKING_PROFILE) and read the gateway from API_THINKING_BASE_URL (optionally with API_THINKING_API_KEY) or API_THINKING_GATEWAY_CONFIG (a config.json holding { listen, api_key }).

License

MIT