menubar: idle energy on AC still high after #648 — 30s cadence x ~10 CPU-s Node spawn per tick, no change-detection, userInitiated QoS (and #648 is unreleased)

[avs-io]

Problem

Follow-up to #647 / #648 with on-machine measurements from a real user machine running the menubar (0.9.15). Idle energy use is still substantial, and the merged #648 work — which is real and large — (a) has not shipped in any release (latest tag mac-v0.9.15 predates the merge) and (b) leaves the dominant idle cost intact on AC power.

Evidence (15-min idle window, popover closed, AC, M-series; 12 GB codex + 1.2 GB claude/opencode session corpus)

• The menubar spawned 15 codeburn status --format menubar-json --provider all --period today --no-optimize Node processes, one every 59-63s. Each burned 7.6-16.7 CPU-s, peaking at 112-360% CPU. Children alone: 142.8 CPU-s / 896s = 15.9% of a core, sustained indefinitely.
• The Swift process itself is innocent: 0.32% avg. Activity Monitor attributes the children to the app.
• Direct measurement of one fetch: today = 9.9 CPU-s, 2.1 GB peak footprint, 93B instructions; week = 15.8 CPU-s. Cold start is not the cost: bare node -e 0 = 0.03s, codeburn --version = 0.4s. sample of a live child shows V8 GC (ConcurrentMarking), UTF-8 decode, and JSON stringify — i.e. a full re-parse of today's sessions on every tick.
• Total: ~16.2% of a core sustained while idle, nearly all of it in the per-tick subprocess re-parse.

What #648 already covers (merged, unreleased)

Display-sleep gating, popover-closed payload trimming, battery/low-power backoff, scoped activity assertions, cadence picker. On battery this will land a big cut once released.

Proposed fix (remainder, cheapest first)

1. Ship a release containing menubar: cut idle energy (video-call-class drain, fixes #647) #648 — users currently have none of it.
2. Change-detection guard (menubar: cut idle energy (video-call-class drain, fixes #647) #648 ladder item 1, unimplemented): stat provider data roots before spawning; skip the tick when nothing changed since the last successful fetch. Most idle ticks are no-ops.
3. AC backoff: RefreshCadence.interval returns 30s whenever on AC with the popover closed (RefreshCadence.swift:34); back off to 2-5 min closed-popover regardless of power source (popover-open stays 30s).
4. QoS: background-tick spawns still run .userInitiated (Security/CodeburnCLI.swift:98; menubar: cut idle energy (video-call-class drain, fixes #647) #648 only edited the comment). Use .utility for timer ticks, keep .userInitiated for interactive fetches.
5. Incremental today-parse in the CLI: persist a per-file byte-offset checkpoint so a refresh parses only appended JSONL bytes; cuts the 8-16 CPU-s per genuine refresh to sub-second and benefits TUI/MCP too.

Quota-poll network behavior is tracked separately in #701.

Measurements: process-table sampling at 2s/5s intervals plus /usr/bin/time -l and sample(1); happy to attach raw CSVs. Items 2-4 are small and I'll put up a PR; items 1 and 5 are flagged for maintainer judgment (release timing, CLI architecture).

[avs-io]

Item 1 is now resolved — v0.9.16 / mac-v0.9.16 shipped yesterday and include #648 + #704. That leaves item 5 (incremental today-parse) as the only open remainder here. Short design sketch before any code:

Approach. Extend the session cache's per-file fingerprint with a parse checkpoint: { byteOffset (last complete newline), tailChecksum (last N bytes at offset), parserCarryState }. On refresh, a changed file whose size grew and whose tail checksum at the old offset still matches is parsed from byteOffset only; the appended entries merge into that file's cached slice. Any mismatch — shrunk file, same-size mtime change, checksum miss — falls back to a full re-parse of that file, so correctness never depends on the checkpoint.

Details that make it byte-identical to a full parse:

• Checkpoint only at the last complete line, so a writer caught mid-append is re-read next tick.
• parserCarryState carries whatever per-file running state the parser threads across lines (dedup keys seen, open session/turn context), so an appended-bytes parse can't double-count or orphan entries.
• Cache schema version bump; old caches re-parse once and then go incremental.
• Composes with the Desktop: refresh cadence, instant switching, cache coherence, telemetry v1 #699 hydration lock untouched — this optimizes the warm path, the lock covers the cold one.

Tests: a parity suite in the style of #698 (incremental result must be deep-equal to a from-scratch parse across append/truncate/rewrite/partial-line fixtures), plus a bench note on a large corpus.

Expected effect: the ~8–16 CPU-s per genuine refresh drops to roughly the cost of parsing only the newly appended lines (sub-second in normal use), and TUI/MCP refreshes benefit identically.

Worth building? If the direction looks right I'll put up the PR scoped exactly to this.

[avs-io]

Revision to the item-5 sketch above, after adversarially checking it against the actual provider corpus — three findings invalidate it as posted:

1. "JSONL is append-only" is not true across providers. Codebuff/CodeWhale/Gemini parse whole-JSON snapshots; Copilot chat replays journal mutations (kind: 0/1/2) and the JetBrains path explicitly handles MVStore compaction rewriting files; Cursor and Copilot-OTel are SQLite. Byte checkpoints must be a declared per-source capability — an allowlist starting with Claude-style append-only JSONL — with full re-parse as the default for snapshot/journal/database sources. Aggregate-cost providers (droid, mistral-vibe redistribute session totals across all calls, so one appended call changes every prior allocation) are full-reparse-only regardless of file shape.
2. No opaque parserCarryState. The real parsers thread open turns, streaming-ID dedup, and cumulative counters that can't be safely serialized generically. Revised: checkpoint at the last complete-turn boundary and re-parse the overlap (the final, possibly-open turn) on resume — restoration is then derived by the parser itself, not deserialized, and the deep-equal-to-full-parse property is checkable rather than hoped for.
3. Tail checksum is insufficient — it misses same-length mutations earlier in the file. Checkpoint validity = size grew AND a bounded prefix-integrity check (block hashes over the committed prefix) passes; any doubt → full re-parse of that file. Hashing is ~2 orders cheaper than parse, so the win survives.

Sequencing: the incremental merge must run inside the warm transaction gate proposed in #645 (two warm processes sharing a checkpoint can otherwise lose updates), so this lands after #645's first slice. The parity suite grows fixtures for prefix mutation, streaming-ID updates, open turns, cross-file dedup, and concurrent warm writers, plus a measured before/after CPU number on a large corpus.

v1 scope: Claude provider only, capability-gated, full fallback everywhere else.