The DeepSeek Harness session log as a cost record

Published 16 August 2026

Most agent cost tracking is bolted on. You wrap the provider SDK, emit a span, hope nobody adds a second call path, and discover six weeks later that the subagent traffic never got instrumented. DeepSeek Harness takes a different route: the session log is the primary artefact, and token accounting rides inside it.

The session is an append-only event log

The docs put it directly: a Session is an append-only log of typed SessionEvents, and it is the single source of truth for an agent's whole interaction history. Every event carries four fields:

Surface events carry two more: sourceEventSeqs, referencing the events they derive from, and surfaceOp, describing how the event enters the message surface.

The events a cost model cares about

• turn/start and turn/end — open and close a turn, the latter with a TurnEndReason. A turn is the user-facing unit of work.
• step/start and step/end — a step is one model call plus its tool calls. This is the billing unit.
• assistant/message — model output, with optional TokenUsage attached.
• assistant/chunk — raw stream tokens, kept for replay fidelity. Usage arrives here as chunks of type usage.
• tool/call and tool/result — the model's tool invocation and its outcome, the latter with an optional meta payload.
• request/header — the full EpochHeader: config, system prompt, and tool set for the request.
• request/context — route metadata: provider, model, context window.

That last pair is the piece most homegrown telemetry misses. request/context tells you which provider and model actually served the step, and request/header tells you what was sent. Together they let you reconstruct the cost of a step from the log alone, without trusting a separately maintained pricing lookup keyed off an assumed model.

Usage travels with output

The docs are careful about this: an assistant/message carries the step's usage when the adapter reported token accounting, so the model output and its accounting travel together. The reader prefers per-step assistant/chunk { type: 'usage' } records and falls back to assistant/message.usage.

The practical effect is that you cannot end up with orphaned usage numbers you can no longer attribute to a step, which is the single most common defect in retrofitted agent cost tracking.

Derived history, not duplicated history

Message history is derived from surface events and never stored separately. The projection rules are simple: user/message becomes a user message, assistant/message becomes an assistant message with raw chunks skipped, tool/result becomes a user message carrying a tool-result block. Everything else stays log-only.

For a FinOps team this is the useful property. There is one place to read, and reading it does not risk disagreeing with what the model actually saw.

What to build on top

1. Join step/start and step/end to get step duration and count per turn. Step count per turn is your orchestration multiplier, and it is the number that surprises finance.
2. Attach request/context to each step for the provider and model, then price the usage from the same step's assistant/chunk usage record.
3. Count tool/call events per step. High tool-call fan-out per step is where latency and retry cost concentrate.
4. Watch TurnEndReason distributions. Turns ending for reasons other than completion are paid-for work that produced nothing.

Related

• DeepSeek Harness: what "everything is a plugin" buys you — the seam model underneath.
• Where to put spend guardrails in DeepSeek Harness — acting on what the log shows.
• OpenTelemetry GenAI conventions — the standard-based alternative.
• What is LLM cost attribution — the underlying discipline.

Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit →

Back to research