[Feature]: Expose per-session token/cost usage in a documented, easy-to-read form

[258692011]

[Feature]: Expose per-session token/cost usage in a documented, easy-to-read form (currently only internal projection JSON + zstd-compressed JSONL)

Repo: deepseek-ai/deepseek-harness (portable Windows build)
Provider/Model: DeepSeek official, deepseek-v4-flash

Summary

While auditing how many tokens/money an agent session consumed on a pay-per-token DeepSeek account, the only machine-readable usage data on disk is:

1. <dsh data>\storages\session_projcache\sessions\<sessionId>.json — a plain JSON projection containing an aggregate rows.tokenUsage.totals (uncachedInputTokens, cacheReadTokens, cacheWriteTokens, outputTokens) plus context breakdown. Useful, but internal/undocumented and aggregate-only.
2. <dsh data>\sessions\<workspace>\<sessionId>\session.jsonl.zstd — the full lossless record log, zstd-compressed (readable via node:zlib zstdDecompressSync). Contains everything but requires custom tooling; no bundled, documented CLI/GUI path to export usage was found.

There is no supported way for a user/script to get a per-request usage ledger (per-call uncached / cache-hit / output tokens with timestamps and model) or an estimated cost, even though the data is already collected.

Example (real measurement, 2026-09-04)

One long agentic session showed, via the projection JSON:
uncachedInputTokens ≈ 106,000, cacheReadTokens ≈ 5,500,000, outputTokens ≈ 85,000 (i.e. ~98% of input billed at the cache-hit rate). To explain/verify that number to the account holder we had to decompress the JSONL and re-derive everything ourselves; per-request attribution (which step/tool call cost what) was not practically accessible.

Request

1. Document the projection JSON and/or the session log layout (schema, meaning of cacheReadTokens vs uncachedInputTokens under DeepSeek caching semantics).
2. Add a supported export (GUI "export session", CLI flag, or a small documented reader) that includes per-request usage: timestamp, model, uncached input, cache-hit input, output tokens — optionally with estimated cost using the provider rate card.
3. Ideally surface a live per-session token/cost readout in the UI for pay-per-token users.

Why it matters

Users on billed DeepSeek accounts currently cannot answer "what did this session cost / which turn burned tokens" from the product itself; they must reverse-engineer internal files. This is the DeepSeek Harness counterpart of proper usage telemetry and would make cost behavior auditable.

Environment

• DeepSeek Harness portable Windows build (data dir C:\DeepSeek-Harness-Portable\data\dsh)
• Session projections written under storages/session_projcache/sessions/, record logs under sessions/<workspace-slug>/<sessionId>/session.jsonl.zstd