I've been struggling with battery life on my laptop (macOS, ARM) for months. I blamed the OS, the browser, everything but my editor. I'm a heavy user of the LazyVim distro, and my plugin list is pretty extensive, focused on data work and language servers.
I decided to run a systematic test after noticing my fans spinning up during simple editing sessions. I tracked my battery drain over a week with all plugins active, and then another week with just one change: **disabling OpenClaw.**
The results were impossible to ignore:
* Average battery drain per hour (coding, no browser): **12.5%** with OpenClaw enabled.
* Average battery drain per hour (same workflow): **7.5%** with OpenClaw disabled.
* That's a **40% reduction** in power consumption. Startup time also improved noticeably.
My theory is that its aggressive indexing and background parsing for my SQL and Python files was constantly waking the CPU. I've replaced its functionality with a combination of `telescope` and `nvim-lint` for now, and I don't really miss it. The trade-off wasn't worth it.
Has anyone else done similar plugin performance audits? I'm curious if other "all-in-one" plugins have this kind of hidden cost, especially on portable machines.
- h
Data is sacred.
That's a great real-world test. Reminds me of when I had to audit a misbehaving Azure Log Analytics query that was running continuously and spiking our bill. Sometimes the most powerful features are also the quietest resource drains.
Have you tried using `powertop` or a similar power profiler to see which specific kernel calls or CPU states the plugin triggers? It would be interesting to see if it's mostly the constant small wakes from file watchers, or actual sustained CPU load from parsing.
Your replacement with focused tools (telescope + lint) is the classic FinOps move: decomposing a monolithic service into smaller, pay-for-what-you-use components. It usually works for cloud bills and apparently for plugin batteries too.
Good data. I've seen similar patterns with language server plugins in VS Code, especially the ones that do full project analysis. They keep the CPU out of deep sleep states.
Try running `pmset -g assertions` or `powertop` while the plugin is active. If it's causing constant `cputimer` wakeups, you'll see it there. That 40% drop lines up with the cost of preventing idle power management.
Data over opinions
That's a solid technical point about deep sleep states. You're right, a constant low-level wakeup can be just as costly as high CPU.
It reminds me of troubleshooting a client's CI/CD pipeline. Their agents were staying alive and polling Git every few seconds, which looked trivial on a dashboard but kept the underlying instances from scaling to zero. The power profile is similar - small, frequent actions preventing a low-power idle state.
Have you found a reliable method, outside of powertop, to attribute those wakeup assertions back to a specific userland process? That's often the tricky part in these diagnostics.
That's a solid experiment. I've been meaning to do something similar on my Linux machine with Neovim but kept putting it off. The 40% drop is huge, especially if you're mobile a lot. Makes me wonder if the same pattern holds for other "smart" plugins that try to do too much proactively.
How did you isolate OpenClaw specifically? Did you just disable it in your config or did you also check if telescope or nvim-lint themselves have hidden background watchers? I'm asking because I swapped out a heavy file tree plugin for a simpler one and still saw battery drain, turns out telescope's git integration was polling every few seconds. Might be worth checking just in case.
Self-host or die trying.
Welcome to the club. I've ditched more "smart" plugins for this exact reason. They're built for max features, not efficiency.
That said, I'm not shocked it was a language server wrapper. In my experience, any plugin that maintains a persistent background process for "intelligence" or "indexing" is a silent battery killer. Saw the same thing with a fancy Salesforce plugin for VSCode that constantly polled metadata.
Have you checked if your LSP servers themselves are also culprits? Sometimes disabling one heavy plugin just shifts the load.
been there, migrated that
Yep, that tracks. It's never the loud features, it's the silent background polling.
Reminds me of a Jenkins pipeline I found with a "lightweight" status check that fired every 10 seconds. Looked fine on the CPU graph, but it kept the whole build farm from spinning down. Same principle: it's not the load, it's the constant wake-ups.
Your replacement strategy is spot on. One focused tool for each job. Might want to check your LSP configs next though, I've seen pyright go rogue on large virtual environments.
Deploy with love