perf(ws): scope preview frames and drop repeated shell payloads

[leoisadev1]

Stacked on perf/server-hot-paths.

The WebSocket layer sent far more than clients needed, which matters most over SSH, Tailscale, and tunnels. Bot browser preview frames, full-viewport PNGs of 100 KB to 1 MB as base64, went to every subscribed client regardless of which chat owned them, with filtering only in the browser. Every thread event made each client refetch and re-send that thread's shell even when nothing visible changed. Subscribing to server config forcibly re-probed every provider by spawning CLI version checks and always broadcast the result, because the probe timestamp defeated the change comparison. Stream budgets charged the raw event size, so one tool result over 8 MB failed every client's shell subscription at once.

The preview subscription now takes an optional threadId and the server filters frames before serialization, an additive contract change that keeps old clients working. Shell subscriptions remember the last shell sent per thread and drop identical refetches. Config subscribes serve the cached provider snapshot, re-probing only entries older than 60 seconds, and the change comparison ignores probe timestamps. The shell stream stores slim thread references instead of raw events, and activity slimming is cached per event so it runs once regardless of subscriber count.

Verified with 210 passing tests across six suites, including new tests for preview scoping and shell de-duplication, with the dedupe test confirmed to fail when the fix is disabled. The preview event queue deliberately stays unbounded because a sliding queue could drop lifecycle events and desync clients.

Created with Claude Fable 5.1 in Claude Code.

🤖 Generated with Claude Code

---

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
akeru-bot-landing	Ready	Preview	Sep 26, 2026 5:53pm UTC

[greptile-apps]

Confidence Score: 5/5

[Medium risk] Optimizes preview and provider status messaging to reduce bandwidth.

The reproduced cache-write issue is non-blocking; the review found no outstanding issue that prevents merging.

Findings

1.  Older Refresh Overwrites Cache ▶

Summary

The PR scopes preview subscriptions by chat and reduces WebSocket traffic. Concurrent refreshes of one provider can leave an older status and authentication snapshot in its disk cache after a newer result wins in memory. Ordering cache writes would prevent stale data from being read during startup.

_{Reviews (6) · Last reviewed commit: "fix(server): skip unavailable providers ..."}

[greptile-apps]

Comments Outside Diff

These findings sit on lines the diff does not cover, so they could not be posted inline. Each one leaves this list once its file changes.

•  Concurrent refreshes can persist an older provider result last ▶

  • Bug
    • When two refreshes of one instance overlap, the newer result can be retained in memory while the older result overwrites its cache file. A subsequent cache read and hydration then yields stale status and auth.
  • Cause
    • The checkedAt comparison is atomic with the in-memory Ref.modify, but persistProvider runs afterward without per-instance ordering; its atomic renames can finish in the opposite order.
  • Fix
    • Serialize persistence per instance, or recheck that a snapshot is still the latest immediately before its cache-file rename.

[devin-ai-integration]

Devin Review found 5 new potential issues.