Open-source siltop brings real Apple Silicon power, clock and temperature data to the terminal

What siltop is

A developer has released siltop, an open-source system monitor written in Rust that runs in the terminal on Apple Silicon Macs and surfaces chip-level telemetry that general-purpose tools usually miss on macOS. The project was shared on Hacker News as a "Show HN" post on 17 October 2026, where its author explained the motivation: btop, a popular cross-platform monitor, cannot report power draw, GPU activity or cluster clocks on a Mac.

According to the project's README on GitHub, siltop reports CPU, GPU, Neural Engine and DRAM power in watts, per-cluster clock speeds for the E, P and Super core groups, fan speeds and temperatures, and per-process energy and GPU usage. It supports chips from the M1 through the M5. Notably, none of this requires root privileges, which separates it from asitop and Apple's own powermetrics, both of which need sudo. The README positions it between lean SoC-only tools like macmon, which lacks a process manager, and btop, which has process management but no chip visibility.

How it reads the hardware

The README says all readings come straight from macOS interfaces: the SMC for fans, temperatures and system power, IOReport for CPU and GPU clocks and energy, and Mach and sysctl for CPU, memory and process data. There is no shelling out to ps or powermetrics.

The project also takes an explicit stance on missing data. Where the system refuses to expose a value, siltop shows it as absent rather than substituting a zero. Fanless MacBook Airs display no fan panel, desktops show no battery, and processes owned by other users keep their name and pid but show dashes where the kernel withholds CPU and energy figures. Some power rails publish in batches rather than per sample; between publications siltop holds the last measured value, marks it with an approximate sign and its age, and still counts it in machine totals.

One design choice worth knowing: the CPU graph is frequency-weighted, so a core busy at half its maximum clock counts as half busy. The developer says this is meant to show how much of the chip's real capacity is in use, which is why the number can read lower than Activity Monitor's.

Overhead and interface

The self-reported cost is about 1.3% of one core when sampling every second, which the developer says is roughly half of btop's 2.5% and on par with macmon's 1.4%, measured back to back on an M5 Pro. The single native binary is around 3 MB, redraws only when something changes, and stops sampling entirely when paused.

The interface offers braille-rendered graphs on a shared time axis, themes built from the terminal's own palette with fallbacks down to monochrome, a full "Work" surface and a compact always-on "Glance" window, plus a zen mode that strips everything back to the graphs. A process table adds live filtering, sorting, tree view, app grouping, signal sending, renice and background quality-of-service controls. There is also a one-line diagnostic verdict, such as naming which process is consuming cores or when fans are running hard.

Scripting and fleet features

Beyond the dashboard, siltop can emit single JSON samples or NDJSON streams, expose a Prometheus endpoint on localhost, print a one-line status format for tmux and SketchyBar, raise alerts via shell hooks, record and replay sessions, run a sustained-performance benchmark that watches clocks, heat and throttling, and display several Macs side by side over the user's own SSH connections. The README stresses privacy: the binary links no HTTP stack, the only network activity is an opt-in daily update check through the system curl, and no telemetry is collected.

Availability and limits

siltop requires macOS on Apple Silicon and installs via Homebrew, as a prebuilt arm64 binary (v1.2.1 at the time of writing) or from source with Rust 1.98 or newer. The developer notes the binary is not notarized, so a browser download is quarantined on first run unless cleared, while a curl download is not. Intel Macs and Linux are out of scope: the code compiles elsewhere, but the collectors are stubbed and sample nothing.

Why it matters

Apple Silicon has never shipped with a built-in way to observe real power and clock behaviour, and the tools that can see the chip have historically demanded root. A no-sudo, low-overhead monitor with machine-readable output makes chip-level telemetry practical for everyday use — status bars, scripts, thermal benchmarks and small fleets of Macs — rather than occasional debugging. Its refusal to fabricate missing readings is also a quietly good example of how monitoring tools should behave, and the per-process energy view fills a gap none of the existing options address.