dsh-hive: Transforming DeepSeek Harness Sessions into a Peer Collaboration Hive

Introduction¶

DeepSeek Harness (DSH) includes a subagent system out of the box: a parent session forks subagents that share context and are destroyed after the task ends. This is suitable for short-lived, tightly coupled small tasks.

But in real development, there is often a need for multiple independent, long-running top-level sessions (for example, a “coordinator” session decomposes tasks, while multiple “worker” sessions process them in parallel) to collaborate with each other. DSH’s native subagent mechanism cannot meet this kind of peer-to-peer, long-lived collaboration requirement.

The dsh-hive plugin solves this problem. It turns DSH sessions into a “hive,” enabling one session to directly send tasks to another session, wake it up, and automatically receive results. This communication happens between top-level sessions rather than between subagents.

Plugin Introduction¶

dsh-hive is a DeepSeek Harness plugin maintained by developer llluchy. It implements peer-to-peer communication between sessions by exposing two tools that models can call.

The core value is enabling multiple independent sessions to assign work to each other like colleagues, each maintaining its own context and history without interference.

Core Features¶

The plugin provides the following capabilities:

1. Wake on delivery: As soon as a message reaches the target session, immediately wake it up and start a new turn of conversation.
2. Automatic result callback: When sending a task, the message automatically carries an instruction to “return the result after task completion” (including the sender’s session ID). The receiver only needs to follow this convention when replying.
3. Task correlation: The callback instruction includes the first 40 characters of the task text as a label. When replying, the receiver repeats this label, allowing the sender to identify which task the reply belongs to.
4. Send-and-yield: After sending a task, the sender’s current turn ends immediately (concludesTurn) without blocking while waiting for a reply. The reply arrives as a new message in a later turn and wakes the sender.
5. No self-delivery: The plugin prevents sending messages to one’s own session to avoid logical errors.

Installation and Activation¶

dsh-hive is a DeepSeek Harness bundle (it declares dsh.bundle and includes cordis.patch.yml). Its installation process matches the official tutorial, and no manual modification of harness code is required.

Run the following command to install it:

dsh plugin --profile <name> add github:llluchy/dsh-hive

After installation, you can use dsh --profile <name> --dump-config to check whether the configuration layer includes dsh-hive. After launching Harness, ask for list_sessions in any conversation to see the list of active sessions in the current process.

Typical Usage¶

Basic Flow: Send a Task and Receive the Result¶

In the sender session, instruct the model to perform the following steps:

1. Call list_sessions to obtain the target session ID.
2. Call send_to_session, passing the session ID and task text as parameters.

After the sender sends the task, its turn ends. The target session is woken up and processes the task in its own context. Because the task message automatically includes the callback instruction, the target session returns the result to the sender automatically. The sender is woken up in the next turn and can see the result.

Batch Sending¶

During the planning phase, list the target sessions first, then issue multiple send_to_session calls at once. All tasks will be delivered. The sender is released after the entire batch of tasks has been processed, and results are then received one by one through replies.

Notification Only, No Reply Expected¶

If the message being sent is itself a reply (for example, a confirmation of an earlier task), or if no result from the other party is needed, set expectReply to false. In this case, the message does not include the callback instruction, avoiding a reply loop.

Tool Reference¶

list_sessions¶

Lists sessions in the current DSH process that are in the “active/loaded” state.

Return value: { ok, count, sessions: [{ id, status, cwd? }] }

• Live-only targeting: Only returns sessions currently running. “Cold sessions” that have never been opened do not appear in the list and cannot be targeted.

send_to_session¶

Directly delivers a message to the specified session and wakes it up.

Return value: On success, returns { ok: true, deliveredTo, expectReply, senderId }; on failure, returns { ok: false, error } (for example, empty session ID, unknown session, or self-delivery).

Use Cases and Considerations¶

dsh-hive is suitable for scenarios where a complex workflow needs to be split into multiple independent, long-running roles.

Considerations:

1. Access restriction: list_sessions and send_to_session can only see sessions already loaded in the current DSH process. Sessions that have not been opened cannot be queried or woken up.
2. Soft convention: The callback mechanism is convention-based. The plugin generates a “please reply” instruction, but whether the receiver enforces it or whether expectReply: false is set depends on the decision of the receiving model. There is no hard state machine to prevent infinite loops.
3. No persistence: The plugin only handles message delivery and session wake-up; it does not maintain message timelines, read receipts, or member lists.

Summary¶

dsh-hive provides a lightweight peer-to-peer session collaboration solution. It does not impose a complex state machine; instead, it relies on models following the agreed instruction flow. If you need to build a multi-role collaboration system with independent contexts, you can review more details via the following links:

• Plugin directory page
• GitHub repository