Per-session update isolation (cheaper updates with many sessions open)

An opt-in performance mode that makes every live update cheaper when many sessions are streaming at once: each open session panel reads its per-session state through one consolidated lookup instead of five, so a busy agent's output nudges far less work across every panel you have open. The app looks and behaves exactly the same.

What it is

What it is: an opt-in performance mode that makes each live update cheaper when many sessions are streaming at once. Normally, every time any session emits a token, Omniscio re-runs a handful of small per-session lookups for every open session panel — even the ones that didn't change. With this on, each mounted panel reads its per-session state through one consolidated lookup instead of five, so a busy agent's output nudges far less work across all your open panels. The app looks and behaves exactly the same; only the internal per-update cost drops.

Where: Settings → Performance → "Per-session update isolation". Default OFF (opt-in). Flipping it takes effect immediately — no restart. It never changes what your sessions actually do; turning it off returns to the previous behavior exactly.

Where to find it

Settings → Performance → Per-session update isolation. It is off by default; flipping it takes effect immediately, with no restart.

How it behaves

Why it exists

This is the residual per-update cost that remains after the adaptive-hidden-window throttle (which cut how often background sessions commit). This cuts how expensive each commit is: a store update re-runs every subscriber's selector, so with ~13–30 mounted keep-alive panels each holding ~5 separate per-session subscriptions, a single streaming token re-ran ~150 small selectors. Consolidating each panel's five reads into one cuts that to ~30 — a deterministic ~80% fewer per-commit selector executions at 30 panels (measured in tests/unit/stores/select-session-panel-subscriptions.test.ts, which also proves the consolidated read wakes a panel on exactly the same updates the five separate reads did — no stale panel, no missed update).

How it works

A mounted session panel reads five per-session slices in its body: the pending action, the pending permission, the auth-retry state, the subagent state, and the per-session usage. Each is its own store subscription that re-runs on every commit.
When the toggle is ON, those five reads are served by one canonical selectSessionPanelSubscriptions selector wrapped in useShallow, so the panel runs one selector per commit instead of five. Because shallow-equality over the five fields is exactly "did any of them change for this session", the panel re-renders on the same updates as before — the behavior is identical, there's just one subscriber.
The OFF↔ON choice is a component swap in SessionPanelImpl (the same shape the Fast session switching toggle uses): flipping the setting live-remounts the panel body onto the other path.

Kill switches

The Settings toggle itself (perSessionSubscriptionIsolation, default false).
AMC_DISABLE_PER_SESSION_SUB_ISOLATION=1 env var — force-OFF regardless of the setting (it can never force the mode ON). Reverts to the five separate subscriptions byte-for-byte.

Scope

This isolates a panel's component-level per-session subscriptions. The conversation-cache / streaming reads that live deeper in the panel's hooks are not part of this pass (a larger, higher-churn change left for later).
Works the same on desktop and the mobile web embed; it's a rendering-cost change, not a UI change.

perf-control.md — the screen that shows what is being paced on this machine, and why.

Contract (invariants + locking tests): .claude/memory/contracts/store-subscription-isolation-contract.md
The switch-render half of the same perf story: isolated-session-view.md, inbox-prerender.md

Last verified 2026-10-06