fix: report agent usage per provider round, not once per turn

[atishpatel]

The bug

buzz-agent emitted its usage_update notification in exactly one place: after ctx.run() returned. Until that moment a turn's token counters lived only in the prompt task's stack frame. A turn killed mid-flight reported nothing at all — the provider had already billed every round it completed, and no consumer ever saw any of it.

That is not a corner case for anything that ends a turn on a clock. It is the normal case for a long-horizon benchmark run that relaunches its agent between phases.

How big

Measured against a provider's own billing ledger over one run's window:

	provider ledger	what we recorded
the relaunched lead seat	$485 / 348M tok	$98.99 / 90.3M tok
the two seats that were not relaunched	$29.90 / 856M	$25.81 / 765M — reconciles

97% of that run's usage rows came back all zeros, against 1–4% for comparable runs that never relaunch. In one 450-phase trial exactly 7 phases recorded any usage — and each of those carries 177k–437k input tokens, a whole session's worth landing in the one phase that happened to end gracefully.

Worth being precise about what was not wrong, since both were plausible and both were checked:

• Not pricing. The rates were verified against the provider's endpoints API and match what we charge.
• Not a truncation bug. The usage files were intact and internally consistent. The tokens were never captured in the first place.

The fix

The run loop now emits a session-cumulative usage_update after every usage-bearing provider response, so an interrupted turn has reported everything but its single in-flight request.

• Emitting more than once per turn is already part of the contract. buzz-acp's UsageTracker advances its committed baseline only at publish time, and goose behaves the same way — which is why the tracker was written to tolerate it.
• The turn-start session baseline is snapshotted into RunCtx so the mid-turn figure stays session-cumulative. A turn-local number would be discarded by a high-water-mark consumer and lose the turn entirely; there is a test for exactly that.
• Snapshot by value, not a session handle. The loop reports once per round, and taking the sessions lock on each would serialise concurrent sessions behind one another's provider round-trips. Nothing else advances those counters while the turn holds busy, so it cannot go stale.
• One shared wire::usage_update_payload for both call sites, so the mid-turn and end-of-turn shapes cannot drift. A drift there would present as tokens silently vanishing, which is the failure this reporting exists to prevent.

Why not a SIGTERM handler

That was the obvious shape and it does not work. At signal time the counters are not sitting anywhere a handler could reach — they are in the turn's stack frame, and the value the handler would need has not been folded into the session yet. Making usage durable during the turn is what actually fixes it; once it is, a handler adds nothing beyond the in-flight request, whose cost is unknown until its response lands.

Tests

• usage_is_reported_after_each_round_not_only_at_turn_end — two rounds; asserts the first notification carries round 1's counts alone, proving it went out before round 2 returned.
• mid_turn_usage_includes_earlier_turns — a mid-turn report must be session-cumulative, not turn-local.

buzz-agent 18/18 on the fake_llm suite, 382 unit. cargo fmt / clippy / cargo check --workspace --all-targets clean.

Scope

Agent-side only, against main. The matching harness change — settling usage on the timeout path, which was skipped on the reasoning that an incomplete turn has nothing to flush — is #4553, against the benchmark branch, since that harness does not exist on main.

🤖 Generated with Claude Code

[wpfleger96]

I checked this against both the token-usage UI contract and NIP-AM. The per-round ACP notifications remain ephemeral telemetry: UsageTracker accepts multiple updates during one turn, keeps the prior published baseline frozen, lets the latest update win, and only advances turnSeq when take() publishes. This still produces exactly one durable kind-44200 usage event per completed turn.

The session-cumulative payload is the right shape for interrupted turns and preserves provenance: model identity, cached-input tokens, and genuine provider-reported totals remain intact rather than being reconstructed. The final end-of-turn notification is compatible with the intermediate updates.

Minimalism, elegance, and correctness all clear the gate: the baseline snapshot avoids per-round session locking, payload construction is centralized, and the tests cover multiple provider rounds plus prior-turn accumulation.

Non-blocking integration caveat: #4553 addressed settling this partial usage before the benchmark harness kills an agent on timeout, but it was closed without merge and I found no open replacement. That timeout-side fix still needs to land for LHTB accounting to benefit from the newly observable partial usage; it is not a defect in this PR.