DeepSeek Harness Plugin Hub

发布与管理完整 Harness Profiles,发现适合你的插件。

探索

插件目录环境预设文档中心动态

社区

发布插件联系我们报告问题

相关链接

Plugin Hub GitHubDeepSeek Harness 官方项目系统状态隐私说明
© 2026 DeepSeek Harness Plugin HubPowered byPaxTech

独立、非官方社区项目,与 DeepSeek 官方无隶属、授权或背书关系。

Llm Model Tuning — DeepSeek Harness 插件(DSH Plugin)
DeepSeek Harness Plugin Hub
ProfilesPlugins分类动态文档登录管理 Profiles
ProfilesPlugins分类动态文档登录
← Plugins
L

dsh-llm-model-tuning

Llm Model Tuning

在 DSH Models 设置页面中,为自定义(llm-pi-ai)供应商的每个模型配置推理强度档位和多模态输入。

插件会安装到这里;不确定时保持 web。

npx -y @deepseek-ai/dsh plugin --profile web add github:xurunxin/dsh-llm-model-tuning#752fef1ec097897442a414c5f756dcae12de9e61
README兼容性版本

兼容性与来源证明

Llm Model Tuning 以 dsh-llm-model-tuning 发布,当前版本为 1.1.0。Plugin Hub 会校验它的 manifest,并保存精确安装来源,便于复现安装结果。

DSH 兼容范围
*
运行环境
web
发布来源
github
Registry 更新时间
2026/9/28

版本

1.1.0stable
2026/9/28

相关插件

正在加载相关插件…

最新版
1.1.0
DSH
*
HMR
重启进程
Tree shaking
未声明可安全裁剪
解包体积
未提供
文件数
未提供
Surface
web
许可证
MIT
发布源
github
GitHub
★ 0
周下载
0
最近提交
2026/9/28
查看源码 ↗
README Badge

点击下方 Badge 复制 Markdown,粘贴到 README 即可。

这是你的 Plugin?认领权益 · 优先安全扫描

验证 package.json 声明的 GitHub 仓库,即可管理这个公开页面。认领后,Hub 会优先安排当前版本的安全扫描,并在通过后公开展示结果。

认领这个 Plugin →
报告问题

相关插件

继续浏览 models-usage 分类下经过校验的插件。

Whale Widgetdsh-whale-widgetDSH Web 界面右下角的 DeepSeek 余额小鲸鱼挂件:余额/今日已用/峰谷定价、自定义泡泡点击序列(文本/余额/今日/峰谷/图片/随机语句与并列加权选择)、逐行样式与字体、悬浮快捷编辑、音效与每轮消耗、自定义角色/动图/音效、吸附与翻转自定义Client Ui Model Capabilities@linxin666/dsh-client-ui-model-capabilities为自定义 pi-ai 提供商声明每个模型的能力(图像输入和推理力度),可直接在 Models 设置卡片中编辑;写入官方 llm-pi-ai 设置命名空间,不更改 DSH 源代码。Codex Subscriptiondsh-codex-subscription通过 OAuth 在 DeepSeek Harness 中使用 ChatGPT 和 Codex 订阅,支持配额管理、安全重置、网页搜索、图像和快速模式Plugin@opencode2dsh/dsh-plugin供 DeepSeek Harness (DSH) 使用的免费 OpenCode Zen 模型:原生 dsh-llm 适配器插件,无需 API 密钥。

README

dsh-llm-model-tuning

Adds a per-model reasoning-effort and multimodal input editor to every custom provider card on the DeepSeek Harness Settings → Models page.

Requires dsh 0.1.7 or newer. This card writes settings through the configForms service; the older settingsScope service was removed in 0.1.7. See Requirements.

The shipped provider editor deliberately ships no reasoning control: effort is a per-model capability, and the models under one provider disagree about it, so a provider-scoped control could only be set to a value some of them reject. This plugin takes the per-model granularity instead — it lists the route's own model entries and edits two fields on each:

FieldMeaning
reasoningEffortsWhich effort levels the model offers, and the wire spelling each one sends. false declares a non-reasoning model; absent inherits the installed catalog.
inputWhich request modalities the model accepts (text, image). Absent inherits the installed catalog.

It also edits the route-level defaultInput fallback, which is what makes a gateway serving vision models the catalog does not describe usable.

Both fields are written into the llm-pi-ai settings section, so a change reaches the next request with no restart — the adapter resolves profiles per request.

