[Bug] Chat context footer accumulates overlapping request totals and cannot correct inflated usage

Summary

The Windows Companion chat footer adds per-request token totals across assistant messages and displays the result as current context occupancy. A conversation with about 218K tokens can therefore show more than 1M / 100%. A subsequent authoritative session snapshot cannot correct the inflated value because the client takes Math.Max with its existing value.

Affected build

• Windows x64 native Companion.
• Installed PDB SourceLink identifies desktop commit 3c43751b2bace876de3febe478ebabeca172e3ac.
• Gateway: OpenClaw 2026.9.4 (3a9d69d), WSL2.
• Observed with opencode-go/glm-5.3-flash, configured context window 1,000,000.
• This report is verified against that installed build, not asserted against untested current main.

Reproduction

Use a thread with ContextTokens = 1,000,000 and successive assistant replies whose usage.totalTokens includes the request's existing prompt/history. In a deterministic fixture, create a separate assistant entry for each reply and feed these per-request totals:

The last value is presented against the 1M window with a clamped 100% percentage. These are six replies, not necessarily six user turns; tool workflows can produce multiple assistant messages.

Then deliver an authoritative session TotalTokens = 215950. The existing client retains 1198185. Deliver a lower post-compaction total such as 50000: it still retains 1198185.

Expected behavior

The context indicator should show the current context snapshot, not the cumulative number of tokens processed over multiple requests. Reused/cached history must not be counted as newly added context on each reply. A current, matching authoritative snapshot must be able to correct an inflated value or reflect compaction.

Cumulative token consumption is useful, but should be a separately named metric.

Code path

All links are pinned to the installed build:

1. OpenClawGatewayClient.ExtractChatUsage maps usage.totalTokens into ResponseTokens.
2. SnapshotAssistantUsageContributionLocked computes Math.Max((previousUsage ?? 0) + currentUsage.Value, existing?.ResponseTokens ?? 0).
3. SnapshotLatestAssistantUsageLocked takes Math.Max(usedTokens, existing?.ResponseTokens ?? 0), preventing downward correction.
4. ChatUsageFormatter renders this against ContextTokens.
5. The existing test ChatMessageReceived_AssistantFinal_AccumulatesUsageAcrossAssistantMessages explicitly expects 27 + 25 = 52, which encodes cumulative consumption rather than context occupancy.

Validation performed

This was not only a spreadsheet simulation: a local isolated PowerShell/.NET reflection harness invoked the two private methods in the original installed DLL, using synthetic in-memory timelines/metadata and the numeric inputs above. It reproduced accumulation, failure to correct the inflated snapshot, and failure to reflect a lower post-compaction snapshot.

A narrowly scoped local IL hotfix changed the two methods to use the latest usage/snapshot rather than add previous usage or retain Math.Max, and discarded stale percentages so the formatter recomputes them. The patched DLL passed 12 checks: six successive replies, duplicate update, authoritative downward correction, post-compaction decrease, stale-percentage refresh, a new response after compaction, and zero-usage handling. After installing locally, the user reported that the displayed result looked correct.

This is targeted method-level validation plus a local startup/reconnect check, not a full upstream build/test-suite run. No patched binaries are attached.

Suggested fix / acceptance criteria

• Separate current context occupancy from cumulative token consumption.
• Preserve message/run ordering and duplicate-event protection, but do not sum overlapping request contexts.
• Permit newer authoritative session usage to decrease; stale event protection should use identity/order rather than a numeric maximum.
• Keep percentages coherent with the chosen snapshot, including after compaction.
• Add coverage for multiple replies, duplicate events, session refresh/reconnect, and compaction decreases.

There were also intermittent UI hangs/layout exceptions and provider timeouts in the environment, but their causal relationship to this counter defect has not been established. This issue reports only the reproducible counter defect.

No credentials, chat text, personal configuration, or session databases are included.

Start with SnapshotAssistantUsageContributionLocked and SnapshotLatestAssistantUsageLocked in src/OpenClaw.Tray.WinUI/Chat/ChatConversationState.cs, then inspect OpenClawGatewayClient.ExtractChatUsage and ChatUsageFormatter.cs. Run OpenClawChatDataProviderTests, especially ChatMessageReceived_AssistantFinal_AccumulatesUsageAcrossAssistantMessages. Done means overlapping request totals no longer inflate context occupancy, newer authoritative snapshots can decrease it, percentages remain coherent, and duplicate or compaction cases are covered.