Preface

DeepSeek Harness (dsh) is an agent harness open-sourced by DeepSeek AI, currently in the developer preview stage. The official repository clearly states its core philosophy: Everything is a plugin. Models, tools, conversation loops, and the Web UI can all be split into replaceable plugins. As a result, a number of independent directory sites have emerged in the community for discovering and installing third-party plugins; these are not officially affiliated with DeepSeek / Fangfang, and you need to verify the source code and license yourself before installing.

When connecting custom model providers, the official “Models” page already supports managing providers, API keys, and model entries. However, there has been a persistent lack of UI access for several native capabilities declared per-model: what reasoning intensity levels does this model support, how should each level be spelled when sent to the endpoint, does it support images, and what are its context window and maximum output token limits? The official documentation requires modifying $DSH_HOME/settings.yaml manually. If a manually declared model does not have an input field, it defaults to processing only plain text, and image-enabled conversations will directly refuse to switch, prompting a message similar to Model ... does not accept image input; if reasoningEfforts is not specified, the model selector in the conversation input box will not show the reasoning intensity controls.

better-model-provider addresses this specific issue: it adds a “Model Capabilities” section to the settings page, allowing you to declare these items per-model in the provider profile without manually editing the YAML file or modifying the harness runtime.

What is this

better-model-provider is a model and provider plugin for DeepSeek Harness, maintained by sanshanya. Its repository address is https://github.com/sanshanya/better-model-provider, and its community directory page is at https://deepseek-harness-plugin.com/zh-CN/plugins/better-model-provider/. The main language is TypeScript, with the MIT license. The current public version is 0.0.1 (first public release on 2026-08-15), and the GitHub repository currently has 6 stars.

It targets models manually declared by users on OpenAI-compatible providers. The plugin itself is a UI plugin: it only mounts an empty keepalive entry on the host side, and all actual read/write operations use the existing settings.describe / settings.mutate and llm.providers contracts of the harness, without introducing runtime dependencies or touching API keys.

Core Capabilities

Based on the repository README, CHANGELOG, and settings page copy, there are three capabilities that can currently be declared in the UI:

1. Reasoning Intensity Levels (reasoningEfforts)

Check which levels each model accepts, and fill in the “wire spelling” for each level, which is the string used when sending requests to the gateway. The engine itself supports declaring levels per-model, and the official model selector will display them correctly; the gap was that the custom provider’s model editor did not expose this field previously. If no levels are declared, the reasoning intensity control will not appear in the selector.

There are three ways to set reasoning intensity in the UI: use provider default, no reasoning (false), and custom. Selecting custom will expand a multi-select list. The repository specifically reminds: only checking { high } will make the selector only show High; if you also need Off, you must check off (with an empty value, written as null).

2. Request Modal (input)

Optional values: text / image. Manually declared models default to plain text; visual models need to check image to allow image input on the host. The official guide also states that this field is missing from the form, and you can only add input: [text, image] to the model in settings.yaml. This plugin moves this line to the settings page.

The declaration is only a statement of the endpoint’s capabilities; the plugin will not detect whether the gateway actually supports images. If the model is marked as supporting image but the endpoint rejects images, the request will be rejected by the provider, which is consistent with the official documentation’s behavior.

3. Token Capacity (contextWindow / maxTokens)

You can fill in the context window and maximum output tokens per-model. Modify the values directly if the provider’s default values are incorrect; leave them blank to inherit the defaults. The spelling follows the same format as the official “Models” page: K stands for thousands, M stands for millions, for example 380K, 1M. The values will be validated as positive integer counts before writing.

The above three items apply to models you have already declared, with one configuration line per model. Adding/removing providers and models, and API keys, are still managed only on the official “Models” page; this page does not touch credentials.

Installation and Activation

The installation command given on the community directory page is:

dsh plugin add github:sanshanya/better-model-provider

The repository README has more complete instructions. This plugin declares platform: web on the client side, so it needs to be installed into the web profile:

dsh plugin --profile web add github:sanshanya/better-model-provider

