DeepSeek Harness Plugin Hub

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

探索

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

社区

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

相关链接

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

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

Keys Manager — DeepSeek Harness 插件（DSH Plugin）
DeepSeek Harness Plugin Hub
ProfilesPlugins分类动态文档登录管理 Profiles
ProfilesPlugins分类动态文档登录
← Plugins

dsh-keys-manager

Keys Manager

DSH 提供商的多密钥管理：按会话固定的轮询、重试故障转移、冷却恢复，以及可搜索的额外提供商。

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

npx -y @deepseek-ai/dsh plugin --profile web add dsh-keys-manager@0.1.0
README兼容性版本

兼容性与来源证明

Keys Manager 以 dsh-keys-manager 发布，当前版本为 0.1.0。Plugin Hub 会校验它的 manifest，并保存精确安装来源，便于复现安装结果。

DSH 兼容范围
*
运行环境
web
发布来源
npm
Registry 更新时间
2026/10/19

版本

0.1.0stable
2026/10/19
0.0.1stable
2026/10/19

相关插件

正在加载相关插件…

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

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

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

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

认领这个 Plugin →
报告问题

相关插件

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

Cost Meterdsh-cost-meterDeepSeek Harness 会话费用统计插件:本会话成本、当日费用、历史记录与官方价格同步,支持多厂商多模型价格计费(内置 170+ 模型 ID 价格目录与自动匹配)、主流 Coding Plan 订阅额度查询与显示(14 家,含 WorkBuddy 官方积分、OpenDesign 工作区查询、含小米 MiMo Token Plan 控制台 Cookie 查询、SCNet Token Plan 本地 Credits 计量与火山方舟 Volcano Ark Coding Plan AK/SK 签名查询Codex Subscriptiondsh-codex-subscription在 DeepSeek Harness 中通过 OAuth 使用 ChatGPT 和 Codex 订阅，支持配额、安全重置、网络搜索、图像和快速模式，并可通过 ChatGPT 移动应用（Beta）控制 DSHConnect Workbuddydsh-connect-workbuddy把本机登录的 WorkBuddy 模型接入 DeepSeek Harness，并提供只读的积分概览与模型管理。Connect Traedsh-connect-trae把本机登录的 Trae 模型接入 DeepSeek Harness：国内版与国际版双供应商并行，提供用量/积分概览与每日签到领取。

README

DSH Keys Manager

English | 简体中文

Docs: Development · Release · Known limits — Documentation in Chinese: 开发 · 发布 · 已知限制

A DeepSeek Harness plugin that turns one provider API key into a managed pool. It extends the Models page rather than replacing it: providers, models, and the model picker stay where they are; only the API-key source moves behind the manager.

Features

  • Several keys per provider, each with an alias and health state.
  • One key pinned to a session, with round-robin selection for new sessions.
  • Bounded retry on the same key, then automatic failover to another key.
  • Exponential cooldown recovery, capped at seven days.
  • A search-driven Keys Manager page on the plugin's own detail page.
  • A "managed by Keys Manager" badge inside the existing Models provider cards.
  • Extra built-in providers installed as ordinary llm-pi-ai routes.

Extra providers

src/providers.ts contains a curated catalog of 34 extra providers (21 from the original catalog plus 13 added in this release, for example SiliconFlow, Zhipu coding plan, Cline Pass, Ollama Cloud, and Alibaba Token Plan (CN)), derived from oh-my-pi's provider catalog (MIT). An extra id is added only when the shipped DSH catalog does not already declare that route id (for example, meta and typesafe are not duplicated); same-endpoint providers with distinct credential identities are kept by design.

Quick start

Install — published package

dsh plugin --profile web add dsh-keys-manager

Install — local checkout

git clone https://github.com/btspoony/dsh-keys-manager
cd dsh-keys-manager
pnpm i
dsh plugin --profile web link .

Refresh the Web page after installing so the browser half is fetched.

Usage

Open Plugins → Keys Manager → View (rendered as Plugins → 密钥管理 → 查看 in the Chinese locale). The manager renders on the plugin's detail page, between its description and its included rows, matching the shipped plugin configuration cards.

  1. Search for a provider. Existing DSH providers appear first; the plugin also ships the curated extra catalog described above.
  2. Adopt a provider. For an existing provider the manager imports the currently resolved credential, writes a broker reference into the provider profile, and leaves the original key in the credential store so release can restore it.
  3. Add more keys with an alias. Every key is stored in the Harness credential store under its own reference; the manager state document never contains a key literal.
  4. Manage a key from the three-dot menu: rename, pause/resume, delete. A key row shows status, last use, and the recovery time while cooling.
  5. Tune retry count (1–3), base cooldown, and recovery grace in the settings card.

Selection and failure policy

  • Sticky session: the first request of a session selects a key and binds it for that session/provider pair. Later requests reuse it.
  • Round robin: a new session advances the provider cursor and takes the next healthy key.
  • Retry: a failing request is retried on the same key retryCount times.
  • Switch: after the retry budget is spent, the failing key is marked cooling, and the session is rebound to another healthy key.
  • Cooldown: the first failure cools a key for baseCooldownMs. A failure while cooling, or within recoveryGraceMs after recovery, doubles the next cooldown. A long healthy gap resets the escalation. The hard cap is seven days.
  • Recovery: the key is automatically selectable again when its cooldown expires; no manual reset is required.
  • Delegation: request-shaped failures such as CONTEXT_WINDOW_EXCEEDED and cancellation never cool a key. When no alternate key exists, the manager delegates to the composition's normal retry/fallback policy.

Configuration & data

Manager metadata lives at:

$DSH_HOME/keys-manager/state.json

with owner-only permissions. It contains aliases, credential references, health counters, session bindings, and provider adoption facts. API key literals live only in the Harness credential store. The file is written atomically through a temporary file and a rename.

Each managed provider profile points its apiKeyEnv at a broker reference such as KEYSMGR_ZAI_CODING_CN_3FA2C1. The Host credential layer answers that reference per request with the session's selected key. The Models page sees the profile as configured; writing directly to the broker reference is refused with a pointer to the manager.

OAuth2 extension point

The state shape already distinguishes kind: "api-key" from kind: "oauth" and keeps a nullable oauth object beside the credential reference. A future account flow can add records under keys-manager/<provider>/<key> without rewriting existing rows. Providers whose only authentication is OAuth are reported as unsupported in this version rather than being treated as API-key providers.

Provider classification

Every provider card carries its origin:

  • DSH built-in (DSH 内置) — a route from the shipped DSH pi-ai catalog.
  • Plugin built-in (插件内置) — a route from this plugin's extra catalog in src/providers.ts.
  • Custom (自定义) — a hand-declared route in the active profile.

The following DSH built-ins are explicitly outside single-key pool management:

ProviderWhy
amazon-bedrockAWS credential chain (profile, IAM keys, ECS/IRSA/EC2), not one API key
cloudflare-ai-gatewayAPI key plus a Cloudflare account ID and gateway ID
cloudflare-workers-aiAPI key plus a Cloudflare account ID
openai-codexChatGPT OAuth sign-in only; no API-key credential

All other DSH catalog routes expose an API-key credential. Providers that also support OAuth (Anthropic, GitHub Copilot, Kimi, OpenRouter, xAI, Radius) remain manageable through their API-key path; OAuth accounts are tracked separately in the roadmap issue.

Documentation

DocContent
Developmentbuild and dev workflow, repository layout
ReleaseCI checks and the npm release flow
Known limitscurrent design boundaries, including deferred providers

Chinese versions: README.zh-CN.md and the *.zh-CN.md files in docs/. Current design boundaries at a glance: Known limits.

License

Released under the MIT License.