Timed-out sessions are journalled with tokens: 0, hiding the most expensive sessions from status, metrics and max_tokens_per_story

[wsquared]

Summary

A session that ends by timeout is journalled with tokens: 0 and tokens_weighted: 0, so the run total, per-story cost, max_tokens_per_story and any digest built on the journal omit the most expensive sessions of the night.

Observed (0.11.1)

Setup: an unattended nightly sweep run with [limits] session_timeout_min = 180, max_dev_attempts = 2 and [scm] isolation = "worktree"; the dev adapter is Claude Code.

session-end  <story>-dev-1  status: timeout  tokens: 0  tokens_weighted: 0
session-end  <story>-dev-2  status: timeout  tokens: 0  tokens_weighted: 0

The Claude transcripts of those two 3-hour sessions and their subagents sum to 114,498,346 raw tokens, 14.7M weighted at cache_read_weight = 0.1 (deduplicated per message id; a transcript repeats a response's usage once per content block). bmad-loop status reports the run at 41,460,533 raw, all from the one story that completed: the timed-out story was about 73 percent of the night's spend and shows as zero.

Consequences: max_tokens_per_story cannot fire for the sessions most likely to exceed it; status, metrics and the digest undercount by the full cost of every timeout; and #611's zero-token heuristic would classify a fully productive 3-hour session as an environment fault.

Proposal

On a timeout / stalled / over_budget verdict, read usage from the adapter's transcript for the session and its children, as a completed session's usage is read after usage_grace_s. The transcript is on disk before the kill (straggler-reap follows timeout-fired by ~200 ms). If the read fails, journal tokens: null rather than 0, so an absent measurement is distinguishable from a free session.

[wsquared]

Contained downstream in our digest rather than in the harness, in case the shape or the measurements are useful.

The digest now classifies each story before costing it. A story is unmeasured when its journalled sessions sum to nothing and at least one ended timeout, stalled or over_budget; only then is its cost read from that unit's transcripts. Both halves matter: without the status test, a story that genuinely spent nothing would have a cost invented for it, which is the mirror of the bug.

Three decisions that were not obvious going in:

• Never sum the two sources. The journal counts sessions; the transcript directory covers a whole unit worktree, every attempt included. Adding them double-counts every session that did report. So a story with one completed session and one timed-out session keeps its journalled total and takes no transcript path at all. That accepts an undercount in the mixed case as the lesser error, which is worth stating out loud because it is the one case the fix deliberately does not repair.
• The two sources disagree even when both work. On the same run, a healthy story journalled 31,172,609 raw against 27,702,669 from its transcripts. That gap is the reason the units cannot be mixed in one column, and the recovered figure is labelled with its unit where it renders.
• tokens_total is left alone. Recovered cost lands in a separate tokens_from_transcripts field, so historical rows stay comparable and nothing silently changes meaning.

Confirming the numbers in the report, computed with per-message-id dedupe and cache reads at 0.1: the deferred story's 14 transcripts sum to 114,498,346 raw / 14,733,285 weighted, against the tokens: 0 in its journal. The run total stayed at 41,460,533.

On the proposal itself, the tokens: null half is the part we could not emulate. Downstream we can only infer "measurement lost" from status plus a zero, which is why the status test above is load-bearing. If the harness journalled null for an unread measurement, the distinction between a free session and an unmeasured one would be readable directly, and every consumer including max_tokens_per_story would get it rather than just the digest.