---
title: Keep my computer smooth under load (smoothLoadEnabled master toggle)
---
# Keep my computer smooth under load

## What it is

**"Keep my computer smooth under load"** is a master on/off switch in **Settings → Performance** (on by default) for Omniscio's load-smoothing behaviors — the things Omniscio does so that running many Claude sessions at once doesn't bog your machine down. It is the umbrella control: turn it **off** and every load-smoothing behavior reverts to Omniscio's older, pre-smoothing behavior; turn it **on** (the default) and Omniscio quietly reduces the background work each session does.

Today this toggle governs one concrete behavior — **how Omniscio checks each session's context-usage** (below). It is built as a master switch so future smoothing behaviors fold under the same single control instead of adding a new toggle each time.

## Where to find it

**Settings → Performance → "Keep my computer smooth under load (recommended)"** — on by default. Flipping it takes effect immediately (no restart): the next turn-complete consults the live setting. Works on every platform (it governs process-launch behavior, not an OS-specific feature).

## How it behaves

### The behavior it controls today: turn-complete-only, gated context checks

While a session is running, Omniscio checks how full its context window is so it can show the 75% / 90% [context warnings](context-warnings.md) (and the optional context indicator). Getting the _authoritative_ number means launching a short-lived `claude --resume … /context` helper process. With one or two sessions that's nothing; with **many** sessions running at once, the old behavior — launching one of those helper processes for **every** session every ~90 seconds (and again repeatedly mid-turn) — piled up into real CPU cost and could make the whole app feel laggy.

With the toggle **on**, Omniscio makes two changes. First, it **stops polling in the background entirely**: the authoritative `/context` launch happens **once per turn, at turn-complete**, not on a 90-second timer. Second, it only pays that cost when something will actually use the result and the session is worth checking: it **skips** the launch when no warning and no indicator are enabled, and (on the warning-only path) it **skips** it for any session whose **free** running fullness estimate (computed every turn, no process launched) says it is comfortably below the warning band (under **60%** full). Sessions that are actually approaching the band still get the accurate check; if the context indicator is on, the under-60% skip is bypassed so the indicator still gets the real number.

**Crucially, no warning is ever missed.** The free estimate is refreshed every turn and drives a cheap warning check that runs at the end of **every** turn regardless of the gate. The authoritative number refreshes at each turn-complete the moment a session is in range, and keeps refreshing through the entire 75% / 90% warning range. The only place Omniscio allows a slightly-stale _authoritative_ number is _below_ 60%, where there is no warning to show anyway.

With the toggle **off**, Omniscio reverts to its older behavior: a 90-second background poll **plus** an unconditional `/context` launch at the end of every turn, for every running session — no gating.

### When to turn it off

Leave it **on** unless you have a specific reason. Turn it **off** if you want Omniscio's exact previous behavior — e.g. you're debugging context-poll timing, or you want the authoritative context number refreshed for every session continuously (on the 90-second background poll) regardless of how empty it is. Off trades smoothness under heavy load for that continuous refresh.

### How you can tell it's working

When the fullness gate skips a session's turn-complete check, Omniscio writes a single per-session log line the first time that session gets gated (a transition marker, not one line per turn) — visible in development builds. It's there so the skip rate is measurable and so a "my context bar looks stale" report has a trace to follow. In normal use you won't see anything: the app just stays smoother when many sessions run.

### Related performance controls

Other independent toggles in the same **Performance** section address different load symptoms:

- [Session CPU cap](session-cpu-cap.md) — bounds the combined CPU of all Omniscio sessions (Windows).
- [Ease RAM pressure by paging busy sessions](session-memory-paging.md) — trims working sets when memory is tight (Windows).
- [Boost Omniscio interface priority](amc-priority-boost.md) — keeps Omniscio's own window responsive under load (Windows).

This toggle is cross-platform and reduces _work done_, where those reduce _resources consumed_ — they compose.

### How it's verified

- [tests/unit/process/context-budget-manager.test.ts](../../tests/unit/process/context-budget-manager.test.ts) — the fullness-gate block: skips the helper-process launch when both fullness signals are below 60%, launches when either crosses 60%, launches unconditionally when the toggle is off (legacy behavior), and fails open (launches) when no estimate exists yet; plus the once-per-session skip-log and its re-arm.
- [tests/unit/shared-types.test.ts](../../tests/unit/shared-types.test.ts) — the setting defaults to `true`.

### Why default on

Most users never think about context polling, and the gating is safe by construction (no warning is missed, and it fails open when fullness is unknown). Shipping it on means everyone gets the smoother behavior under load without having to discover a setting; the toggle exists for anyone who wants the exact prior behavior back.

## For agents

### Implementation pointers

- [src/main/process/context-budget-manager.ts](../../src/main/process/context-budget-manager.ts) — `maybeQueryContextAtTurnEnd(session)` (the once-per-turn entry point: skip when no warning/indicator consumer; warning-only path applies the fullness gate, indicator-on path passes `bypassFullnessGate`; legacy `smoothLoadEnabled === false` spawns unconditionally), `isBelowContextPollGate(usage, windowTokens)` (the pure fail-open helper, MAX of the authoritative `contextInfo.percent` and the free `lastTurnInputTokens` proxy divided by the session's REAL per-model window — 1M on Opus 4.8, not a flat 200k — threshold `CONTEXT_POLL_FULLNESS_GATE_PERCENT = 60`), the gate inside `querySessionContext` (`getSettings().smoothLoadEnabled !== false && isBelowContextPollGate(session.usageInfo, session.contextWindowTokens)`, after the recovery gate, before the helper-process launch), and `startContextPollTimer` which early-returns (no-op) unless `smoothLoadEnabled === false`.
- [src/renderer/src/features/settings/PerformanceSettings.tsx](../../src/renderer/src/features/settings/sections/performance/PerformanceSettings.tsx) — the `smoothLoadEnabled` toggle definition in `PERFORMANCE_DEFINITIONS` (`defaultValue: true`).
- Behavior lock: [context-warning-contract.md](../../.claude/memory/contracts/context-warning-contract.md) invariant **I13**.

## Related

The other performance controls sit in the same area: the system file cache cap and the background pacing during severe lag. **Computer feels slow?** is the guide to follow when something is already wrong.
