---
title: Computer feels slow? A step-by-step fix-it guide (free fixes first, new hardware last)
---
# Computer feels slow? A step-by-step fix-it guide (free fixes first, new hardware last)

## What it is

A plain-English, do-this-in-order guide for when your computer feels slow while running Omniscio — freezing for a few seconds, fans spinning up, everything lagging. It is written so **you** can follow it, and so an **AI agent** (any Omniscio session) can follow it for you.

The steps go **cheapest and easiest first**. You almost never have to go far down the list. **Buying new hardware is the very last resort** — only after everything above it.

## Where to find it

### How to open the settings these steps mention

Most Tier 1 fixes live in one place: the **gear icon (top-right) → Settings → Performance**. Toggles there take effect **live** (no restart) unless a step says otherwise.

---

## How it behaves

### The one thing to understand first

About 9 times out of 10, "my whole computer is slow/frozen" comes down to **one cause: your computer ran out of fast memory (RAM) and started using the much slower disk as overflow** (this is called _paging_ or _swap-thrash_). When that happens:

- The whole machine — not just Omniscio — freezes for a few seconds at a time.
- The CPU looks busy (70–95%) but never quite pegs at 100% (the busy parts are _waiting on the disk_, not computing).
- Fans spin up; everything feels like wading through mud.

**It is almost never "too many sessions."** A pile of _idle_ sessions sitting in your sidebar costs very little. What actually eats the machine is **memory pressure** (too much held in RAM at once) plus **background junk** (backup software, antivirus, leftover files). So the fixes below mostly free up memory and clear out junk — not "use Omniscio less."

**The other ~1 in 10 is a stuck Windows background service.** Once in a while it _isn't_ memory at all: a Windows service gets wedged in a tight loop and pins the CPU. The tell is different from the RAM story above — RAM is _fine_, but the machine still freezes and the CPU sits pinned near 100% doing **"kernel/system"** work (not your apps). If the Step 0 RAM checks come back clean and it _still_ freezes, skip to **"If RAM is fine but it still freezes"** below.

> **A code fix only helps after you restart the app.** Many speed-ups ship inside Omniscio itself. If you're running a build from a while ago, you don't have them yet. When in doubt, **restart Omniscio** (Tier 2, step 1) so you're running the latest — and note that _turning off_ a misbehaving feature sometimes needs a restart to fully release what it was using.

> **CPU still busy after Omniscio closes?** That is not normal. Gates started by an Omniscio agent
> are owned by the app and the entire process tree should end on shutdown, including background
> Node/git packaging work. Do not kill every `node.exe` or `git.exe` by name; those names are shared
> by unrelated work. Restart onto the latest build, then ask an agent to inspect the shutdown outcome
> and positively identified process roots. Gates launched by a genuinely external terminal are the
> exception: their sidecar says `scheduled-task-external`, and they keep running independently until
> they finish or you use their printed teardown recipe.

---

### Step 0 — Let Omniscio's AI scan your computer first

The fastest way to know _which_ of the steps below you actually need is to let an AI look. The scan only **reads** information — it never changes anything on your computer.

**Ask Omniscio itself first — it already measured this.** Have any session run `npm run perf:status`, or open the **Performance Monitor** panel (Developer Tools → Performance Monitor) — see [perf-status.md](perf-status.md). Everything else on this page reads your _operating system_ — how much RAM is free, how many processes are running — which can only tell you the machine looks busy. Omniscio's own readout answers the questions that actually pick your fix: what share of the last 30 minutes the app's main thread was **stalled**, whether the whole **box** was kernel-bound (a hang the app-side numbers structurally cannot see), which load gates are actually governing right now, your per-drive disk runway — **and it names what it could not see**, so a blank is never mistaken for a clean bill of health. Run it before the OS counters below, not after: if it shows stalls or a kernel-bound box, that is a bug to report (see the bottom of this page), not a machine for you to tidy.

**On Windows — use the built-in health-check.** Omniscio ships a guided **First Mission**: a coached, **read-only** computer health-check that reveals what it finds and asks your approval _before_ any change, with an undo. It runs automatically on first launch; you can replay it anytime from a project's empty state → **"Run a guided mission."** See [first-mission.md](first-mission.md).

**See it inside Omniscio — the Resources panel.** For a live look without leaving the app, open **Settings → Tools & Maintenance → Diagnostics → Resources** (or the toolbar **⋯** menu → **Resources**). It's a read-only, Task-Manager-style view of every process Omniscio is running — the app itself, the window, each session, and its background tools — each with a live CPU and memory readout, and a **Kill** button (with a confirmation) for a single runaway. It answers the first question fast: _is one session eating everything, or is the whole machine just low on memory?_ See [resources-diagnostic-panel.md](resources-diagnostic-panel.md).

