Context doesn't match with compaction

[buraktamturk]

The side bar at the right shows context is 879k, the bottom bar also shows the same when over scrolled. But when I issue /compact command I get the following:

Requesting compaction...

Context Status:
• Messages: 1036 (active), 56181 (total history)
• Token usage: ~396k (estimate ~370k) / 976k (40.6%)
• Has summary: yes
• Compacting: no

📦 Compacting context (manual) — summarizing older messages in the background to stay within the context 
window.
The summary will be applied automatically when ready.

📦 Context compacted (manual) - older messages were summarized to stay within the context window.

Took 36s · before ~396,674 tokens · now ~23,244 tokens (2.4% of window) · saved ~373,430 tokens ·
summarized 1,026 messages · summary 11,371 chars · kept 8 recent messages live

and the stats are not updated (the same), and next prompt brings the stats on both places to "503k" on the next prompt.

I don't know which is broken.

[1jehuang]

Triage: thanks for the detailed numbers. There appear to be two separate estimators disagreeing:

1. The sidebar/status bar figure (879k) comes from the last provider-reported stream usage (current_stream_context_tokens / effective_context_tokens_from_usage).
2. /compact's "Context Status" (~396k) is a local estimate over the active message list.

A 2.2x divergence plus the post-compaction jump to 503k on the next prompt suggests the stream-usage-derived number is not being reset/recomputed after compaction replaces the active messages with a summary, or that cache-read tokens are being counted differently between the two paths.

To pin it down, could you share:

• provider/model in use (cache-heavy providers report cache_read_input_tokens that some paths may double-count)
• whether the sidebar number ever corrects itself after 2+ prompts post-compaction
• ~/.jcode/logs/jcode-YYYY-MM-DD.log lines around the compaction (grep for compact)

Labeled as a bug. We'll audit the two token paths for consistency after compaction regardless.

[1jehuang]

Fixed on master in 12d7afba (merged in cc91b179).

Two real bugs behind the mismatch:

1. Stale stream usage after compaction. The sidebar figure comes from the last provider-reported usage, which described the pre-compaction message list. After compaction replaced the messages with a summary, the sidebar kept showing the old figure (your 879k). Compaction now marks the stream-derived figure stale, so the display falls back to the local estimate over the new active messages until the next provider usage report arrives.

2. Stale cache counters across calls. Some gateways (deepseek via opencode go included) only report cache_read_input_tokens on some calls. The old code merged cache counters across calls, so a stale cache-read figure from a previous call could be added on top of a new call's input tokens, inflating the display (part of why the number jumped to ~503k post-compaction instead of dropping). Counters now reset wholesale on the first usage report of each new call.

Also unified the three duplicated cache-accounting heuristics (sidebar, compaction manager) into one shared function with tests covering split (Anthropic-style) vs subset (OpenAI-style) accounting, so the sidebar and /compact can't drift again.