auto-cpufreq 3.2.0 lands in Debian's repos, adds Intel HWP Dynamic Boost and platform-profile reporting
auto-cpufreq 3.2.0 is out now, and the biggest change isn't a feature. It's that a widely used open-source laptop battery saver just got a native package in Debian's official repositories.
For years auto-cpufreq reached Linux users through a soup of channels. There's a source installer for Debian, Ubuntu, Fedora, RHEL, Arch-based distros, openSUSE, Void, and Solus, plus an official Snap, an AUR package, a Gentoo ebuild, and a NixOS flake. You could always get it. It just never lived cleanly inside Debian's own apt database.
3.2.0 fixes that. Contributor filhocf pushed a self-contained .deb that adds a debian/ directory without touching the core code. Runtime dependencies land in system site-packages, wrapper scripts go to /usr/bin/, and there's a systemd unit, a Polkit policy, and a desktop file. Debian users can now simply run sudo apt install auto-cpufreq.
The path there wasn't clean. The contributor tripped over a missing systemd unit that broke the packaging helper, and the --stats command falsely claimed the daemon wasn't running whenever it actually was. Both got patched. The maintainer also made one specific request: don't auto-start the service on install. That's deliberate. auto-cpufreq wants the user to deploy the daemon through auto-cpufreq --install, not have it happen behind their back.
HWP Dynamic Boost, now on by default on AC
The other headline feature is more in the weeds, which is where this tool tends to live. Intel HWP Dynamic Boost is a mechanism in the intel_pstate driver that raises the minimum P-state when a task wakes up from I/O wait. The kernel says it exists to improve responsiveness during short bursts, but on most laptops it stays off unless userspace turns it on.
Contributor lucasleocs added a config key called hwp_dynamic_boost for both the [charger] and [battery] sections. You set it the way Python's ConfigParser expects: true, yes, on, or 1. Leave it blank and nothing changes. Point it at unsupported hardware and the setting is silently skipped.
The more interesting choice arrived separately, though. Hodzic reasoned that enabling Dynamic Boost on AC "could have value... as then it kicks in when IO is high, finishes what it needs to do and goes back to powersave." So 3.2.0 flips it on by default when plugged in and leaves it off on battery. Switch between the two and it toggles on its own, staying close to what the kernel would do anyway. Batteryless systems follow the charger profile, so they get it enabled too.
Not cheap to reason about, but that's the point. The tool wants to be clever without being in your way. And honestly, enabling a performance feature on AC is a fine default for most people who are plugged in precisely so they don't have to think about power settings at all.
Platform profiles that finally show up
The third feature tackles something that quietly confuses people. A Samsung Galaxy Book 4 can be led into a conservative powersave governor by auto-cpufreq while the firmware simultaneously runs a performance platform profile. The tool then reports a low-power state while the machine runs hotter and louder than the numbers suggest.
That's the kind of thing you'd only know if you'd actually been fooled by a Galaxy Book 4 in person. This release prefers the richer per-handler class API under /sys/class/platform-profile/ over the older aggregate ACPI interface, falling back only when needed. A new read-only command, auto-cpufreq --pp, reports the current profile, the available choices, and the provider that owns them. You can see the platform policy instead of guessing at it.
Writes stay fail-closed now. If the tool can read the current profile but can't get reliable available choices, it stops changing things. A configured profile the kernel doesn't advertise gets rejected rather than written blindly, and the change is read back afterward to confirm it stuck. The PR was validated on a Galaxy Book 4 and a Lenovo ThinkPad X1 Carbon.
The long tail of fixes
There's a lot of bug-fixing packed in here, too. One PR (#958) makes write failures actually report instead of silently pretending they succeeded, which settles a cluster of long-standing complaints. Another (#963) fixes battery detection on systems with multiple power supplies, which matters because the HWP Dynamic Boost default policy depends on knowing whether you're plugged in at all.
The project also re-licensed itself to GPL-3.0-or-later and bumped the idna dependency from 3.10 to 3.15 for a security fix. Small housekeeping that you rarely see called out, but it matters when you're trusting a daemon with your power settings.
Still a hobby project at heart
The release note points users to a discussion thread and a Discord community, crediting the same three contributors — lucasleocs, shadeyg56, and emfox. It's worth a moment of context: creator Adnan Hodzic began this in 2022 as a "10-day vacation project." Six years later it's reportedly sitting at around 100,000 users, roughly 7,800 GitHub stars, and 611-plus commits. A YouTube blog series framing the whole arc reads like a manifesto.
The project still explicitly wants co-maintainers and open-source developers to help shape what comes next. If you've ever wanted to pitch in, that call is still open.
How to get it
Source users can run sudo auto-cpufreq --update, which fetches the published release tag and installs it atomically, building and verifying a new generation before selecting it. Debian users should be able to reach it through apt as of this release. Snap, AUR, Gentoo GURU, and NixOS users keep using their existing channels. As always, check your live state with auto-cpufreq --stats after installing the daemon.
Head here to the auto-cpufreq GitHub repository full the full release notes.
