dsh-commandcode-provider

English | 简体中文

Awesome GitHub Repo stars DeepSeek Harness PRs Welcome CI License: MIT npm

Unofficial DeepSeek Harness LLM provider plugin for Command Code, ported from pi-commandcode-provider (MIT).

Community integration. You need your own Command Code account, API key or subscription, and Command Code's terms apply. Not affiliated with Command Code, Inc.

Quick start

Verified engines	dsh 0.2.1-rc.2, 0.2.1-rc.3, 0.2.1-rc.4, 0.2.1-rc.5, 0.2.2-alpha.2
Node.js	>=24.9 — raised from 22 in 0.16.0, see Node.js 24.9 or newer
Install — web	dsh plugin --profile web add @mars-sea/dsh-commandcode-provider@latest
Install — terminal	dsh plugin --profile dsh-tui add @mars-sea/dsh-commandcode-provider@latest
Config file	$DSH_HOME/settings.yaml → llm-commandcode:
API key env	COMMANDCODE_API_KEY
Usage dashboard	/commandcode

Features

• Plugin bundle — one dsh plugin add installs a commandcode provider route with the live model catalog.
• Settings page — accounts (keys, browser sign-in, live quota, dedicated models), model visibility, privacy switches, connection options.
• Annotated catalog — plan tier, deal/FREE badge, peak/off-peak, image support and context window in the picker; free models first.
• Multi-account rotation — an exhausted account hands over to the next one; pin a preferred account or route models to dedicated ones.
• Browser sign-in — run the official authorization flow from the settings page; the approved key lands in the local credential store.
• Plans & quota panel — optional sidebar card with the serving account's plan, 5-hour and weekly windows, balances and reset times.
• Session cost estimate — published-rate estimates (≈) beside the composer token counter, priced per request from durable session history.
• Model analysis — tokens, estimated cost, response timing and failures by session or date range. Scope.
• Web search — the dsh web_search tool is served by Command Code (/alpha/web-search) with the same key and endpoint as chat.
• Zero data retention — optional ZDR routing (x-cmd-zdr: 1), off by default.
• Context & output limits — override the metered context window globally or per model, and cap or omit the per-turn max_tokens.
• Reasoning effort & images — effort levels in the picker; Vision models accept images.
• Terminal UI — the same install serves a dsh-TUI profile with its own /settings → Command Code page.

Screenshots

Model picker — plan tier, deal/FREE, peak/off-peak, Image and context annotations:

<img src="assets/screenshots/model-picker.png" alt="Model picker with plan, deal, image and context annotations" width="320">

Usage dashboard — /commandcode per-account report:

<img src="assets/screenshots/usage-dashboard.png" alt="Usage dashboard" width="520">

Settings page — accounts with live quota, model visibility, privacy switches, connection options:

<img src="assets/screenshots/settings-page.png" alt="Command Code settings page with the account usage card" width="640">

Install

dsh plugin --profile web add @mars-sea/dsh-commandcode-provider@latest

This build admits dsh >=0.2.1-rc.2 <0.2.2-0 — every RC of the 0.2.1 channel from 0.2.1-rc.2 onward — and >=0.2.2-alpha.2 <0.2.3-0, the 0.2.2 channel from its current alpha. 0.2.1-rc.5 is what npm latest and next run, and 0.2.2-alpha.3 is on alpha. All six are covered by the full engine matrix (npm run test:engine, npm run test:install). A later release of either channel is admitted without a plugin update, but stays unverified until a record is added to dsh.compatibility.dshReleases. 0.2.3 and later are deliberately excluded — the upper bounds are written <0.2.2-0 / <0.2.3-0 for exactly that reason. A profile on 0.2.0-rc.2, 0.2.1-alpha.5 or older must upgrade its engine first. Compatibility details — the engines.dsh admission rule, package pairings, evidence — live in engine compatibility.

Node.js 24.9 or newer is required

The Node.js floor was raised from 22 to 24.9 in 0.16.0. On Node 22 or 23, upgrade Node before updating this plugin.

dsh 0.2.2-alpha.2 declares engines.node >=24.9.0 and this plugin admits that engine, so the package-wide floor had to follow: a plugin that claims to support an engine must not be installable on a Node version that engine cannot start on. What that means in practice:

• npm reports EBADENGINE when installing or updating this plugin on Node 22/23. It is a warning, not a hard failure, unless your npm sets engine-strict=true.
• The 0.2.2 engines genuinely cannot run on Node 22/23, so a profile admitted there would fail at startup — the failure this floor exists to prevent.
• The 0.2.1 RC engines still run on Node 22, but engines.node is a single floor for the whole package, so it applies to them too. That is the cost of admitting two channels in one build.

nvm install 24 && nvm use 24 (or any Node 24.9+ distribution) resolves it. Node 24 is a current LTS line.

