Usage & Billing

dsh-session-audit

bwndlct/dsh-session-audit · ★ 3

bwndlctCurated

Session execution analytics: steps, tool calls, failures, repeated actions, token usage and verification signals, rendered as text/Markdown/JSON reports.

License
MIT
Added
2026-08-14
Maintenance
active
Install kind
github
Manifest status
Declared
Manifest path
package.json#dsh
Manifest checked
2026-08-19
Lifecycle scripts
None found

Static manifest checks report declarations only; they are not compatibility or security review.

安装

dsh plugin --profile web add github:bwndlct/dsh-session-audit

GitHub 源码安装:首次需按提示配置 allowBuilds 构建授权后重试

For install and environment setup, plus plugin development tutorials, see DSH community docs ↗

README

Source README · body: en · Read Chinese README

Table of contents
  1. Why
  2. Features
  3. Installation
  4. Usage
  5. Audit Signals
  6. Verification Detection
  7. How it works
  8. Privacy
  9. Development
  10. Compatibility
  11. Limitations
  12. Roadmap
  13. Existing alternatives
  14. License

Understand how your DeepSeek Harness agent actually worked.

Inspect steps, tool calls, failures, repeated actions, token usage and verification signals for one DSH session — rendered as a readable audit report by a single session_audit tool call.

简体中文 | English

DSH Session Audit
──────────────────────────────────────────────

Session
ID              session-d2309fa2-47d3-484a-8357-236e0acdd9aa
Model           glm-5.3
Provider        zai-coding-cn
Duration        51m 42s
Started         2026-08-14T09:08:08.384Z

Execution
Turns           4
Steps           121
Assistant msgs  120
Turn endings    completed×1, interrupted×1, error×1

Tools
Total calls     150
Succeeded       143
Failed          6
Unresolved      1
Failure rate    4.0%

Top tools
  bash                  83  (1 failed)
  write                 26
  edit                  21  (4 failed)
  read                  12

Tokens
Input           349,428
Output          80,415
Cache read      9,243,520
Total           9,673,363

Execution signals
  ⚠ 3 consecutive failed tool calls detected
  ⚠ `bash` called 83 times
  ℹ session has a turn that never closed

Verification
  ✓ pnpm run typecheck  [typecheck]
  ✓ npm test  [test]  (2 attempts, 2 ok)

(real report from a live machine session)

Why

DSH sessions already record what happened — the session log is the append-only source of truth. But reading a 1000-event log does not answer the questions you actually have after an agent run:

How long did this take? How many turns and steps? Which tools dominated? Where did it fail? Did it repeat the same calls? Was anything verified?

dsh-session-audit folds one session's durable event log into those answers. It is a step / tool-call profiler and failure analyzer, not a token dashboard (see Existing alternatives).

Features

  • Session metrics — duration, turns, steps, assistant messages, tool call totals, per-tool distribution, success/failure split.
  • Token usage — input / output / cache buckets folded per model step exactly like the official session-stats projection; reported as unavailable (never estimated) when the provider logged no usage.
  • Deterministic audit signals — consecutive failures, failure rate, high-frequency tools, identical repeated calls (key-order insensitive), repeated reads of the same file. Rule-based only; no LLM judgement.
  • Verification detection — recognizes test/build/lint/typecheck commands (npm test, pytest, cargo test, tsc, eslint, …) inside shell tool calls and reports their observed outcomes.
  • Three formats — text (default), Markdown, JSON with a stable schemaVersion you can build on.
  • Live or historical — audits the current session in memory by default, or any durable session by id; lists recent sessions for discovery.
  • Robust — empty sessions, malformed events, unknown future event types, orphan results, torn crash-tail log frames: all handled without crashing, and surfaced as data-quality notes.

Installation

Requires dsh (@deepseek-ai/dsh) 0.1.0-rc.6+.

# from npm (once published)
dsh plugin --profile web add dsh-session-audit

# from GitHub
dsh plugin --profile web add github:bwndlct/dsh-plugins/plugins/dsh-session-audit

# local development (link)
dsh plugin --profile web add link:/path/to/dsh-plugins/plugins/dsh-session-audit

Then add the package to the profile's dsh.profile.bundles array in ~/.dsh/profiles/web/package.json (the install command above does not do this step):

"dsh": {
  "profile": {
    "bundles": [
      // ...existing entries...
      "dsh-session-audit"
    ]
  }
}

Restart dsh (dsh web). Verify the mount:

dsh --profile web --dump-config | grep -A2 session-audit

Usage

In a session, ask the agent (it will call the tool), or use the slash commands in interactive profiles:

  • audit this session — audits the current session.
  • audit session session-abc123 — audits a stored session by id.
  • list recent sessions — lists durable sessions to pick from.
  • audit this session as markdown / as json — picks the format.

Slash commands (available when the commands service is mounted, e.g. web profiles):

  • /session-audit [text|markdown|json] — audit the current session (empty for text).
  • /audit-list — list recent durable sessions.

Tool parameters:

parameter type meaning
session_id string target session (default: current session)
format text | markdown | json report format (default text)
list_sessions boolean list recent sessions instead of auditing
thresholds object optional overrides for audit rule thresholds (shallow-merged with defaults)

The report stays local — it is returned as the tool result for you and the model to read; nothing is written to disk.

Audit Signals

