Idle Saver

A VS Code extension that reclaims memory while you are idle: it trims working sets, puts helper processes into Windows' efficiency mode, and optionally restarts analysis servers that have leaked heap.

Windows only. The memory levers it uses are Win32 APIs with no cross-platform equivalent.

Build and run

cd idle-saver
npm install
npm run compile

Then press F5 in VS Code to launch an Extension Development Host. To install it properly:

npm i -g @vscode/vsce
vsce package
code --install-extension idle-saver-0.1.0.vsix

How it works

Three tiers, driven by a timer that any editor activity resets.

Window focus is the strongest signal available. Alt-tabbing away tells you far more about whether someone left than a keystroke timer does, which is why the unfocused threshold is six times shorter.

The native work happens in scripts/memtool.ps1, a PowerShell process that stays resident for the session and speaks newline-delimited JSON over stdin/stdout. Spawning powershell.exe per call costs 250-400ms, which is far too slow for something that fires on every focus change. The P/Invoke surface is small:

• EmptyWorkingSet (psapi) — the memory lever
• SetProcessInformation with PROCESS_POWER_THROTTLING_STATE — EcoQoS
• SetPriorityClass to IDLE_PRIORITY_CLASS — the other half of what Task Manager labels "Efficiency mode"

Process discovery walks up from the extension host pid to the top-most Code.exe, then collects every descendant. That catches renderers, the pty host, language servers, and any dart or node process VS Code spawned.

What this actually buys you, and what it doesn't

EmptyWorkingSet does not free memory in the way Task Manager's number suggests. It evicts a process's resident pages to the standby list, from which Windows can either hand them to someone else who needs RAM or write them to the pagefile. Come back within a minute and they re-fault straight out of standby, which is nearly free. Come back after an hour under pressure and you eat real disk reads.

So the honest framing: this is useful when you are actually away and something else on the machine needs the RAM. It is theatre if you are pausing to read a stack trace. Windows already reclaims under pressure — the value here is doing it proactively, while you are gone, instead of at the worst possible moment when you are mid-build.

minimumFreeMemoryPercent exists for exactly this reason. It defaults to 25, so the extension stays out of your way until free physical memory is genuinely low.

Two things it deliberately refuses to do:

• Suspend processes. NtSuspendProcess on a language server that holds a file lock or a socket is how you get a hung editor on return. Not worth it.
• Act during debug sessions or running tasks. Throttling the pty host mid Flutter hot reload is actively user-hostile.

The only setting that reclaims memory permanently is restartLanguageServersAfterMinutes. Analysis servers accumulate heap they never return; trimming just pages the garbage to disk. Restarting gives it back for real, at the cost of a re-index when you return. It is off by default — turn it on with something like 20 minutes if you routinely step away for long stretches.

The things that will save you more RAM than this extension

Worth doing regardless. From the numbers in a typical Flutter-on-Windows setup:

Cap the Dart analysis server. Three dartvm.exe processes at ~530 MB combined is the single biggest avoidable cost. In settings:

"dart.analyzerVmAdditionalArgs": ["--old_gen_heap_size=768"]

Also add an analysis_options.yaml that excludes build/, .dart_tool/, and generated *.g.dart files from analysis. The server indexes everything it can see.

Cap the TypeScript server, if you touch any TS or JS:

"typescript.tsserver.maxTsServerMemory": 2048

Stop watching what you don't edit. File watchers are a quiet memory and CPU cost:

"files.watcherExclude": {
  "**/.dart_tool/**": true,
  "**/build/**": true,
  "**/node_modules/**": true,
  "**/.git/objects/**": true
},
"search.followSymlinks": false

Put a ceiling on WSL. By default the WSL 2 VM can claim half your RAM and holds cached memory until you shut it down. In %USERPROFILE%\.wslconfig:

[wsl2]
memory=4GB
swap=2GB

[experimental]
autoMemoryReclaim=gradual

Then wsl --shutdown and wait ~8 seconds for it to take effect. Note that autoMemoryReclaim has been graduating out of [experimental] across releases, and an unrecognised key is ignored silently rather than erroring — check wsl --version against Microsoft's current docs if it doesn't seem to apply.

Audit extensions. Run Developer: Show Running Extensions from the command palette. It shows activation time and lets you profile. A 16-process VS Code tree usually means several extensions you installed once and forgot.

Let Chrome do its own thing. Chrome's built-in Memory Saver discards background tabs on its own and does it better than an external trim, because it can drop the whole renderer rather than page it out. #� �i�d�l�e�-�s�a�v�e�r� � �