Older dsh releases are no longer supported: the last plugin release for dsh 0.1.7 is 0.11.17, for 0.1.2–0.1.6 it is 0.11.11, and for the 0.5.0-era line 0.9.1 — all installed by exact version, none maintained.

pnpm 11 holds back new releases. minimumReleaseAge defaults to 1440 minutes, so a version published less than a day ago is skipped and @latest resolves to the previous release — silently, with a success exit code. To install a release from the last 24 hours, name it exactly: @mars-sea/dsh-commandcode-provider@0.11.15. This applies to every profile, including the terminal UI below.

Updating — same tag, then restart the web app. Each profile updates separately, because the terminal UI owns its own plugin list:

dsh plugin --profile web update @mars-sea/dsh-commandcode-provider@latest
dsh plugin --profile dsh-tui update @mars-sea/dsh-commandcode-provider@latest

Get an API key and verify it works

Easiest via the official CLI (Node.js 22+):

npm i -g command-code@latest
cmd login        # macOS/Linux; native Windows: cmdc login

Or skip the CLI: click Sign in to Command Code under Settings → Command Code — the browser opens the commandcode.ai authorization page (the same flow cmd login runs) and the key is stored locally once you approve. You can also create a key on the Keys page and paste it, or export COMMANDCODE_API_KEY="user_...".

The sign-in flow needs the Host and your browser on the same machine (loopback callback). With a remote Host, paste the key manually; a literal composition-level apiKey, if set, still takes precedence over a signed-in credential.

To verify: after restart, enter your API key in Settings → Command Code and save. Settings → Models shows a Command Code card, and the model picker lists the live catalog under commandcode. Send a message with a model your plan includes.

Terminal UI (dsh-TUI)

Each dsh profile owns its own plugin list, so the web install does not reach the terminal — add the plugin to the dsh-tui profile as well, pinned to an exact version (within 24 hours of a release a bare name resolves to the previous build, leaving a fresh install with no /settings → Command Code page and no commandcode models):

dsh plugin --profile dsh-tui add @mars-sea/dsh-commandcode-provider@latest

Then pick the provider in the model selector, or name it directly:

/model commandcode/deepseek/deepseek-v4.1-flash

/model lists every registered provider, with the live catalog and its plan/deal/context annotations; the /commandcode dashboard works there too.

Entering the key. The TUI has no web Models page, so the plugin declares its own page — /settings → Command Code — with the API key, API base, out-of-plan filter, active account and command language. The key field is write-only: it shows whether a key is configured and writes what you type to the credential store, never to a settings document. The same page lists the whole catalog as checkboxes grouped by plan tier, free models first; everything starts checked, and the choice is stored as per-model overrides next to the visibleModels list the web page edits.

Alternatively set the key outside the TUI. The first match wins:

• A literal apiKey in the composition config wins over everything and is always used.
• Otherwise the credential reference is resolved (apiKeyEnv, COMMANDCODE_API_KEY by default). In a profile that mounts the credentials service (Web, desktop, SDK, ACP) that service owns the order: since 0.2.1-alpha.3 a saved credential wins over the launching environment; earlier releases had the environment first.
• A headless profile mounts no credentials service on purpose, so only the launching environment, the project .env and $DSH_HOME/.env apply — a key saved on the page never reaches a headless run.
• The last resort is ~/.commandcode/auth.json, written by the official CLI.

export COMMANDCODE_API_KEY="user_..."   # launching environment
cmd login                               # writes ~/.commandcode/auth.json

Making Command Code the default. dsh-TUI pins its own agent route, so its agent-default-model setting does not override it. Override the agent-loop row in your profile patch ($DSH_HOME/profiles/dsh-tui/cordis.patch.yml):

- id: agent-loop
  inject: [tuiStartup]
  config:
    agents:
      - id: main
        provider: commandcode
        model: deepseek/deepseek-v4.1-flash
        reasoningEffort: max
        cwd: !!js process.cwd()

Usage dashboard

The plugin registers a /commandcode slash command showing per-account usage:

/commandcode        (or /commandcode status)

Its copy follows the shell's locale: explicit lang: 'en' | 'zh' in the llm-commandcode plugin config wins, otherwise LC_ALL/LANG is read, otherwise it falls back to zh. The web settings page is independent — it follows the browser's language preference.

Account rotation

With several Command Code subscriptions, the plugin switches to the next account automatically when one hits its usage limit:

• Setup — Add account in the Accounts card at Settings → Command Code, then sign in or paste an API key. Account actions (add, rename, replace or clear a key, remove, pin) apply immediately; only the other settings wait for the Save bar. The top-level key always serves first as the default account.
• Manual switching — Pin this account in an account's ⋯ menu makes