--- title: Computer feels slow? A step-by-step fix-it guide (free fixes first, new hardware last) (part 3) --- # Computer feels slow? A step-by-step fix-it guide (free fixes first, new hardware last) (part 3) ## What it is This is part 3 of the [Computer feels slow? A step-by-step fix-it guide (free fixes first, new hardware last)](slow-computer.md) page. It carries the next stretch of the material on that page, moved here because a single page is capped at 40,000 characters. ## Where to find it Reach this part through [Computer feels slow? A step-by-step fix-it guide (free fixes first, new hardware last)](slow-computer.md) — it lists every part and explains where the feature lives in the product. Everything below is reached from the same place. ## How it behaves Everything below is the behaviour, detail and edge cases that belong to this stretch of the Computer feels slow? A step-by-step fix-it guide (free fixes first, new hardware last) page. ### If you're a developer and git actions feel slow: a bloated git repo _(Developers only — skip if you don't use Omniscio to run coding sessions.)_ Git stores a project's history in two forms: fast, compact **pack files**, and slow, individual **loose object files** (one tiny file per saved object). Normally git tidies loose objects into packs on its own. But on a busy machine running a swarm of coding sessions — where git is constantly committing, branching, and building worktrees — that automatic tidy-up keeps getting **interrupted** (often by the very freezes you're chasing), so loose files pile up into the **tens of thousands** and the packs fragment into a dozen-plus pieces. Once that happens, **every** git action — creating a worktree, a checkout, even a status — has to rummage through a storm of tiny scattered files: thousands of little disk reads for one operation. On a shared drive that's enough to spike the disk and feed a freeze — and it makes the **spawn storm** above worse, because the short-lived processes stampeding the machine are these now-expensive git actions. **How to spot it:** during ordinary git actions, you (or your agent) see git processes doing enormous disk I/O — hundreds of MB/s across tens of thousands of tiny operations — and a health check of the repo shows a huge **loose-object count**. The read-only check: ```powershell git -C "C:\path\to\your\repo" count-objects -v # 'count:' in the tens of thousands + 'packs:' in the double digits = a rotted store. # Healthy is a few hundred loose at most, and 1-2 packs. ``` **The fix — a one-time compaction, done with Omniscio CLOSED.** A single clean repack collapses those loose files and fragments back into one tidy pack and makes every future git action dramatically cheaper. **It must run with Omniscio fully quit:** the compaction reads and rewrites the whole store at once, which on a shared drive is a big enough disk burst to freeze the machine if Omniscio and its sessions are competing for the disk. So the safe way is to have your Omniscio agent build you a small **one-click tool that refuses to run unless Omniscio is closed**, then run it once when you quit for the day. Ask: _"git actions feel slow — please check my repo's object store, and if it's bloated, set me up a safe one-click repack I can run with Omniscio closed, plus ongoing upkeep so it stays healthy."_ For Omniscio's own repository, use **Settings → Diagnostics → Git storage** to schedule the compaction for the next pre-window startup. Omniscio then owns the ongoing paced upkeep; do **not** run `git maintenance start` for this repo, because its independent Windows tasks can overlap active tests, landing, and Omniscio's own maintenance. In one real case a store had grown to **~34,000 loose files across 15 fragments**; one clean repack took it to **0 loose / 2 packs in under a minute**, and everyday git actions dropped back to well under a second. ### More git tuning for a large repo or lots of worktrees Once the store is compacted, git has more levers for a big repo (tens of thousands of files) or many worktrees — but **not all of them help at scale, and one can backfire when you keep a lot of worktrees**, so have your Omniscio agent evaluate before flipping anything: - **Already managed by Omniscio (nothing to do):** its paced maintenance refreshes the **commit-graph** (speeds history and "is this branch merged yet?" checks) and the **multi-pack-index** (one lookup across accumulated packs instead of searching each pack). These jobs run behind Omniscio's load gates instead of an independent Windows schedule. - **Safe — faster `git status` on a huge tree:** `git config feature.manyFiles true` turns on a bundle for large working trees (a leaner index + a cached untracked-file scan), so status and checkouts stop re-examining all tens of thousands of files every time. Per-worktree, low-risk. - **Speeds up _creating_ a worktree — but NOT under a heavy agent fleet:** `git config checkout.workers 0` (or any value >1) writes a fresh checkout's files in parallel across your CPU cores instead of one at a time — the slow part of `git worktree add`. A help on a many-core machine when creating ONE worktree at a time on a fast, uncontended drive. **⚠️ Do NOT use it when many agents check out concurrently on a ReFS Dev Drive:** parallel checkout does concurrent working-tree file CLOSES that trip a ReFS.sys async-close driver bug (the `0x149 REFS_FILE_SYSTEM` bugcheck), which crashed the whole box under fleet load (2026-07-20 BSODs). Keep `checkout.workers = 1` (git's serial default) for the agent-worktree drives — the AMC git shim pins it to 1 for exactly this reason, and the repo `.git/config` should match. - **Careful — this one can backfire with many worktrees:** git's file-system monitor (`core.fsmonitor true`) makes `git status` near-instant by watching for file changes instead of scanning — but it runs **one background watcher per worktree**, so dozens or hundreds of worktrees means dozens or hundreds of watchers, which can _add_ more load than it saves. Great for a single big repo; measure it (or skip it) when you keep many worktrees. - **Keep the worktree count lean:** stale, finished worktrees still cost disk and get re-scanned — sweeping them (Tier 2.4 above) keeps both the working copies and the shared store tidy. --- ### Tier 3 — Move the heavy work off your machine or your hours (developers) Relevant if you use Omniscio for development and run heavy **builds / tests / lint** that compete with you while you work. - **Run heavy work when you're away.** Omniscio doesn't have a one-click "run overnight" button today, but you can wrap a heavy task in a **Recipe** (Settings → Automations → Recipes) and have a **Cron Job** (Settings → Automations → Cron Jobs) trigger it on a schedule — or simply kick the work off before you step away, so it runs while you're not fighting it for the machine. - **Send heavy verification to the cloud.** If you develop on the Omniscio repo (or a similarly set-up project) and have cloud offload configured, you can route test/typecheck/lint/build runs to rented cloud machines instead of your own box — add `--cloud` to those commands, or turn on **"Prefer cloud for tests on this machine"** in **Settings → Diagnostics**. _Honest caveat:_ this is a **developer feature** — it needs the cloud test infrastructure set up and is not present in the regular packaged app. It moves _verification_ work off your machine, not the AI sessions themselves. --- ### Tier 4 — Last resort: upgrade hardware Only after everything above. For a machine that genuinely runs many agents at once, the real cure for swap-thrash is **more RAM**. - **RAM beats CPU for this workload.** Running out of RAM is what causes the freezes; a faster CPU doesn't fix that. Going from, say, **64 GB → 128 GB** removes the paging-to-disk that causes whole-machine stalls. - **Check what your machine can take** before buying: your motherboard's maximum RAM and its memory type/generation (e.g. DDR4 vs DDR5). A 4-slot board often means replacing all sticks, not adding. As a real example, 128 GB of DDR4 has run around **$799** (prices vary a lot). - **A whole new computer** is only worth it if you can't add RAM to your current one. Prioritize RAM capacity, then a fast SSD, then CPU cores. --- ### Remember: settings apply live; app fixes need a restart - **Settings → Performance** toggles take effect **immediately** (a couple are marked "next launch"). - **Speed-ups built into Omniscio** only reach you after you **rebuild/restart** the app — if you've been running the same build for a while, restarting is often the whole fix. - **Turning off** a misbehaving feature may need a restart to fully release the memory/CPU it was using. ### Quick reference: symptom → likely cause → what to do | What you see | Likely cause | Where to go | | --------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Whole computer freezes for seconds | Out of RAM → paging to disk | Tier 1 (Lite mode, release idle sessions) + free RAM (Tier 2); Tier 4 if chronic | | CPU high but never hits 100% | Threads waiting on the disk (paging) | Same as above — it's a memory problem, not CPU | | Freezes but RAM is fine; CPU pinned near 100% and mostly "kernel/system" | A stuck Windows background service spinning | "If RAM is fine but it still freezes" — ask your Omniscio agent | | Freezes in short _bursts_, RAM fine, right when a lot of work starts at once | A spawn storm — short-lived processes created all at once flood the scheduler | "If RAM is fine but it freezes in bursts" — ask your Omniscio agent to catch it | | Everything hitches, RAM and CPU fine, but exactly ONE drive is pinned while the others sit idle | A Windows file-crawler (`InventorySvc`) walking a drive full of project folders | "If RAM is fine but one DRIVE is pinned" — ask your Omniscio agent to confirm and disable it | | Used to run lots of sessions, now even a few crawl | A build from before the fixes, or a leaked background feature | Widen start spacing (Tier 2.1); relaunch to pick up shipped fixes (Tier 2.2); turn off unused features + restart (Tier 2.3). Running fewer sessions is never the fix — report it | | System drive filling up / won't boot | Abandoned worktrees + a growable pagefile | Sweep worktrees (Tier 2.4); cap the pagefile (Advanced) | | Installs, builds, or file-heavy work drag; antivirus always busy | Antivirus real-time-scanning every file operation | Defender exclusion, or move that work to a Dev Drive (Advanced) | | Defender ("Antimalware Service Executable") stays a top CPU user _after_ you've excluded everything | Behavior Monitoring watching your running sessions — exclusions don't stop it | Turn off Behavior Monitoring, keep real-time protection (Tier 2 → Advanced) — ask your Omniscio agent | | Typing or scrolling is laggy | Heavy rendering on a busy chat | Real-conversation layout + Low Power Mode (Tier 1) | | Only Omniscio is slow while the rest of the computer is fine — worst during heavy file work | Omniscio's database sharing a physical disk with the busy work | Move Omniscio's data folder to a quiet drive (Tier 2 → Advanced) — ask your Omniscio agent | | The Omniscio window freezes while sessions run | The interface is being crowded off the CPU | Reserve + dedicate a CPU core (Tier 1, Windows) | | Builds/tests bog the machine down | Heavy local work competing with you | Run it off-hours or in the cloud (Tier 3) | | Git actions (worktree creation, checkouts) drag; git processes do huge disk I/O _(developers)_ | A bloated git object store — tens of thousands of loose files | "If you're a developer and git actions feel slow" — ask your agent to compact it (Omniscio closed) | | Available RAM keeps dropping but your own programs aren't using much (worst on a Dev Drive) | Windows' file cache ballooned (a ReFS Dev-Drive quirk) | Restart clears it; ask your agent to cap the Windows file cache (Tier 2 → Advanced, the Dev Drive note) | | Omniscio's own database has grown to several GB | The database file only ever grows; deleted chats leave empty space inside it | Settings → Diagnostics → "Reclaim disk space" (Tier 2.5) | If none of this helps, Omniscio keeps detailed timing logs: **Settings → Diagnostics → Startup Trace** (slow launch) and **Interaction Trace** (laggy clicks/typing). Attach them to a bug report. ## Related The overview, the other parts, and everything else worth reading next all sit on [Computer feels slow? A step-by-step fix-it guide (free fixes first, new hardware last)](slow-computer.md).