dsh-key-manager

Multiple API keys per provider for DeepSeek Harness.

Keep a pool of API keys for each provider configured in Settings → 模型 (Models), annotate each key with a note, and switch the active key from Settings → API 密钥 — every switch really takes effect on the next model call.

Features

• Per-provider key pools — for every configurable provider exposed by the Models page (only providers that actually have a key reference are listed).
• Notes — annotate each key (e.g. "personal", "team", "billing A"); the currently-in-use key can be renamed too.
• Switch that really applies — activating a key writes it through the harness credential seam. When the native reference is shadowed by the process environment or a .env file, the plugin takes over by storing the value under a plugin-managed reference and repointing the provider's apiKeyEnv at it — the Models page shows which reference is in effect.
• Current-use pinned first — the key actually in use always sits on top with a green badge; keys missing the pool show as a "live" row.
• Defaults to the provider in use — the page pre-selects the provider behind the currently-selected model.
• Durable, no hardcoded paths — the registry file lives next to the harness data directory (derived at runtime from the settings document path).

Storage note: key values are persisted in plain text in the harness data directory (~/.dsh/dsh-key-manager.json), the same level of protection the harness itself applies to .credentials.yaml. Lock down the directory if you share the machine.

Install

dsh plugin --profile web add dsh-key-manager

Restart dsh web, then open Settings → API 密钥.

How it works

Piece	Where
Settings section api-key-manager	lib/client.js (web module)
Same-origin JSON API /plugins/dsh-key-manager/*	lib/index.js
Key pool registry	~/.dsh/dsh-key-manager.json (derived at runtime)
Active key write	harness credentials service (native ref, or plugin-managed takeover ref)
Provider apiKeyEnv repoint	harness settings service (llm-* namespace)

License

MIT