mecatui: context and token counters are not restored on session resume #1822

Summary

When resuming a session with mecatui --resume-latest, the status line's context meter and token counters start empty and only reappear after the first prompt. When they come back, they only reflect the new run, not the resumed session. In one case the context reading after resume was much lower than before quitting, which suggests the counters (and possibly the context sent to the model) don't match the session being resumed.

Steps to reproduce

1. Run a session long enough to build up significant context. Note the ctx reading in the status line, then /quit.
2. Resume with mecatui --resume-latest.
3. Look at the status line before sending anything: the ctx/usage area is empty.
4. Send a prompt and look at the status line after the turn ends.

Observed

Before /quit:

ctx 100% ⚠ · 135.2K/128K (the reading above 100% comes from our gateway misreporting the model's context window and isn't related to this issue)

After resume, no counters until the first prompt. After the first prompt:

ctx 35% · 45.7K/128K · ↑45.7K ↓163 ⊕45.7K cache 0%

No compaction seemed to happen on resume. There was none of the usual compaction delay.

Expected

• On resume, the status line shows the resumed session's context occupancy and cumulative token usage (and the context window) right away, before any new prompt.
• After the first post-resume turn, cumulative totals continue from the session's prior totals instead of restarting from zero.

Notes from the code

• Both counters are populated only from live stream events. m.contextTokens is set from TurnEndMsg.Usage.InputTokens (cmd/mecatui/ui/update.go:1166-1168) and m.usage is summed from ResultMsg.Usage in applyResult (cmd/mecatui/ui/update.go:1637). Nothing on the resume path (applySessionReady / finishStartupResume) seeds them from the stored session, so they start at zero until a turn completes.
• The post-resume 45.7K is not a stale or reset value. It is the provider-reported input size of the first turn after resume (↑45.7K matches it). So that turn really sent ~46K input tokens, against ~135K reported for the last turn before quitting. Open question: is the resumed session's request history smaller than before /quit (something dropped or trimmed on reload), or was the pre-quit figure inflated? cache 0% on that turn also suggests the prompt prefix didn't match what was cached before. That could be a changed history or just an expired cache.

Related

Separately, the counters only update when a run ends, not during it. Live updates mid-run would be a nice follow-up but are out of scope here.