Windows boot got about 5x faster, by feel — startup tuning I did on just one of several machines

2026-06-11 ／ Vol 17 ／ draft at the time of publishing

I run several Windows PCs, each for a different purpose. One of them — a Dell laptop — took oddly long from power button to a usable desktop. Not just "felt slow": measured, about 54 seconds to boot. I don't stand there waiting every single time, but every time I used it, there was that sense of being kept waiting.

So this time I had Claude diagnose it and do the startup tuning. The short version: it now boots about 5x faster, by feel.

Diagnosis: the culprits were "immediate-start" resident services

First I had it survey the current state. The surprise: the heavy resident apps (creative-suite agents, browser auto-launch, and so on) were already disabled. Fast Startup was already on. In other words, those 54 seconds were what remained after all the usual "speed up Windows boot" tips had been exhausted.

What was left was a group of non-Microsoft services set to start "immediately" alongside Windows. Most of them fell into two buckets:

・Update checkers: resident services from Adobe / Google / Logitech whose only job is to watch for updates
・Printer residents: a full set of printer-vendor services sitting idle even while nothing is being printed or scanned

All of them are "nice to have." None of them needs to be running from the moment the machine boots. Update checks can happen later; printer services can wake up when I actually print.

What I did: delete nothing — they just don't load at boot

The fix was simple: switch those services from automatic to manual start. Nothing was uninstalled. Every service is still there, and starts on demand when needed (at print time, for example).

On top of that, exactly 2 startup items were disabled: the Japanese IME's prelauncher (a resident that preloads the IME so it appears faster — the IME itself still works normally) and the printer status monitor.

Conversely, anything where the call was debatable (a cloud-storage-related launcher, for instance) was left alone, on hold. If the gain is small and it might touch daily use, the AI doesn't get to decide on its own.

The design rule I cared about most: everything undoable in one shot

The one thing I specified to Claude from the start: make everything reversible. Alongside the script that applies the changes, it auto-generated an undo script (for REVERT), plus a log of exactly what was changed and how.

So if the printer ever starts acting up, or some update stops arriving, running the revert script once puts everything back the way it was. The "don't delete, just don't load at boot" policy exists for the same peace of mind — nothing has been removed from the system.

One more thing: running services were not stopped on the spot. The changes take effect from the next boot. That avoids the risk of breaking something the moment the work is done — it's the same mindset as reversibility.

The result: about 5x faster, by feel

To be honest, I haven't re-measured the post-change boot time with a stopwatch. So the number is subjective. But using several machines side by side every day gives you a kind of measurement of its own: this one tuned laptop, and only this one, now has a clearly shorter wait from power button to desktop. The difference is big enough that "about 5x, by feel" is the phrase that comes to mind.

Placebo? Maybe — except the untouched machines are right there next to it every day as a control group. The difference is obvious.

Afterwards: the audit AI has been told "this is intentional"

I run a weekly PC audit here — an AI checks the configuration of my machines every Friday. A change in service startup settings is exactly the kind of thing that audit would normally flag as "configuration drift."

So the audit rules were told in advance: "these services being set to manual start is an intentional change, not an anomaly." The AI that made the change and the AI that audits share the same memory, so the change and the reason for it are recorded as a pair. Six months from now I won't be staring at the services list wondering "why is this one set to manual again?" Having every configuration change come bundled with its own memory update is, I think, one of the most practical advantages of running things with an AI.

An honest caveat

I haven't rolled this out to the other machines yet. The same changes are ready to apply, but I want to run this one laptop for a while first and see whether anything around printing or updates gets annoying. There's no reason to rush the rollout.

Fifty-four seconds of boot time is a small thing per occurrence. But something I'd resigned myself to as "slow is normal" got fixed the same day I asked the AI — and it can be undone at any time. Small frictions like this are exactly what's worth picking back up, now that the cost of asking has dropped.