macpow shows where the watts go on an Apple Silicon Mac

Eight macOS interfaces feed one tree

The architecture section is the most informative page in the documentation, because it lists what each source actually provides. IOReport gives the SoC power from the Energy Model and the CPU and GPU frequencies from the DVFS residency tables. The SMC supplies the system power through the PSTR key, the display backlight through PBwo on M5 and Neo and PDBR on M1 to M4, the adapter through PDTR, the WiFi through wiPm, plus temperatures and fans. IORegistry covers the battery, display brightness, keyboard PWM, USB devices, the SSD model and the disk I/O counters. CoreAudio provides the volume level and the mute state. The Mach APIs supply per CPU utilization ticks and the memory statistics. Per process energy comes from `proc_pid_rusage`, network traffic byte counters from `getifaddrs`, WiFi details and Bluetooth devices from CoreWLAN and pmset, and power assertions and audio playback detection from IOPMAssertions. The design note says each source runs in its own thread and updates shared metrics at its own pace, so the interface renders at the configured interval without blocking on a slow source.

The legend is the most honest thing in the tool

Every power figure carries a prefix, and the prefixes say how much the number is worth. A plain value such as `0.123 W` is a measured power taken from a direct hardware reading, an approximation sign means the value is estimated by a model, and a less than or equal sign means it is an upper bound estimate. The rest of the legend is just as careful. A temperature with no marker is a fresh reading, a temperature with a tilde is stale, shown because the sensor read failed, and the last known value is being displayed instead. A row that says `pending…` means the data source has not finished initialising, and a process marked `[dead]` has exited while its energy total is preserved. Colour carries the same information numerically, green below one watt, yellow between one and five, orange between five and ten and red above ten. The point is that a screenshot of this tool is not a set of facts but a set of facts with confidence attached, which is more than most power meters give you.

Per core detail goes down to MHz and to the E and P cores

The SoC breakdown is the part that makes the tool more than a battery gauge. The CPU is broken down into the E and P cores, with per core power, a utilization bar and a temperature, and the GPU, the ANE, the DRAM, the GPU SRAM, the Media Engine, the Camera ISP and the Fabric each have their own row, all from the IOReport Energy Model. The frequencies are real numbers in MHz taken from the DVFS voltage states tables rather than percentages, which is a meaningful difference, because a percentage of a boost clock tells you much less than the clock itself. The utilization comes from the Mach `host_processor_info`, and memory usage comes from `host_statistics64`, reported as used and total in gigabytes. Temperatures are per component and per core, from the SMC sensors for the CPU, GPU, ANE, DRAM, SSD and battery, and the key mapping is described as bank based so that it works across every Apple Silicon generation from M1 to M5 and beyond, including the dual die Ultra parts.

Per process energy is billed energy, and it comes with context

The per process panel is the most interesting part of the interface and the part with the clearest source. The energy is not a guess based on CPU time, it is billed energy from `proc_pid_rusage`, and the list is sized dynamically so the top processes by session energy are the ones shown. Alongside the energy figure the tool reports per process disk I/O rates, network traffic through nettop, the memory footprint, and whether the process has exited. That combination is what makes the panel useful for a question like which build is eating the battery, since a process can be unremarkable in CPU and still expensive in energy because of its I/O. The interface also covers the parts people forget: the display with its brightness, panel class of SDR, HDR or XDR, refresh rate and a live HDR active indicator taken from the IOReport DPB factor for AppleARMBacklight, external display power through DISPEXT, the keyboard backlight with an estimate derived from the IORegistry PWM, the SSD model and interconnect, the fans with an RPM and a cubic power model, and the peripherals including Thunderbolt, Ethernet, WiFi, Bluetooth and USB devices.

Installing and running it takes one command

The tool is published on crates.io, so the shortest install is:

cargo install macpow

Building from source takes the usual four steps:

git clone https://github.com/k06a/macpow.git
cd macpow
cargo build --release
./target/release/macpow

There is a Homebrew tap and a pixi route from conda-forge, and the manifest also carries binstall metadata so the release archives can be installed directly. The binary starts in the terminal interface by default and has a small set of flags for other jobs: `--json` writes structured data to standard output for scripts and dashboards, `--interval` sets the sampling interval in milliseconds with a default of 250, and two diagnostic flags, `--dump` for the IOReport channel names and `--dump-smc` for every SMC key with its type and value. The last one is what you would run on a new machine to see which sensors your particular chip exposes, and the JSON mode is the reason this is more than a toy, since the same data can feed a dashboard or a script.

The interface is a foldable tree with a smoothing window

The display is a tree that can be folded and unfolded with the arrow keys, with plus and minus to expand or collapse everything at once, and the keybindings table is complete enough to use without looking things up. The space bar pins a resource so that an inline sparkline shows its recent history when the terminal is wide enough, the `a` key cycles a time based smoothing window between zero, five and ten seconds, and the `l` key cycles the refresh interval between 250 milliseconds, 500 milliseconds, one second and two seconds. The `r` key resets the accumulated totals and the minimum and maximum values, and the mouse can be used to select rows. The letter keys are stated to work on any keyboard layout, including QWERTY, Russian and Dvorak, which is a small thing that tells you the author has actually used the tool on more than one machine. The JSON mode and the TUI are the same binary, so the same numbers can be watched live and then piped somewhere else.

The package shape tells you what it depends on

The Cargo manifest is small and the dependencies are the hardware interfaces rather than a framework stack. The interface is ratatui at version 0.29 with crossterm at the same version, the command line is parsed with clap, and the Apple specific work goes through core-foundation and core-foundation-sys, with libc for the lower level calls. The `cli` feature is on by default and pulls in ratatui, crossterm, clap and unicode-width, which means the terminal front end is optional and the library can be used as a data source on its own, and there is a `data_sources` criterion benchmark in the repository for measuring that path. The package metadata includes a binstall stanza pointing at release archives, the licence is MIT, and the crate is categorised as a command line utility and as hardware support. The release list shows v0.1.19 from 2026-05-11 with v0.1.17 and v0.1.16 in April 2026, so this is a young tool shipping often, and the version number is still pre one.

Editorial conclusion

macpow suits a developer on an Apple Silicon Mac who wants to know what is consuming power rather than guessing, particularly when a machine is hot, a battery drains faster than expected, or a single process needs attributing. It is a poor fit for an Intel Mac, for Linux or for Windows, since every data source is a macOS interface, and it is a poor fit if you need the figures to be laboratory measurements, because the documentation is explicit that several rows are model based estimates and upper bounds. Before you rely on it, check three things: which rows are measured on your machine and which are estimated, using the legend rather than the numbers, whether the temperature sensors read cleanly on your chip generation, since the tool marks a stale reading with a tilde when a sensor fails, and the version you install, with v0.1.19 published on 2026-05-11 and the last push to the repository on the same day.

Frequently asked questions

Official sources

1. Issues
2. k06a/macpow on GitHub
3. License: MIT
4. README
5. Releases