**Any platform — ask any session to scan.** Open any Omniscio session and paste this:

> Please do a **read-only** scan of my computer and tell me why it might be slow, then point me to the right fixes. Do not change anything. Check and report: free vs total RAM, my top 10 memory-using processes, total number of running processes, free disk space on my system drive, whether my pagefile is a fixed size or growable, my antivirus/Defender exclusions, and — if I use Omniscio for development — how many git worktrees and how much disk they use. Then tell me which tier of the "Computer feels slow?" guide I should start with.

The read-only commands an agent (or you) can run on **Windows PowerShell** — every one is a `Get-` command, so nothing is changed:

```powershell
# Free vs total RAM (in GB)
Get-CimInstance Win32_OperatingSystem |
  Select-Object @{n='FreeGB';e={[math]::Round($_.FreePhysicalMemory/1MB,1)}},
                @{n='TotalGB';e={[math]::Round($_.TotalVisibleMemorySize/1MB,1)}}

# Top 10 memory hogs
Get-Process | Sort-Object WorkingSet64 -Descending |
  Select-Object -First 10 Name, @{n='RAM_MB';e={[math]::Round($_.WorkingSet64/1MB)}}

# How many processes are running (an idle PC is ~250; 1,000+ means death-by-a-thousand-processes)
(Get-Process).Count

# Free disk space on C:
Get-PSDrive C | Select-Object @{n='FreeGB';e={[math]::Round($_.Free/1GB,1)}},
                              @{n='UsedGB';e={[math]::Round($_.Used/1GB,1)}}

# Pagefile: if this prints nothing, your pagefile is "system-managed" (growable) — see Tier 2
Get-CimInstance Win32_PageFileSetting | Select-Object Name, InitialSize, MaximumSize

# Antivirus exclusions already in place
Get-MpPreference | Select-Object -ExpandProperty ExclusionPath

# Is Defender's behavior engine still on, and is Tamper Protection blocking changes to it?
# (If Defender is a top CPU user but the paths above are already excluded, this is the reason.)
Get-MpComputerStatus | Select-Object RealTimeProtectionEnabled, BehaviorMonitorEnabled, IsTamperProtected

# --- Only if the RAM checks above look FINE but it still freezes: is a Windows service stuck? ---
# How much of the CPU is "kernel/system" work (a stuck service shows a high second number):
Get-Counter '\Processor(_Total)\% Processor Time','\Processor(_Total)\% Privileged Time' -MaxSamples 1 |
  ForEach-Object CounterSamples | Select-Object Path, @{n='Pct';e={[math]::Round($_.CookedValue)}}
# Threads stuck waiting for a free CPU (well above your core count = a pile-up):
(Get-Counter '\System\Processor Queue Length' -MaxSamples 1).CounterSamples[0].CookedValue
# Which process churns the most CPU hand-offs — a lone svchost FAR above the rest is the wedged one:
Get-CimInstance Win32_PerfFormattedData_PerfProc_Thread | Where-Object IDProcess -ne 0 |
  Group-Object IDProcess | ForEach-Object {
    $p = Get-Process -Id $_.Name -ErrorAction SilentlyContinue
    [pscustomobject]@{ Proc = $p.ProcessName; CtxSwPerSec = [int](($_.Group | Measure-Object ContextSwitchesPersec -Sum).Sum) }
  } | Sort-Object CtxSwPerSec -Descending | Select-Object -First 6

# --- Only if RAM and CPU look FINE but things still hitch: is ONE drive pinned? ---
# Per-drive load. One drive at ~0% idle with a long queue while the others are near 100% idle
# is the tell — that asymmetry means a crawler, not an overloaded machine:
Get-Counter '\LogicalDisk(*)\Avg. Disk Queue Length','\LogicalDisk(*)\% Idle Time' -MaxSamples 2 |
  ForEach-Object CounterSamples | Where-Object { $_.InstanceName -notmatch '_total|harddisk' } |
  Group-Object InstanceName | ForEach-Object {
    $q = ($_.Group | Where-Object Path -match 'queue' | Measure-Object CookedValue -Average).Average
    $i = ($_.Group | Where-Object Path -match 'idle'  | Measure-Object CookedValue -Average).Average
    if ($q -gt 1 -or $i -lt 50) { '{0,-6} queue={1,7:N2}  idle%={2,6:N1}' -f $_.Name, $q, $i }
  }
# Is the Windows file-crawler running? (Expect "Stopped / Disabled" if you already turned it off —
# a Windows FEATURE update can reset it, so re-check here after a version upgrade.)
Get-CimInstance Win32_Service -Filter "Name='InventorySvc'" | Select-Object Name, State, StartMode
```

