tequed232/DSH-L2D

What it does

DSH-L2D connects a Live2D Cubism character to a DeepSeek Harness (DSH) workspace. Instead of only replying in text, an agent can describe semantic goals such as looking at the user or entering a thinking state, and a local runtime resolves them into expressions, gazes and motion chains. The project separates semantic intent from rendering: an action queue and parameter ownership rules arbitrate writes, then the Cubism/WebGL renderer applies them (architecture overview).

The codebase is split into a model-agnostic core, a renderer, a DSH plugin, a stdio MCP server, an MCP bridge and a SQLite action/model registry (module responsibilities). An MCP client can start the server to enqueue, query or cancel character actions from an agent.

The README is explicit about maturity: renderer, parameter injector, FIFO scheduling, the action library and the MCP server are implemented; the workspace bridge and overlay are still being validated; sidebar/pet-window switching, automatic limb allocation and the dual-view workspace UI are partial, planned or experimental (implementation status). If you need a finished drop-in desktop pet, this is not that yet.

Quick start

Prerequisites: Node.js 22+, pnpm 12.5.1, a working DeepSeek Harness installation, and your own Live2D model plus Cubism Core (requirements).

1. Clone and install:

git clone https://github.com/tequed232/DSH-L2D.git
cd DSH-L2D
pnpm install

2. Build the renderer:

pnpm build:renderer

3. Package the DSH plugin and deploy it through your DSH profile's plugin installation method, then restart DSH as the host requires:

npm pack ./packages/dsh-l2d-plugin

The exact plugin registration and profile paths can change with DSH versions; follow the current DSH and plugin package instructions.

4. Place your licensed Live2D model and Cubism Core where the plugin settings expect them. Neither is shipped in the repository; obtain Cubism Core from the official Live2D SDK page.

5. Optionally start the MCP server:

node packages/dsh-l2d-mcp/src/server.mjs

and register it with your MCP client, replacing the path with your local absolute path:

{
  "mcpServers": {
    "dsh-l2d": {
      "command": "node",
      "args": ["/absolute/path/DSH-L2D/packages/dsh-l2d-mcp/src/server.mjs"]
    }
  }
}

For debugging the overlay and action pipeline without DSH, run pnpm build:renderer then pnpm dev:server and open the address printed in the startup log (local debugging). Available MCP tools are whatever the running server returns in tools/list; see the MCP package notes for tool semantics and receipt examples.

Constraints and limits

• The system and media sensors are off by default and should be enabled explicitly. The bridge should only listen on loopback; do not expose it or API keys to the public internet (privacy boundaries).
• A successful action request is not proof the motion finished. accepted means queued, and pending should not be resubmitted; completion or interruption must be read from receipts and events (action chain semantics).
• Motion chains accept at most 15 segments, and a renderer batch handles at most 8 steps. Model capability states supported, approximate, unsupported and unknown are distinct; unknown must not be treated as supported.
• Unit tests, contract checks, browser verification and real DSH host acceptance are separate layers. Passing one does not validate every model, GPU or window container (acceptance scope).
• Models, textures, motion assets and the Cubism Core binary are not distributed with the repository and may carry their own licenses; the repository itself is MIT (resources and license).

HotRepo's take

On 2026-11-07 the project entered HotRepo's new-project JavaScript list with 106 stars and 18 forks, reporting a net gain of 5 stars over a roughly two-hour window; the hourly star samples moved from 102 to 106 across that afternoon. That is a short observation window and only supports the fact of an early spike, not a trend.

The engineering write-up is unusually candid for a young project: it distinguishes implemented, wired, experimental and planned subsystems and warns that mock conversation services and a degraded local agent client are not real backends. The gap between that honesty and the partial state of the workspace bridge is the main thing to note — the renderer and action pipeline are the concrete parts, while the agent integration story is still being accepted.