dsh-thinking-effortDeepSeek Harness plugin

Configurable reasoning levels for hand-declared DSH llm-pi-ai models, with bilingual settings and subagent defaults.

Stars
23
Forks
0
License
MIT
Last commit
Sep 3, 2026

Overview

Configurable reasoning levels for hand-declared DSH llm-pi-ai models, with bilingual settings and subagent defaults.

Original README

Cached from the project repository on Sep 3, 2026. This is source content, separate from the Agents.md review above.

View source

dsh-thinking-effort

A DSH (DeepSeek Harness) plugin that adds configurable reasoning effort levels to hand-declared llm-pi-ai models and sets a default reasoning effort for subagents.

npm version npm downloads GitHub license

Compatibility boundaries: DSH Runtime compatibility covers the Settings transport only: modern DSH exposes remote.settings, while legacy DSH exposes connection.api.settings. The plugin detects the available runtime capability and keeps the legacy fallback optional, so the settings page does not require a Remote provider on older DSH builds.

Gateway Protocol compatibility is a separate layer. It reads the official llm-pi-ai.compat fields supportsDeveloperRole and maxTokensField when the DSH schema exposes them. DSH 0.1.0-rc.7 does not provide these fields; DSH 0.1.0-rc.8 and later supported ranges do. The optional dsh-llm-openai-completions transport can take over eligible custom OpenAI-compatible thinking providers when it is installed and enabled. For either gateway field, Auto unsets the user override and restores the official protocol default.

DSH 0.1.2-alpha.1 and later accept language-pack locale IDs through LocaleRuntime. This plugin registers ja and ko dynamically, so no DSH core fork is required. Older DSH builds that only expose built-in locale IDs support zh and en only.

The published runtime entries are lib/index.js (Host) and lib/client.js (Client). After changing TypeScript or locale sources, run npm run build before running DSH or packing the plugin. Current DSH does not expose a public semver metadata contract, so runtime capability detection is authoritative. An optional version is used only when explicit metadata or test input supplies it; unknown valid versions still use the detected capabilities. The plugin supports both modern remote.settings and legacy connection.api.settings.

DSH compatibility

DSH rangeGateway compatibility settings
0.1.0-rc.7Not available
0.1.0-rc.8 to <0.1.2-alpha.1Available
0.1.2-alpha.1 to <0.1.3-0Available

Why use it?

The llm-pi-ai adapter supports hand-declared third-party models, but those entries often do not declare reasoningEfforts. As a result, Composer does not show a reasoning effort selector, and gateway-specific values such as ultra cannot be mapped to DSH's standard levels.

This plugin provides the configuration layer needed to:

  • Add default off, high, and max options to models without a declaration;
  • Configure reasoning levels per model from the DSH settings page;
  • Map a DSH level such as high to a gateway value such as ultra;
  • Set a default reasoning effort for subagents while preserving explicit request values;
  • Keep existing user-defined model declarations unchanged.

The plugin is usually unnecessary when you only use built-in DSH models and their reasoning controls already work.

Identifiers

These identifiers have different responsibilities:

IdentifierPurpose
@hytime/dsh-thinking-effortnpm package, browser bundle path, loader ID, and host/client runtime ID
thinking-effortCordis composition entry ID and settings Slot ID

Features

FeatureDescription
Default levelsAdds off, high, and max without overwriting custom values
Per-model editorSelect levels and configure gateway values for both catalog/modelOverrides and models[] entries in Settings
Gateway compatibilityConfigure supportsDeveloperRole and maxTokensField globally per provider or separately per model
Gateway mappingSend ultra when the user selects DSH high
Subagent defaultApply a default effort only when a subagent request has no explicit value
Multilingual settingsIncludes Chinese, English, Japanese, and Korean dictionaries; Japanese/Korean switching uses DSH language-pack support
Version watermarkShow the installed plugin version in the bottom-right corner

Install, upgrade, and remove

Use the official DSH CLI to manage the plugin profile. A plain npm install does not register a DSH profile bundle.

bash
1# Install the latest version
2dsh plugin --profile <profile> add @hytime/dsh-thinking-effort
3
4# Install a specific version
5dsh plugin --profile <profile> add @hytime/dsh-thinking-effort@0.1.14
6
7# Upgrade
8dsh plugin --profile <profile> update @hytime/dsh-thinking-effort
9
10# Remove
11dsh plugin --profile <profile> remove @hytime/dsh-thinking-effort
12rm -f "${DSH_HOME:-$HOME/.dsh}/thinking-effort-loaded.json"

See INSTALL.md for profile discovery, migration, validation, and troubleshooting.