For local development and debugging, you can use link: pointing to the absolute path of the repository:

dsh plugin --profile web add link:<absolute path to this repository>

After installation, restart dsh web, hard-refresh your browser, and a “Model Capabilities” entry will appear in the settings sidebar.

The directory page also reminds: for reproducible installations, pin the commit hash. The latest commit on the current main branch is 13e37c69055155e27ce6cdd0c29f5d85306e8a6f (2026-08-17), and the installation command is as follows:

dsh plugin --profile web add github:sanshanya/better-model-provider#13e37c69055155e27ce6cdd0c29f5d85306e8a6f

To uninstall:

dsh plugin --profile web rm better-model-provider

The plugin runs with the permissions of the current dsh process, and may execute code during installation. Please check the source code repository and license before installing.

Typical Usage

The operating sequence given in the repository is as follows.

  1. First configure the provider on the official “Models” page, and save the keys there. This page does not read or write credentials.
  2. Open Settings → Model Capabilities. If you do not have any providers yet, the page will prompt “No providers available” and ask you to configure them first on the official “Models” page.
  3. Expand the target model row: select “Custom” for reasoning intensity and check the allowed levels; check image for visual models to enable image input; if the provider’s default context window / maximum output values are incorrect, fill them in using the format 380K, 1M, etc.
  4. Click “Apply”. The selector will immediately only offer the declared intensity levels; image input will also be allowed based on the declaration. If the write fails, the draft will remain on the page; if there is a conflict, you will be prompted that the settings document has been modified elsewhere, and you should apply again after checking the refreshed state.

On directory providers, the model list only exists in the assembly baseline layer, and this page displays them as read-only, without materializing them into user settings. Unknown routes will disable capability editing. These behaviors are written in the plugin’s contribution instructions and UI copy, and are not extra features, but rather to avoid modifying parts of the official “Models” page that are not the responsibility of this plugin.

Applicable Scenarios and Notes

It is suitable for the following use cases:
- Corporate gateways, self-hosted OpenAI-compatible services, or providers not listed in the directory, where models are added manually on the “Models” page.
- Both plain text models and visual models exist on the same route, and you need to declare image per-model.
- The gateway’s reasoning intensity spelling does not match the DeepSeek / pi-ai default, for example, a certain level needs to send ultra instead of max in production.
- You do not want to manually modify reasoningEfforts, input, contextWindow, and maxTokens in settings.yaml every time.

Please note the following points when using it.

DeepSeek Harness is still in developer preview, and the official README notes that there will be breaking changes in the future. This plugin has been validated against harness master commit 47f943859b (2026-08-13), corresponding to release line 0.1.0-rc.6. The minimum available contracts known include settings.describe/mutate, llm.providers, the { rpcId, result } envelope, and the model row schema. The registration form of settings.section is treated as an experimental compatibility layer: if the updated harness does not provide this interface, the plugin will degrade silently instead of breaking the settings page. If the “Model Capabilities” sidebar entry does not appear after upgrading, first verify the harness version, then check if the plugin still matches the current contract.

The plugin only edits model capabilities, and is not responsible for the provider lifecycle. API keys, base URLs, adding/removing models, still go through the official “Models” page. Capability declarations will not verify whether the endpoint actually supports images or a certain reasoning intensity level.

The community directory is an independent site, not an official app store. The directory page may not be synchronized with the GitHub stars and recent push times; the installation command shall prevail based on the source you actually use. This article provides both the original directory page content and the --profile web syntax from the repository README.

Summary

Configuring custom providers in DeepSeek Harness is not difficult, but the challenge lies in writing “what this model can actually do” into the profile. The official interface manages keys and model lists, and previously reasoningEfforts and input could only be modified by hand-editing YAML. better-model-provider adds a “Model Capabilities” section to the settings page, allowing you to declare visual input, reasoning intensity levels, and token capacity per-model, writing to the same settings file without modifying the harness runtime.

Directory page: https://deepseek-harness-plugin.com/zh-CN/plugins/better-model-provider/

GitHub: https://github.com/sanshanya/better-model-provider