jolt shows you which processes are eating your laptop battery

The problem is attribution, not a percentage

The About section states the aim plainly. jolt helps laptop users understand what is draining their battery, providing real-time insights into power consumption, process energy usage and battery health in a clean, themeable TUI. The interesting part is what it adds to what the operating system already tells you. macOS and Linux both report a battery percentage, and a percentage tells you almost nothing about which of the twenty processes running is responsible. The feature list is the decomposition. Battery status covers charge percentage, time remaining, health and cycle count. Power monitoring gives system power draw with a CPU and GPU breakdown. Process tracking sorts processes by energy impact with colour-coded severity. Historical graphs track battery and power trends over time. Themes give more than ten built-in themes with dark and light auto-detection. A background daemon collects historical data even when the TUI is not running. And process management lets you kill energy-hungry processes directly, which turns a diagnostic into an action. That last one is the feature that makes it more than a dashboard, though it is also the one to think about before you press the key.

Installing it five ways, including a Nix flake

The installation section covers the usual set of routes and one that is less common. The quick install pipes a script into a shell:

curl -fsSL https://getjolt.sh/install.sh | bash

Homebrew is a tap install, brew install jordond/tap/jolt. Cargo installs the TUI binary as jolt-tui. Nix has three options, running directly with nix run github:jordond/jolt, installing to the profile with nix profile install github:jordond/jolt, and adding it to configuration.nix through a builtins.getFlake call that pulls the default package for the current system. And from source is a clone, a cargo build --release and running the binary from the target directory. The Cargo package name is jolt-tui while the repository and the executable are jolt, which is a small inconsistency worth knowing if you script an install. The Nix route is the one worth pointing a colleague at, because it is the only one that does not require trusting a script fetched over the network.

A subcommand for every job, and one for scripting

The usage output is a standard clap layout and it shows that jolt is a tool with several modes rather than only a TUI. The commands are ui to launch the terminal UI, which is the default, pipe to output metrics as JSON for scripting, debug to print system and battery debug info, config to manage configuration, theme to manage themes, daemon to control the background daemon, history to view and export historical data, and logs to view daemon logs. The pipe subcommand is the one that makes jolt composable rather than purely visual, since it means the same measurement can feed a script, a dashboard or a cron job, and the history subcommand has an export function, so the collected data leaves the tool. There is a global --log-level option taking error, warn, info, debug or trace. The keyboard shortcuts in the TUI are the same kind of vocabulary as a pager, with j and k to navigate, Enter to expand or collapse a process group, K to kill the selected process, g to toggle the graph between battery and power, t for the theme picker, s for settings, h for history, ? for help and q to quit.

The daemon is what makes history possible

There is a daemon subcommand with a start, status and stop, and the feature list describes it as a background daemon that collects historical data even when the TUI is not running. That is the piece that separates a live meter from a monitor, since a battery percentage at 14:00 tells you nothing about what happened between 09:00 and now. Without a daemon, a TUI only has the data it saw while it was open, and the historical graph feature would be limited to the current session. The dependency list explains how it runs, with daemonize at 0.5 for detaching the process, rusqlite with the bundled feature for storage, and tracing-appender for writing the logs that the logs subcommand then reads. Storage is a local SQLite database, and the workspace has a crates/protocol member, which is the natural place for the shared message format between the daemon and the UI.

Platform support is not uniform, and the table says so

The platform support table is short and the differences matter. macOS on Apple Silicon has battery and power metrics with full support. macOS on Intel has battery but no power metrics, so battery data only. Linux has both, with the note that it requires RAPL permissions, and there is a separate Linux setup guide for configuring power metrics. The Apple Silicon row is the reason the macOS side of the project is worth understanding. On an Intel Mac you get the battery state and the process list but not the system power draw, which is the number you would use to sanity-check the process attribution. The RAPL requirement on Linux is the equivalent kind of constraint, since RAPL is the interface the hardware exposes for energy reading and it is not readable by an ordinary user without extra permission, so a Linux user who installs jolt and sees no power metrics has probably not granted it. The crate list backs the platform split, with core-foundation and core-foundation-sys for the macOS side and libc for the Unix side.

How the workspace is arranged

The Cargo manifest describes a four member workspace with the cli binary and three internal libraries. crates/protocol, crates/theme and crates/platform are the internal crates, and each is published to crates.io with the version tied to the workspace package, which is why the manifest notes the version required for crates.io publishing. That split is the design: the protocol crate defines how the daemon and the UI exchange data, the theme crate holds the theme definitions, and the platform crate is the layer that knows how to read battery and power on macOS and Linux, so the TUI code does not contain platform conditionals. The other dependencies are the expected Rust stack, with ratatui and crossterm for the TUI, clap for the command line, tokio for async, tracing for logging, sysinfo and systemstat for process and system information, and starship-battery at 0.11.1 with a comment explaining that it fixes macOS issues and linking to the relevant upstream issue. The release profile is tuned, with link time optimisation on, one codegen unit, symbols stripped and opt-level 3. The repository also carries a flake.nix, an install.sh, a website/ directory, an assets/ directory and a docs/ directory.

Editorial conclusion

Adopt jolt if you want to see, on your own machine, which processes are responsible for a short battery life, and you are comfortable with a terminal application and a background daemon. Do not adopt it for a fleet of machines, since it is a local monitor rather than an agent you deploy, and note that macOS on Intel gives battery data only. Verify first that your platform is covered, since Linux power metrics require RAPL permissions and macOS on Intel has no power metrics, that the daemon is acceptable on your machine, since it runs in the background to collect history, and that the install route you pick matches whether you want a packaged binary or a Cargo build.

Frequently asked questions

Official sources

1. jordond/jolt on GitHub
2. License: MIT
3. Project website
4. README
5. Releases