Why this is a client-side plugin

The whole contribution is one card on the settings.models.provider-card seat, keyed by the provider row's own settings namespace. Because every configurable pi-ai route declares settingsNs: 'llm-pi-ai', a single registration under that key receives every custom-provider card — saved rows and the add-provider draft alike — without the Models section knowing anything about this plugin.

The host half is intentionally empty. It exists only so the profile row resolves to a real package, which is what makes @deepseek-ai/dsh-client-modules scan the dsh.client declaration and serve lib/client.js into the browser boot graph.

Install

Install the bundle with the plugin manager, pointing it at this directory:

plugin_manager  action: install_bundle  target: <absolute path to this package>

That performs the package installation and bundle selection itself — it adds the dependency, links it into the active profile's node_modules, and appends the package to dsh.profile.bundles because it declares dsh.bundle.patch. Do not hand-edit the profile's package.json or cordis.patch.yml, and do not run a package manager in the profile directory.

The install is a symlink to this directory, so later edits here are picked up without reinstalling. A freshly installed bundle can activate through HMR; a replaced one needs a profile restart to load a fresh JavaScript module generation.

Requirements

  • dsh 0.1.7 or newer. This card reads and writes settings through the configForms service. The older settingsScope service was removed in 0.1.7, and a card still injecting it never activates — the row simply waits forever. test/bundle-contract.mjs guards against that regression.
  • The llm-pi-ai adapter must be composed, since it owns the settings namespace this card edits. The card follows it with configForms.whileServed, so a deployment without that adapter shows no trace of this card rather than a dead panel.

What the card does with your document

  • Edit surface. The card reads and writes the user layer of the llm-pi-ai section. A route declared only in the composition base is read from the resolved value so it can still be tuned; writing it is what materializes it in the user layer.
  • Path-addressed writes. Every edit travels as settings.mutate path ops against the stored section, so fields the card never rendered cannot be deleted. The namespace revision fences a stale card against a concurrent change.
  • models vs modelOverrides. A models list replaces the installed catalog, while modelOverrides reshapes it. The adapter refuses both together, so the card edits whichever the profile already uses and offers to add modelOverrides entries when neither is present. A models list is an array — and the settings path-op walker refuses to descend through arrays — so that array is written as one value; a modelOverrides dict is addressed field by field.
  • Text is held on. input and defaultInput replace a modality list rather than extending it, so declaring images alone would quietly drop text and leave a model the harness can no longer talk to. Text is therefore always kept, and clearing the last optional modality removes the field so the adapter's own default answers instead.
  • Refusals are named locally. ConfigFormController.mutate reports whether the Host accepted a write, not which field it rejected. The card therefore reproduces the adapter's own reasoningEfforts rules (every level needs a wire spelling; only off may be empty; at least one level beyond off) so a refusal names the field, and it still reports a Host rejection as a failure rather than success.

Tests

npm test

Four suites, all offline, no dependencies to install:

SuiteWhat it proves
test/harness.mjsThe card's own behaviour, driven through its real inputs against a faithful settings-op simulator. Includes a rejection-never-reported-as-success case, and one proving nothing registers when the Host does not serve the namespace.
test/integration.mjsThe exact section the card wrote is accepted by the real llm-pi-ai Config schema.
test/conformance.mjsDocument shapes, and the refusals the card reproduces, checked against that same real schema.
test/bundle-contract.mjsThe bundle satisfies the loader's registration protocol and requires nothing outside the module baseline.

The two schema-checked suites need an installed @deepseek-ai/dsh-llm-pi-ai to compare against. test/dsh-adapter.mjs locates one from DSH_PROFILE_DIR, DSH_HOME, or the usual ~/.dsh/profiles layout; when none is reachable they print a labelled SKIP and exit 0 instead of failing, so a contributor without a DSH installation still gets a green run. Set DSH_PI_AI_DIR to point at an unusual layout.

The last assertions in conformance.mjs are informative on purpose: the real schema accepts an empty wire value for a thinking level, because only the adapter's resolution step rejects it. That confirms the card's own validation is load-bearing rather than redundant.

Limitations

  • The card edits only reasoningEfforts, input, and defaultInput. Capacities, compat switches, and credentials stay with the shipped editor and settings.yaml.
  • Levels beyond the seven the schema accepts (off, minimal, low, medium, high, xhigh, max) are preserved on write but not offered for editing.
  • Settings are stored in the user's settings.yaml; the card holds no state of its own.