Reading the result tells you where to start: **low free RAM** → Tier 1 + free up memory; **1,000+ processes or no antivirus exclusions** → Tier 2 cleanup; **disk nearly full / growable pagefile** → Tier 2 Windows steps; **RAM fine, but the "kernel/system" number is high, the thread queue is huge, and one `svchost` dwarfs the rest** → a stuck Windows service (see **"If RAM is fine but it still freezes"** below); **RAM and CPU fine, but exactly ONE drive is pinned while the others are idle** → a Windows file-crawler (see **"If RAM is fine but one DRIVE is pinned"** below), especially if that drive holds a lot of project folders. If nothing stands out in that last list, it isn't this. And if **Defender itself** ("Antimalware Service Executable") is a top CPU user _even though the paths above are already excluded_, that points to its **Behavior Monitoring** engine rather than file scanning — see the antivirus steps in **Tier 2 → Advanced**.

---

### Tier 1 — Free, instant, no restart (flip a few switches)

Open **Settings → Performance** and turn these on. Start with the first one — it bundles several of the others. The page shows the essentials first; some of the toggles below live under its collapsed **"Show advanced"** fold — expand it, or just type the toggle's name into Settings search and it will jump straight there with the fold opened for you.

1. **`Lite mode (optimize for a less powerful computer)`** — the single best starting switch. One toggle makes Omniscio lighter: it turns on Low Power Mode, holds new sessions when memory is low, reclaims RAM from idle sessions, staggers loading at startup, and stops pre-building extra chats in the background. Turning it off restores your previous settings exactly. _(If Omniscio ever showed you a low-spec or weak-graphics notice in your Inbox with a **"Turn on Lite mode"** button, that button switches this on in one click — say yes. A slowness card such as **"Omniscio has been running slowly"** with a **"Go to Lite mode"** button opens Settings → Performance right at this switch.)_
2. **`Reserve a CPU core for Omniscio so the window never freezes`** _(Windows, hybrid CPUs)_ — sets aside one fast CPU core just for Omniscio's window so a swarm of sessions can never crowd the interface off the CPU and freeze it. Your sessions keep running on the rest.
3. **`Real-conversation layout`** _(on by default)_ — shows just your messages and the agent's final replies, folding per-turn tool work into a collapsed "N actions" pill. The single biggest rendering-cost reduction on busy chats. If yours is off, turn it on.
4. **`Release idle sessions to reclaim more RAM`** _(default 15 minutes)_ — fully releases the background engine of a session that's been waiting on you, giving back ~250–450 MB each; the chat stays on screen and your next message reloads it. Lower the number (e.g. 5–10 min) to reclaim memory sooner.
5. **`Low Power Mode`** — drops GPU-heavy visual effects (background blur, heavy animations, decorative shadows). Smoother on laptops and integrated graphics. (Already included in Lite mode.)
6. **`Smooth streaming output (recommended)`** _(on by default)_ — paints fast-streaming text at 30 fps instead of on every character, keeping the rest of the app responsive while many sessions stream. Leave it on.
7. **`Hold new sessions when memory is low`** — when memory is tight, pauses _bursts_ of brand-new sessions (mass restarts, recipe runs) until memory frees up, so a flood can't tip you into a freeze. A single session you open by hand is never delayed.

> **Don't disable GPU Acceleration.** It's tempting, but turning it off forces slow software rendering and makes everything _worse_. Leave **`GPU Acceleration`** on unless you're chasing a specific graphics glitch.

> **Is your mouse laggy over the Omniscio window — but fine everywhere else?** That very specific symptom almost always means one thing: Omniscio turned graphics acceleration off **by itself**. It does that after it crashes several times while starting up, on the assumption your graphics card is at fault. Your computer then has to draw the whole window itself, which costs real work on every mouse move — so the pointer stutters, scrolling feels choppy, and rounded corners look rough, while the rest of your machine feels perfectly normal.
>
> You'll see a banner at the top of the window whenever this is on, with a **"Re-enable graphics acceleration"** button (it's also in **Settings → Performance**). Update your graphics drivers first if you can — Intel, NVIDIA, or AMD, from the manufacturer's website — then press the button. Omniscio restarts to apply it. It's safe to try: if the startup crashes come back, Omniscio turns acceleration off again on its own.
>
> This is **not** the same as the toggle above. That one is your choice; this one is Omniscio's, and it stays on until you undo it — so a machine can sit in it for months.
>
> Omniscio will also drop a reminder card in your inbox **about once a week** while acceleration stays off, with the same one-click re-enable, and it goes quiet the moment acceleration is back on. _(It used to be monthly, which was long enough that people sat in software rendering for a whole season without realising it was fixable — 2026-09.)_ Omniscio will **never** switch acceleration back on by itself; that stays your decision.

