my-dsh-plugin/thinking-level-override

thinking-level-override

English | 中文

A DeepSeek Harness plugin that fixes missing or mismatched thinking-level presets of third-party models: it overrides and adjusts the reasoning effort on every request, and lets you choose exactly which thinking levels each model offers.

Third-party models reach the harness through adapter catalogs whose reasoning presets do not always match reality: a selector offers a level the exact model cannot serve, a session inherits an effort across a model switch, or a deployment simply wants one level for a whole route. Left alone, such a request fails UNSUPPORTED_REASONING_EFFORT before it reaches the provider. This plugin intercepts the request configuration, rewrites the reasoning effort according to your rules, and repairs unserviceable levels instead of letting the request fail.

Quick start

You can use the plugin two ways — they can be combined:

A. Pick the offered levels on the Web settings page (no YAML). Open the Web GUI → Settings → Thinking levels (right below Models). For each model, check the levels it can actually serve, then Save. The conversation's model-selection dialog now offers exactly those levels — choosing the actual level still happens in the dialog. This writes each model's reasoningEfforts under llm-pi-ai in settings.yaml for you.

B. Write override rules in YAML. Rules force, default, or remap levels per provider/model, and repair levels a model cannot serve:

thinking-level-override:
  rules:
    # The kimi-k2 family on openrouter misreports its preset: always use high.
    - provider: openrouter
      models: ['kimi-k2*']
      effort: high
    # acme-gateway uses a different vocabulary: rename the levels, default to medium.
    - provider: acme-gateway
      map:
        max: high
        xhigh: high
      default: medium
    # legacy-gw cannot serve inherited efforts: drop them instead of failing.
    - provider: legacy-gw
      onUnsupported: drop

Rules are live: writes to settings.yaml are picked up by the next request, no restart.

How it works

The plugin listens to the agent/request waterfall — the documented interception point for the frozen call configuration — and transforms the resolved LlmCallConfig before the LLM seam validates it against the exact model capability. It registers with prepend, so the override is the outermost listener and has the last word over later listeners such as model selection. The loop logs the rewritten configuration through its normal request/header path, so every override stays durable and reconstructable from the session log.