Battery drain + slowdown with multiple concurrent sessions

[samanthamsong]

Problem: Running multiple concurrent sessions causes noticeable battery drain and system slowdown.

Impact: Performance / power — degrades the experience for users running several agent sessions.

Repro: Start multiple sessions and observe CPU/battery over time.

Epic: should ladder up to #837 (S4 - Secure & contained / MXC).

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed July 1, 2026, 4:55 PM ET / 20:55 UTC.

Summary
Keep open. Current main has partial mitigations around node invoke concurrency and session preview traffic, but there is no measured Windows multi-session CPU/battery proof showing the central performance/power problem is solved, and no narrower canonical issue or merged PR owns the remaining symptom.

Reproducibility: no. the report gives only a broad "start multiple sessions and observe CPU/battery" path. A high-confidence reproduction needs session count, workload, duration, baseline, Windows build, logs, and CPU/battery measurements.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.

Next step
Needs maintainer/performance triage before automation because the hotspot and acceptable throttling behavior are not known yet.

Review details

Best possible solution:

Collect measured Windows multi-session performance proof first, then tune the concrete hotspot with regression coverage and MXC-specific validation if containment/session policy is involved.

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

No; the report gives only a broad "start multiple sessions and observe CPU/battery" path. A high-confidence reproduction needs session count, workload, duration, baseline, Windows build, logs, and CPU/battery measurements.

Is this the best way to solve the issue?

Unclear; current main already has some concurrency and preview throttles, so profiling should decide whether the fix belongs in node invoke limits, chat history loading, session preview traffic, reconnect behavior, or MXC session policy.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• No live Windows multi-session soak, CPU profile, battery baseline, session count, workload, or duration is available yet.
• The measured hotspot could be node invoke concurrency, chat history/previews, reconnect or health traffic, gateway behavior, or MXC session policy, so a premature throttle could delay or reject valid agent work.
• The open chat timeline virtualization PR may help large-chat UI rendering, but it does not prove the reported battery drain and concurrent-session slowdown are fixed.

Codex review notes: model internal, reasoning high; reviewed against 8b857ecbb1f5.

Label changes

Label justifications:

• P2: This is a current performance/power report affecting multi-session users, but it lacks evidence of data loss, security bypass, crash loop, or an urgent confirmed regression.
• impact:other: The concrete impact is battery drain and system slowdown, which is maintainer-visible but outside the owned data-loss, security, message-loss, session-state, and auth-provider labels.

Evidence reviewed

What I checked:

• Issue report: The issue body reports battery drain and system slowdown with multiple concurrent sessions, gives only a broad repro of starting multiple sessions and observing CPU/battery, and explicitly says it should ladder up to the secure-contained-node MXC epic.
• Current main/release check: Current main is 8b857ec; the visible post-v0.6.12 commits are MCP chat automation and documentation refreshes, not a measured multi-session performance or power fix. (8b857ecbb1f5)
• Node invoke concurrency guard: WindowsNodeClient caps concurrent capability invokes at 8 and rejects overflow with a busy response, which mitigates one node-load class but does not prove multi-session battery drain is fixed. (src/OpenClaw.Shared/WindowsNodeClient.cs:58, 8b857ecbb1f5)
• Session preview throttle: GatewayService requests previews at most every five seconds and only for the first five sessions, showing partial session-load throttling but not a complete power policy. (src/OpenClaw.Tray.WinUI/Services/GatewayService.cs:320, 8b857ecbb1f5)
• Chat history load path: OpenClawChatDataProvider eagerly loads history for every unloaded timeline when sessions arrive while connected, which is a plausible multi-session workload that still needs profiling before changing behavior. (src/OpenClaw.Tray.WinUI/Chat/OpenClawChatDataProvider.cs:1565, 8b857ecbb1f5)
• Coverage gap: TEST_COVERAGE.md still lists long-running soak behavior for reconnects, high-frequency activity updates, and memory usage over multi-day sessions as not fully covered by automated tests. (docs/TEST_COVERAGE.md:112, 8b857ecbb1f5)

Likely related people:

• shanselman: GitHub PR metadata and local blame link Scott Hanselman to the merged node invoke concurrency hardening and recent current-main MCP/chat automation work relevant to multi-session load. (role: recent node/concurrency and current-main contributor; confidence: high; commits: 6c4d11f6c619, 83872b8e5f59, 162097ad0ad5; files: src/OpenClaw.Shared/WindowsNodeClient.cs, src/OpenClaw.Shared/WebSocketClientBase.cs, tests/OpenClaw.Shared.Tests/WindowsNodeClientTests.cs)
• christineyan4: PR metadata shows Christine Yan authored the chat auto-reload and eager history loading behavior that fires when sessions arrive while connected. (role: chat session/history feature-history contributor; confidence: high; commits: 488f26509ced, 76ed2843bef6; files: src/OpenClaw.Tray.WinUI/Chat/OpenClawChatDataProvider.cs, tests/OpenClaw.Tray.Tests/OpenClawChatDataProviderTests.cs)
• ranjeshj: PR history shows Ranjesh introduced AppState/GatewayService, including the session update and preview throttling path likely involved in multi-session UI load. (role: session state and gateway-service feature owner; confidence: high; commits: 4ab640f5b012, cff1033b3bb3, 59078f5d3def; files: src/OpenClaw.Tray.WinUI/Services/GatewayService.cs, src/OpenClaw.Tray.WinUI/Services/AppState.cs, docs/DATA_FLOW_ARCHITECTURE.md)
• RBrid: PR metadata shows RBrid added the device.status CPU and battery diagnostic sections that would be useful for proving this report. (role: device diagnostics contributor; confidence: medium; commits: 24dfd6aebefe, ae5899ccb7f4; files: src/OpenClaw.Tray.WinUI/Services/DeviceStatusProvider.cs, src/OpenClaw.Shared/IDeviceStatusProvider.cs, src/OpenClaw.Shared/Capabilities/DeviceCapability.cs)

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.