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

[Si1as-code]

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:

Reply	Request total	Current client result
1	186213	186213
2	188019	374232
3	193639	567871
4	195686	763557
5	217082	980639
6	217546	1198185

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.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed September 16, 2026, 12:58 PM ET / 16:58 UTC.

Summary
Current main and v2026.9.4 retain the reported counter defect. The source and existing tests support a focused repair, and no open PR was found that owns it.

Reproducibility: yes. from source: the reported request totals exercise the accumulation path, followed by lower session snapshots that Math.Max rejects. This read-only review did not execute the app, builds, or tests.

Next step
Route one focused repair for the source-proven accounting defect, with no new settings or cumulative-usage UI.

Review details

Best possible solution:

Keep context occupancy as a freshness-checked snapshot, separate from cumulative consumption, with coherent token counts and percentages after refresh and compaction.

Do we have a high-confidence way to reproduce the issue?

Yes, from source: the reported request totals exercise the accumulation path, followed by lower session snapshots that Math.Max rejects. This read-only review did not execute the app, builds, or tests.

Is this the best way to solve the issue?

Yes to snapshot-based accounting, but the reported two-method hotfix is incomplete as an upstream solution unless cached-session fallback and stale percentages are handled together.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• A mechanical replacement of Math.Max would let cached session data overwrite newer assistant usage; freshness and duplicate handling need regression coverage.

Codex review notes: model internal, reasoning medium; reviewed against 3c43751b2bac.

Label changes

Label changes:

• add P2: This is a source-proven display defect with limited blast radius; no blocked chat workflow or actual context loss is established.
• add impact:ux-friction: Inflated context totals and a stuck 100% indicator mislead users about remaining model capacity.
• add issue-rating: 🦞 diamond lobster: Current issue advisory state selects this label.
• add clawsweeper:source-repro: Current issue advisory state selects this label.
• add clawsweeper:queueable-fix: Current issue advisory state selects this label.
• add clawsweeper:fix-shape-clear: Current issue advisory state selects this label.

Label justifications:

• P2: This is a source-proven display defect with limited blast radius; no blocked chat workflow or actual context loss is established.
• impact:ux-friction: Inflated context totals and a stuck 100% indicator mislead users about remaining model capacity.

Evidence reviewed

Acceptance criteria:

• ./build.ps1
• dotnet test ./tests/OpenClaw.Shared.Tests/OpenClaw.Shared.Tests.csproj --no-restore
• dotnet test ./tests/OpenClaw.Tray.Tests/OpenClaw.Tray.Tests.csproj --no-restore
• dotnet test ./tests/OpenClaw.Tray.Tests/OpenClaw.Tray.Tests.csproj --no-restore --filter "FullyQualifiedNameOpenClawChatDataProviderTests|FullyQualifiedNameChatUsageFormatterTests|FullyQualifiedName~ChatConversationStateTests"

What I checked:

• Current main matches the affected release: The checkout, live main branch, and peeled v2026.9.4 tag all resolve to 3c43751, the installed source revision reported by the author. (3c43751b2bac)
• Overlapping request totals are accumulated: ExtractChatUsage maps usage.totalTokens into response usage. SnapshotAssistantUsageContributionLocked adds that value to the previous assistant snapshot and retains the maximum. The reported six inputs therefore reach 1,198,185 instead of preserving the latest request snapshot. (src/OpenClaw.Tray.WinUI/Chat/ChatConversationState.cs:2239, 3c43751b2bac)
• Session correction and percentage defects: SnapshotLatestAssistantUsageLocked takes Math.Max against existing response usage and preserves the existing ContextPercent. The formatter can prioritize that percentage over token counts, so correcting only the addition would leave stale display state. (src/OpenClaw.Tray.WinUI/Chat/ChatConversationState.cs:511, 3c43751b2bac)
• Cached session fallback must remain freshness-safe: After processing assistant usage, every assistant final calls SnapshotLatestAssistantUsage using the cached session. Removing the numeric maximum without distinguishing this fallback from a fresh session update could replace new usage with an older snapshot. (src/OpenClaw.Tray.WinUI/Chat/OpenClawChatDataProvider.cs:1440, 3c43751b2bac)
• Existing tests encode the faulty behavior: The provider tests explicitly expect 27 + 25 = 52 across assistant messages and prohibit lower session usage. Formatter tests separately identify the displayed metric as context usage. Regression coverage must replace the accumulation expectations while preserving duplicate-event protection. (tests/OpenClaw.Tray.Tests/OpenClawChatDataProviderTests.cs:11385, 3c43751b2bac)
• Historical design context: The merged Show chat usage in assistant timestamp footer #551 (Show chat usage in assistant timestamp footer) explicitly intended monotonic snapshots. The repair should preserve its protection against stale data through freshness checks, while allowing legitimate decreases. The continuation Show chat usage in assistant timestamp footer #725 (Show chat usage in assistant timestamp footer) is closed unmerged and is not a fix candidate. (ff38d8499c48)

Likely related people:

• kenehong: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)
• karkarl: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.