All rules are deterministic and threshold-driven; every threshold lives in one place (src/rules/thresholds.ts) and defaults are conservative so a normal session does not drown in warnings.

Signal Severity Default threshold
consecutive failed tool calls warning ≥ 3
overall tool failure rate warning ≥ 15% over ≥ 3 resolved results
identical tool call repeated warning ≥ 3 occurrences (arguments compared with sorted keys — JSON key order never hides a duplicate)
same file read repeatedly info / warning ≥ 4 reads (warning ≥ 8); reader tool + argument name configurable (read/read_file → file_path by default)
high-frequency tool info / warning ≥ 15 calls (info), ≥ 30 (warning)
turn ended non-completed info any aborted / error / interrupted ending
open turn info live/interrupted session indicator
no verification command detected info careful wording — absence of evidence, not evidence of absence
verification command failed warning last observed attempt failed
repeated verification failures warning ≥ 2 failed attempts, none succeeding after

There is deliberately no efficiency score — the report states facts and deterministic findings; judging them stays with you.

Verification Detection

The rules recognize common verifiers inside shell tool calls (bash / pwsh, configurable):

  • test: npm|pnpm|yarn|bun (run) test*, pytest, cargo test, go test, dotnet test, jest, vitest, mocha, mvn|gradle test, make test
  • lint: (npm|pnpm|yarn|bun) (run) lint*, eslint, biome, prettier, ruff, pylint, flake8, golangci-lint
  • typecheck: (npm|…) typecheck*, tsc, mypy, pyright, cargo check
  • build: (npm|pnpm|yarn|bun) (run) build*, cargo build, go build, dotnet build, make build|all

Success is decided from what was actually observed in the tool result: a harness-level error, or the documented [exit code: N] marker that dsh-tool-bash appends for non-zero exits, marks the attempt failed. A matched command with no durable result is treated as not observed, not as a failure. When no verifier is seen at all, the report says exactly that — it never claims the agent "did not verify", because verification may have run through a mechanism the log cannot show.

How it works

DSH session (live registry or ~/.dsh/sessions durable log, zstd frames)
        │  session-reader — direct stat by session id (dir name IS id),
        │                    header-frame-only decode for listing, full decode
        │                    for audit; fallback scan when dir name ≠ header id
        ▼
session-adapter — raw events → normalized AuditEvent vocabulary
        ▼
analyzer — one O(n) pass: counts, tool pairing, usage fold (per turn:step,
           usage chunk superseded by final assistant/message usage)
        ▼
rules — deterministic signals from the folded facts
        ▼
SessionAuditReport (schemaVersion 1.0) — text / markdown / json
  • Turn/step counting mirrors the official dsh-session-stats semantics (steps = step/end count; turns = distinct turns with a closed step), so audit numbers agree with the Web UI stats strip.
  • Token buckets follow TokenUsage from dsh-llm: input excludes cached input; cache read/write are separate; reasoning (a subset of output) is reported but never added into totals.
  • DSH event-shape knowledge is confined to the adapter; the analyzer and rules depend only on the normalized vocabulary.

Privacy

dsh-session-audit performs local analysis only. It reads session logs from this machine's DSH home and the live in-memory session registry. It makes no network requests, calls no LLM APIs, sends no telemetry, and collects nothing about you. Reports exist as tool-call results inside your own session.

Development

cd plugins/dsh-session-audit
npm install --no-save            # typescript + @types/node for tooling
npx tsc -p tsconfig.json         # typecheck + build to lib/
node --test tests/               # 32 unit tests

Layout:

src/
  index.ts               tool registration + live/disk session loading
  dsh/
    session-adapter.ts   raw DSH events → normalized audit events
    session-reader.ts    durable-log discovery, zstd decode, JSONL parse
  audit/
    analyzer.ts          O(n) fold + rule orchestration
    types.ts             SessionAuditReport schema, AuditEvent vocabulary
  rules/                 one file per rule + centralized thresholds
  formatters/            text / markdown / json
  utils/                 stable-json (sorted-key identity), duration
tests/                   node:test suites: analyzer, rules, edge cases, reader

Compatibility

  • Verified against @deepseek-ai/dsh 0.1.0-rc.6 (session format version 0).
  • Reads both compressed (session.jsonl.zstd, default) and plain (session.jsonl) durable logs.
  • SESSION_FORMAT_VERSION is pre-release; a future format bump will need an adapter update — which is why all shape knowledge lives in one place.

Limitations

  • Verification matching is pattern-based; a verifier wrapped in an unusual script name is not recognized.
  • Sub-agent sessions are audited individually (by id); there is no cross-session rollup yet.
  • Reasoning tokens are reported when the provider supplies them, but the per-step values of some providers cannot be reconstructed.
  • No time-series or context-growth analysis yet (roadmap).

Roadmap

  • v0.3 — session compare
  • v0.4 — context growth analysis
  • v0.5 — HTML report
  • later — web dashboard views, cross-harness audit

Existing alternatives

Token/cost dashboards already exist (dsh-spend, dsh-balance-stats, dsh-session-cost, dsh-token-monitor) and are complementary: they answer how much did I spend. This plugin answers how did the agent work — execution shape, failure locations, repetition, verification. As of v0.2.0 no other plugin in the dshplugin ecosystem covers single-session execution audit.

License

MIT