fix(cli): show live session spend in TUI sidebar during active turn

[mvanhorn]

Issue

Fixes #11480

Context

The TUI sidebar showed live spend as $0.00 while an assistant turn was still running, even though token count and context percentage updated live. session.cost is only the persisted session aggregate, which is stale until the turn finalizes, so the sidebar read 0 mid-turn.

Implementation

In sidebar/context.tsx, the cost memo now sums cost across the live assistant messages and takes Math.max of that against session()?.cost. During an active turn the per-message sum leads; once the aggregate is persisted it wins (or ties), so the displayed value never regresses. This mirrors how the adjacent tokens / context-percent memos already derive from the live message list rather than the session aggregate. Client-only change; no server or protocol changes.

Screenshots

before	after
sidebar "spent" reads $0.00 during an active turn	sidebar "spent" reflects accumulating cost during the turn

N/A for a static capture in this environment — the change is a derived-value calculation in the sidebar memo. See verification below.

How to Test

Manual/local verification

• Start a TUI session, send a prompt, and watch the sidebar "spent" line during the assistant turn: it now climbs with the running cost instead of staying at $0.00, and settles at the session total when the turn finalizes.

Reviewer test steps

1. Open the TUI and start an assistant turn that incurs cost.
2. While the turn is still streaming, observe the sidebar "spent" value.
3. Confirm it shows a non-zero, increasing value mid-turn and matches the session total after completion.

Blocked checks and substitute verification

• bun test ./test/cli/tui/usage.test.ts could not complete in this environment (missing @opentui/solid/preload, an environment/runtime dependency unrelated to the change). Substitute verification: reviewed that cost now derives from the same msg() live-message list the existing tokens/context memos use, and that Math.max preserves the persisted aggregate so the value is monotonic across turn finalization.

Checklist

• Issue linked above, or exception explained
• Tests/verification described
• Screenshots/video included for visual changes, or marked N/A
• Changeset considered for user-facing changes
• I personally reviewed the diff and can explain the changes, including any AI-assisted work.

Get in Touch

AI was used for assistance.

[kilo-code-bot]

Code Review Summary

Status: No Issues Found | Recommendation: Merge

Files Reviewed (2 files)

• .changeset/tui-live-spent-cost.md
• packages/opencode/src/cli/cmd/tui/feature-plugins/sidebar/context.tsx

---

_{Reviewed by gpt-5.4-20260305 · Input: 55.5K · Output: 5.4K · Cached: 302.1K}

_{Review guidance: REVIEW.md from base branch main}

[truffle-dev]

This lands on the right layer. `session().cost` is the persisted aggregate that only moves on a `session.updated.1` event or a full session-list load, so it stays stale for the whole in-flight turn while the per-message cost is already arriving live. Summing `item.cost` across the assistant messages reads those same live values the adjacent `state` memo already derives from `msg()`, so the sidebar stays internally consistent with the token/context line right next to it.

The `Math.max` is the right guard, not just a tiebreak: if the client is holding a truncated message window, `total` can undercount and the persisted aggregate wins, so the displayed value never regresses below the session total. Mid-turn `total` leads and climbs; once the projector persists the aggregate they converge. Matches the traced root cause exactly.

[mvanhorn]

Thanks for tracing it to that layer so precisely. That matches what I saw: mid-turn the summed item.cost leads and climbs, then converges to the persisted aggregate once session.updated.1 lands, and the Math.max keeps the displayed value from regressing below the session total when the client is holding a truncated message window. Appreciate the careful read.

[shssoichiro]

I can confirm this resolved the issue for me.

[YannickDurden]

This fix will be ship with the next release? My Kilo version is 7.4.1 on MacOS and I've the bug too. Thanks mate 👍

[mvanhorn]

It merged after 7.4.1 was cut, so it should land in the next release. Until then 7.4.1 still has the bug, no workaround needed once you update.