Quick use

  1. Open DSH Settings → Model capabilities and effort.

  2. Use the Page language selector at the top to choose 中文, English, 日本語, or 한국어. DSH uses the persisted locale first, then the browser language, then English as the fallback.

  3. Choose a subagent default from the Subagent default effort card, then click Apply.

  4. Use Quick settings to apply the official DeepSeek or generic preset to all models, or expand a provider and model for detailed configuration.

  5. Use the search field to filter models by name or ID. Model rows show text/image input capability badges, a context-window badge when declared, and a settings button for per-model editing.

  6. Select a reasoning level and enter the exact gateway value. For example:

    DSH levelGateway value
    offLeave empty to omit the parameter
    highultra
    maxmax
  7. Return to Composer and select the model to use its reasoning selector.

The settings page shows the installed version as a small watermark such as v0.1.14 in the bottom-right corner.

Gateway compatibility configuration

The provider compat block is the global default for every model under that provider. Configure provider defaults with the official DSH YAML shape:

yaml
providers:
  qwen-gateway:
    compat:
      supportsDeveloperRole: false
      maxTokensField: max_tokens
    models:
      - id: qwen-plus
      - id: qwen-thinking
        compat:
          maxTokensField: max_completion_tokens

A model-level compat overrides the provider default field-by-field. Fields not written at the model layer continue to inherit from the provider. Auto deletes the current-layer field and restores provider inheritance. For a given route/provider, any non-empty models[] together with any non-empty modelOverrides is invalid; the official schema rejects this invalid configuration, and the plugin fails closed for malformed data.

The provider area in Settings edits defaults for all models. Both catalog models and custom YAML models[] entries expose a single-model compat editor: catalog models write modelOverrides.<model>.compat, while models[] models write models[].compat. Because the Settings API does not support array-index path operations, a models[] edit writes one complete providers.<route>.models array set while preserving other models, unknown fields, and compat fields.

These compat values are control plane configuration. They do not implement or replace the gateway transport; an external transport remains responsible for network requests.

Settings page layout

The page header contains the language selector. Below it, the Subagent default effort card controls the default for requests without an explicit effort. The Quick settings controls apply a preset across models. Provider sections can be expanded or collapsed; each model row exposes input capabilities, context length, and gateway compatibility controls in its settings area. models[] saves use one complete array set rather than an array-index path operation.

English Model capabilities and effort settings page

How it works

  • Host: Scans llm-pi-ai models and modelOverrides on startup and settings changes, adding defaults only where reasoningEfforts is missing.
  • Client: Registers a settings page through the DSH Settings Remote (ctx.remote.settings) and the official DSH locale service. Chinese, English, Japanese, and Korean dictionaries are maintained separately in src/locales/zh.json, src/locales/en.json, src/locales/ja.json, and src/locales/ko.json, then generated into the client bundle before publishing.
  • Subagents: Stores the default in the llm-pi-ai user layer as subagentEffort. The agent/request waterfall only fills requests that do not already specify an effort.
  • No configured default: The plugin does not automatically choose off, high, or max; the request omits reasoning and the gateway decides its own default behavior.

Limitations

  • llm-pi-ai exposes seven standard levels: off, minimal, low, medium, high, xhigh, and max.
  • Non-off levels require a gateway value. An empty off value means that the parameter is omitted.
  • The selected subagent level must be supported by the target model, or the gateway may return UNSUPPORTED_REASONING_EFFORT.
  • off and an unset effort may both omit reasoning; whether this disables thinking depends on the gateway protocol.
  • Host changes require a DSH restart. Settings and locale changes are applied in the browser, with a refresh available when needed.

CI and release maintenance

  • Pull requests and pushes to main run the quality matrix on Node 22.19.0 and 24.x.
  • The workflow uses npm ci; maintainers must commit package-lock.json when dependencies change.
  • The ordinary CI workflow does not publish to npm. Publishing is triggered only by a v<version> tag through publish.yml.
  • Before creating a release tag, update package.json version and CHANGELOG.md files, commit those changes, and create the matching v<version> tag. The tag must point to a commit in the main history.
  • npm Trusted Publishing must be configured for repository hytime/dsh-thinking-effort and workflow publish.yml. The workflow publishes provenance through GitHub OIDC and does not require NPM_TOKEN.
  • Before publishing, the workflow builds and tests three official DSH capability representatives in this order: dsh-v0.1.0-rc.7 (0.1.0-rc.7), dsh-v0.1.1-rc.2 (0.1.1-rc.2), and dsh-v0.1.2-alpha.3 (0.1.2-alpha.3), using the official dsh plugin command and real compatibility checks.
  • The workflow never changes the package version or any CHANGELOG file automatically; an existing npm version also blocks publishing.

License

MIT