> **Already working for you: `Keep Omniscio resident in memory`** _(on by default)_. This is the fix for the _random whole-app freeze_ — the kind that hits even when you're not clicking anything. Omniscio keeps its own database pinned in fast memory so a busy disk (from a swarm of sessions) can't push it out and stall the window. It sizes itself automatically and only switches on when your PC has enough RAM to spare (roughly 13 GB+), so it can never starve a smaller machine — there's nothing to tune. On a low-RAM PC it simply stays off. You'd only turn it **off** if you're deliberately freeing every last megabyte for something else.

> **Also already working for you: Daily Digest generation runs off the window thread** _(2026-07)_. Under sustained disk load Windows can evict Omniscio's database from memory even past the pin above, and the digest's once-a-day full-day scan used to run on the window thread — the one case where that combination could freeze the window for minutes (and retry every 15 minutes). Digest scanning now happens in its own short-lived helper process, so a slow disk delays your briefing, never your window. Nothing to configure.

> **Also already working for you: new sessions build their private copies a few at a time** _(2026-07)_. When Omniscio isolates a session it creates a git "worktree" — a private copy of your project. That copy sits in a `<your-repo>-worktrees` folder **beside your repo, on the same drive as the repo** (put that folder on a Windows "Dev Drive" and you get the benefit described further down as well). It is a deliberately *trimmed* copy, not a whole one: a few large tracked folders are left out to save disk and time, so from inside the worktree those folders look **empty**. In this repo that is `audit-reports/`, `docs/plans/` and `firebase/`. If a session genuinely needs one of them, fill the copy back in with `git -C "<worktree-path>" sparse-checkout disable`. Starting many sessions at once used to fire all of those copies off simultaneously and flood the drive, one of the disk-saturation freezes described above. Omniscio now paces worktree creation (a few at a time by default), so a burst of new sessions **still all start** — they just build their copies in quick succession instead of all at once. Nothing to configure, and nothing throttles how many sessions you can run.

> **Also already working for you: Omniscio reclaims RAM automatically when your computer runs low** _(on by default, Windows)_. Separate from _releasing_ idle sessions (#5 above), this watches your **free memory** and, whenever it stays low — below **15% free** by default — trims the memory Omniscio's own **idle** sessions are holding, never a session mid-reply or one waiting on you. Want it to act sooner? Raise the threshold under **Settings → Performance → "Reclaim when free memory drops below __%"**. Nothing to turn on.

> **Also already working for you: each session loads only the tools it was given** _(on by default)_. A session loads just the background tools (its "MCP servers") Omniscio set it up with — not every tool you have installed globally. This matters for memory: a single heavy tool (a browser-automation server, for instance) can cost ~95 MB of RAM, so across a swarm of sessions loading only what each needs quietly saves **gigabytes**. Nothing to configure.

> **Also already working for you: the app you're using stays ahead of your agents** _(on by default, Windows, 2026-09)_. Omniscio runs its agents at a lower CPU priority than your own programs, so your browser or editor always gets the CPU first. But an app can occasionally start at that same low level itself — it happened to Chrome after a restart — and then it has to share the CPU equally with every agent: it feels sluggish the moment you switch to it, while Omniscio stays smooth. Omniscio now notices that and raises the app you're using, plus its own helper processes, back to normal priority within about a second of you switching to it. It never raises anything above normal, never touches an app you put in Efficiency mode, and never touches an agent. You can check an app yourself in **Task Manager → Details** (right-click it → **Set priority**): "Below normal" on your own app is this case. It has no on-screen toggle; to switch it off, ask any Omniscio session to set the `foregroundAppPriorityFloorEnabled` setting to false.

> **Tight on RAM? You can trade instant-switching for memory.** To make hopping between chats and panels feel instant, Omniscio keeps your most recently used sessions and panels fully loaded in the background — like browser tabs — which costs some RAM. If you're squeezed for memory, turn **off** **"Keep recent sessions instant"** and **"Keep recently-opened panels loaded"** under **Settings → Performance**: switching back becomes a beat slower, but you get that memory back. (Leave them **on** if you have RAM to spare — they make the app feel snappier.)

---

## Related

- [Computer feels slow? A step-by-step fix-it guide (free fixes first, new hardware last) (part 2)](slow-computer-part-2.md) — the continuation of this page.
- [Computer feels slow? A step-by-step fix-it guide (free fixes first, new hardware last) (part 3)](slow-computer-part-3.md) — the continuation of this page.

**Something's not working? Start here** routes every other symptom to its own fix, and the Performance Monitor and Resources panel pages cover reading live numbers inside the app.