Preface

In DSH’s agent flow, some model calls do not need to enter the main Session’s formal transcript, but they still require invocation, restriction, and cancellation, and must be able to be counted separately. For example, Clarify-type tools may need to generate context questions, options, and evolving Draft previews, while SeekTTY-type tools may need to display official usage, auxiliary usage, and combined usage in /status respectively.

If these auxiliary calls are all mixed into the official tokenUsage, the source becomes unclear; without concurrency and total token limits, controlling the main Session’s runtime surface becomes difficult. Below introduces dsh-plugin-auxiliary-runtime, which places these auxiliary model calls in a cancellable, restrictable, and auditable runtime, and maintains a usage ledger independent of the official tokenUsage.

What is this

dsh-plugin-auxiliary-runtime is a community Host plugin for DeepSeek Harness (DSH), maintained by Hilbert-beinghappy, and licensed under MIT. The current version is 0.1.1.

The problems it solves can be summarized in three points:

  1. Bind cancellable auxiliary model calls to an already existing live Session.
  2. Apply policy limits per Session instead of allowing auxiliary calls to run with unlimited concurrency or token consumption.
  3. Record auxiliary call usage into the official storageDomain, forming a ledger separate from the official tokenUsage.

Clarify and SeekTTY can be used as optional consumers, but they are not installation requirements.

Core Features

Cancellable Auxiliary Model Calls

The plugin supports cancellable auxiliary model calls. The calls are bound to an already existing live Session and are no-tools auxiliary model calls.

Cancellation is not simply discarding the request. The runtime combines the caller’s signal and the service’s signal via AbortController to keep the cancellation path consistent with the provider call path.

Admission and Streaming Output Boundaries

Auxiliary calls undergo token-limit admission after provider metadata has been materialized and before streaming begins.

Successful live calls temporarily return model text to the in-process caller. The returned content is concatenated in stream order and is limited to 65,536 UTF-16 code units.

Terminal replay returns persisted state and usage, along with:

replayed: true
output: null

If the caller needs new text, a new call must be initiated rather than relying on replay to return new model output.

Per-Session Policy Limits

The plugin supports per-Session policy limits, including the following configuration items:

maxConcurrentCalls
maxCallsPerSession
maxAuxiliaryTotalTokens

These limits are used to control the concurrency count, number of calls, and total auxiliary token amount within the same Session.

Three-Source Usage Views

The plugin provides three usage views with different sources:

View Meaning
Official Projection of the official Host tokenUsage.
Auxiliary The auxiliary_runtime ledger maintained by this plugin.
Combined The combined value for consumer viewing, not entering the official projection.

Usage is recorded in four buckets:

uncachedInputTokens
outputTokens
cacheReadTokens
cacheWriteTokens

The Combined value is used for consumer-side aggregation display and remains independent of the official tokenUsage.

Persistent Ledger

The ledger uses the official storageDomain:

auxiliary_runtime
version 0

It contains two tables:

calls
policies

Persisted rows are used to save call and policy records. It does not contain prompts, messages, system text, model output, custom answers, credentials, environment values, or filesystem paths.

Failed records only save the normalized:

{ category, code }

Version 0 retains audit rows and rejects new auxiliary calls when 10,000 rows are reached.

Session Fencing

Records are fenced using the Session ID and session.header.createdAt. If the same Session ID is reused, it will also start based on new usage and policy identity.

This design prevents mixing old usage and old policies into a new lifecycle when reusing a Session ID.

Fail Closed

The following conditions cause the system to fail closed, avoiding further dispatch when state is incomplete:

  • missing Host services
  • missing live Session
  • domain version mismatch
  • invalid stored records

Installation and Enablement

Verified materials do not provide official installation commands; therefore, this article does not provide installation commands and does not concatenate commands like dsh plugin add based on the repository name.

Confirm the Host version before enabling. The current version is:

0.1.1

Tested Host versions include:

0.1.0-rc.8
0.1.1-rc.2

Among them, testedHost is:

0.1.1-rc.2

The supported deployment form is:

one Host process per DSH_HOME

The plugin runs with the permissions of the current DSH process. Before installation, you should check the source code, license, and repository build process.

Typical Usage

Official web Typert remotes

The official web Typert can call the following remotes:

auxiliary-runtime/snapshot
auxiliary-runtime/cancel

These remotes are available on stock Host 0.1.1-rc.2.

auxiliary-runtime/snapshot is used to read snapshots, and auxiliary-runtime/cancel is used to cancel auxiliary calls.

In-process run service

The run service is available within the same process and remains private, not exposed to other Host plugins.

This means other Host plugins cannot directly reuse the in-process run service to initiate auxiliary calls.

Clarify optional usage

Clarify can use the in-process run service of Auxiliary Runtime to generate:

  • Context questions
  • Options
  • Evolving Draft previews

The key here is “outside the main Session transcript.” Clarify’s Q&A and Draft previews do not need to be written into the formal transcript of the main session.

SeekTTY optional usage

SeekTTY can consume read-only snapshots and display in /status when capable:

Official
Auxiliary
Combined

This usage is suitable for scenarios where it is necessary to distinguish official usage, auxiliary usage, and combined usage within the terminal status.

Suitable Scenarios and Notes

Suitable scenarios for using this plugin include:

  1. Need to perform no-tools auxiliary model calls within DSH.
  2. Need to bind auxiliary calls to an existing live Session.
  3. Need to limit concurrency, number of calls, and total auxiliary token amount per Session.
  4. Need to distinguish Official, Auxiliary, and Combined usage.
  5. Need to view auxiliary runtime status in /status or snapshots.

Boundaries that need attention include:

  • It does not replace the formal model routing of the main Session.
  • Clarify and SeekTTY are optional consumers, not installation requirements.
  • The plugin runs with the current DSH process permissions; check source code and license before installation.
  • Verified materials do not provide official installation commands; this article does not guess installation commands.
  • Combined usage is a consumer-side aggregated value and does not enter the official tokenUsage projection.

Links

Verified materials do not provide a directory page URL; this article does not guess the directory page address.

GitHub repository:

https://github.com/Hilbert-beinghappy/dsh-plugin-auxiliary-runtime