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) 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) — 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:

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.
• Don't bother — this one was measured and it LOSES: git's file-system monitor (core.fsmonitor true) is often recommended to make git status near-instant by watching for file changes instead of scanning. On a ReFS worktree drive under an agent fleet it made things worse: across 8 cold/warm pairs on 4 worktrees, 7 were slower with the daemon running, and 25–40% slower on a cold cache — the one win was inside the noise. It also runs one background watcher per repo, with a daemon to start and stop. Skip it here.
• 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.

If ONE worktree feels slow, the cost is the working-tree scan — check that before changing any setting. A tree-wide git read (git diff --name-only HEAD, git status, git ls-files --deleted) has to look at every tracked file; a read that stays inside the index does not. So time both on the same tree:

git -C "<worktree>" ls-files | Measure-Command { git -C "<worktree>" ls-files }   # index only
Measure-Command { git -C "<worktree>" diff --name-only HEAD }                     # working tree

If the index read is ~2 s and the working-tree read is minutes, nothing is wrong with that worktree — and changing its settings will not help. On one real case the same 86,000-path tree returned git ls-files in 2.1 s while git status was killed at 200 s, and a repeated 20,000-file stat sample swung 84× on the identical paths (48,890 µs per file, then 583 µs forty minutes later) with the same ~130 git processes running. That is the drive's metadata cache going cold under a fleet of concurrent scans, and every worktree on the drive shares it. It clears on its own, which is why the slowness appears to move between worktrees — and why re-measuring a few minutes later is the right first response, not a config change. Warming the git index does not repair it: the refresh pays the same cold scan, and a freshly created worktree's index is already valid, so it writes nothing at all.

---

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).