auto-cpufreq 3.2 just landed in Debian's official repositories. Here's how to let a daemon do the AC/battery juggling your laptop's default governor never will.

Most Linux laptops run their CPU governor the same way regardless of what powers them. Plugged into the wall at your desk or clinging to the last 12% on a train, the kernel mostly picks the same performance profile — which means you're either wasting power on battery or leaving performance on the table on AC. The power-profiles-daemon that ships with GNOME helps, but it's a blunt instrument. auto-cpufreq is the precision one, and version 3.2 — released October 5 — just got a lot easier to install.

Why a daemon, not a setting

CPU frequency scaling on Linux is governed by scaling governors (powersave, performance, schedutil) and, on Intel, by Hardware P-States (HWP) letting the CPU itself make fast frequency decisions. The catch: nobody flips these automatically when you unplug. auto-cpufreq is a small daemon that watches your power source and charger state and switches CPU settings — governors, turbo boost, energy performance preferences, platform profiles — between profiles you define for battery and AC. It is the automation layer that should have been there all along.

Installing: 3.2 changed the game on Debian

The headline change in auto-cpufreq 3.2 isn't a feature at all — it's packaging. After years of living in AUR packages, a Snap, Nix flakes, and a source installer, auto-cpufreq finally has a native package in Debian's official testing repositories:

sudo apt install auto-cpufreq

That's it — a systemd unit, a Polkit policy, and a desktop entry come along in the box. On other distributions the established routes still work: the Snap (snap install auto-cpufreq), the AUR package on Arch-based systems, and the upstream source installer (sudo ./auto-cpufreq --install from the cloned repo). Note the daemon historically conflicted with power-profiles-daemon, so disable that first — 3.2 improves native handling of it, but running two power managers is still asking for a fight.

The config that matters: charger vs battery

The entire philosophy lives in /etc/auto-cpufreq.conf, split into sections for each power state. A practical starting point for an Intel laptop:

[charger]
# plugged in: give me the performance
governor = performance
turbo = auto
energy_performance_preference = performance
platform_profile = performance

[battery]
# unplugged: sip, don't gulp
governor = powersave
turbo = never
energy_performance_preference = balance_power
platform_profile = low-power

Two 3.2 features worth calling out. First, Intel HWP Dynamic Boost is now configurable per-profile — and enabled by default when you're on AC. It toggles /sys/devices/system/cpu/intel_pstate/hwp_dynamic_boost, giving the CPU extra headroom for burst workloads when the charger is connected. Flip it explicitly in your config:

hwp_dynamic_boost = false   # in [battery], if you want bursts locked down on the go

Second, platform profile reporting (auto-cpufreq --pp) exposes what your firmware thinks the power mode is — low-power, balanced, performance — so you can confirm the profile you asked for is the one the firmware actually accepted. Manufacturers' firmware sometimes overrides or ignores kernel requests; now you can see it.

Verify, don't assume

After enabling the daemon, the command that earns its keep is the simplest one:

sudo auto-cpufreq --stats

It shows the live CPU state: current governor, frequencies, core temps, battery charge/discharge rate. Run it once on battery and once on AC, a minute apart, and you'll see the daemon doing its job. Version 3.2 unified the reporting between the CLI and the GTK interface, so both views finally agree — and it now reports the effective power and frequency settings, fixing cases where tools claimed a low-power state the hardware never actually entered.

For battery-charging discipline — keeping a mostly-docked laptop at 80% instead of floating at 100% — the config supports charging thresholds on supported hardware (enable_thresholds, start_threshold, stop_threshold). Support varies by vendor and kernel module, so treat it as a check-your-hardware feature, not a guarantee.

The operator's take

Laptop power management is one of those things that feels invisible until it isn't: the fan that screams during a video call, the battery that melts through a flight. auto-cpufreq's approach is refreshingly mechanical — no machine learning, no mysterious "optimization," just a daemon that applies the settings you'd apply yourself if you remembered to. With 3.2 in Debian's repositories, the excuse of "I'll set it up later" is officially retired. Set it once, forget it, and let your hardware behave like it knows where the charger is.

Sources: auto-cpufreq 3.2 release (github.com/adnanhodzic/auto-cpufreq); Linux Compatible and Linuxiac coverage, October 5, 2026.