auto-cpufreq
auto-cpufreq is a Linux daemon that automatically optimizes CPU frequency scaling and power management based on battery state, CPU load, and temperature. It aims to extend laptop battery life without manual intervention while maintaining performance when needed.
Key facts
Objective fields from the source. Values we can't verify are shown as “Unknown” rather than guessed.
| Field | Value |
|---|---|
| Repository | AdnanHodzic/auto-cpufreq |
| Owner | AdnanHodzic |
| Primary language | Python |
| License | LGPL-3.0 — OSI-approved |
| Stars | 7.6k |
| Forks | 351 |
| Open issues | 80 |
| Latest release | v3.0.0 (2026-01-11) |
| Last updated | 2026-06-07 |
| Source | https://github.com/AdnanHodzic/auto-cpufreq |
What auto-cpufreq is
Python-based Linux system daemon that monitors battery state, CPU usage, temperature, and system load to dynamically adjust CPU governors and turbo boost settings. Supports Intel, AMD, and ARM architectures with config-file and CLI-based overrides for frequency scaling policies.
Get the auto-cpufreq source
Clone the repository and explore it locally.
git clone https://github.com/AdnanHodzic/auto-cpufreq.gitcd auto-cpufreq# follow the project's README for install & configurationNeed it deployed, integrated, or customized instead? DEV.co ships production installs.
Best use cases
Implementation considerations
- Installation via git clone only (not zip download) due to git-based versioning; pre-built snap/AUR packages available but snap lacks GUI due to confinement constraints.
- Requires root/sudo for daemon installation and frequency scaling; verify kernel supports cpufreq governors (powersave, performance, schedutil, etc.) before deployment.
- Configuration via CLI flags, config file, or runtime overrides (--force governor, --turbo); no central policy engine—per-device tuning recommended for heterogeneous fleets.
- Battery charging threshold support limited to specific devices; verify hardware compatibility before relying on this feature.
- Conflicts with TLP and similar tools; requires audit and removal of competing frequency-management daemons before install.
When to avoid it — and what to weigh
- Non-Linux Systems — Explicitly Linux-only; requires cpufreq kernel module support and /sys/devices/system/cpu interfaces. Not portable to Windows, macOS, or non-POSIX platforms.
- Unsupported CPU Architectures — Only Intel, AMD, and ARM CPUs listed as supported. Systems with other architectures (RISC-V, MIPS, etc.) will not function.
- Real-Time or Hard Latency-Sensitive Workloads — Daemon-based frequency scaling introduces unpredictable latency; systems requiring deterministic CPU behavior (kernel RT, audio production) should use manual static governors instead.
- Concurrent Frequency Management Tools — README explicitly warns against running alongside TLP (same frequency-setting scope) due to risk of conflicts and overheating. Requires tool deconfliction or deep configuration expertise.
License & commercial use
Licensed under LGPL-3.0 (GNU Lesser General Public License v3.0). Permits commercial use, modification, and distribution provided derivative libraries/binaries carry LGPL-3.0 notice and source availability is offered. Statically-linked commercial applications may have compliance obligations requiring legal review.
LGPL-3.0 permits commercial use and distribution. However, LGPL-3.0 requires that if you link auto-cpufreq statically into a proprietary binary, recipients must be able to relink with modified LGPL source. For SaaS or preinstalled appliances, ensure compliance pathways are documented. Recommend legal review before shipping in closed-source commercial products.
DEV.co evaluation signals
Editorial assessment — not user reviews. Directional, with an explicit confidence level.
| Signal | Assessment |
|---|---|
| Maintenance | Active |
| Documentation | Strong |
| License clarity | Clear |
| Deployment complexity | Low |
| DEV.co fit | Good |
| Assessment confidence | High |
Runs as root/daemon with direct kernel cpufreq access; no documented SELinux or AppArmor profiles. No CVE history visible in provided data. Input validation for config files and CLI flags not detailed—sanitize custom config to avoid injection. Snap package provides isolation layer; direct install exposes full system access.
Alternatives to consider
TLP
Mature power management suite with broader scope (disk I/O, USB, wake timers); auto-cpufreq explicitly aims to replace TLP's frequency-scaling role but TLP remains valid for comprehensive power tuning where conflicts can be managed.
cpufreq / indicator-cpufreq
Manual frequency/governor switching; requires user intervention vs. auto-cpufreq's automation. Lower complexity but trades convenience for control.
thermald
Thermal-only management; does not replace frequency scaling but complements auto-cpufreq. Orthogonal scope—both can run safely together per README.
Build on auto-cpufreq with DEV.co software developers
Integrate auto-cpufreq into your Linux infrastructure or development pipeline. Our DevOps and custom software teams can help audit, deploy, and maintain frequency-scaling automation at scale.
Talk to DEV.coRelated open-source tools
Surfaced by semantic similarity across the DEV.co open-source index.
Related on DEV.co
Explore the category and the services that help you build with it.
auto-cpufreq FAQ
Can I run auto-cpufreq and TLP together?
Does auto-cpufreq support my laptop?
Why does the Snap package not have a GUI?
How do I report a bug or get help?
Work with a software development agency
From first prototype to production, DEV.co delivers software development services around tools like auto-cpufreq. Our software development agency staffs experienced software developers and web developers for custom software development, web development, integrations, and ongoing support across open-source observability and beyond.
Ready to Optimize CPU Performance & Power?
Integrate auto-cpufreq into your Linux infrastructure or development pipeline. Our DevOps and custom software teams can help audit, deploy, and maintain frequency-scaling automation at scale.