# Zenith: a terminal system monitor with zoomable charts for Linux and macOS > Zenith is a Rust TUI that pairs a top-like process table with CPU, memory, network, disk and optional NVIDIA GPU charts. It builds from source with Cargo, ships in distro repositories, and stores performance data between runs. **bvaisvil/zenith** — Zenith - sort of like top or htop but with zoom-able charts, CPU, GPU, network, and disk usage - Repository: https://github.com/bvaisvil/zenith - Stars: 3,055 · Forks: 84 - Language: Rust - License: MIT - Published: 2026-09-24 · Updated: 2026-09-24 · Language: en - Canonical page: https://hysenlabs.com/projects/bvaisvil-zenith ## What Zenith adds to a top-like process table The README describes Zenith as "sort of like top or htop but with zoom-able charts, CPU, GPU, network, and disk usage." That sentence is the whole pitch, and it is accurate about where the project sits. A conventional top clone answers one question: what is running right now and who is eating the CPU. Zenith keeps that process table, adds per-process disk usage, and puts time-series charts beside it so you can see whether the spike you are staring at started thirty seconds ago or has been building for ten minutes. The intended user is someone on a Linux or macOS box who already has a terminal open and does not want to start a browser-based dashboard, a Prometheus stack, or a desktop app to answer a quick question about system load. The README also lists battery percentage, time to charge or discharge, power used, disk free space, NIC IP addresses, and CPU frequency as quick glances. Those are the details you normally assemble from three or four separate commands. It is not a fleet monitoring tool. There is no server, no remote agent, no alerting described in the README, and no export format documented. Everything happens inside one terminal window on one machine. ## How the charts, process table and saved history fit together Zenith is written in Rust and draws through ratatui with the crossterm backend, both pinned in Cargo.toml. The data layer is split: heim, pulled from a fork on the zenith_changes branch with the full feature set, and sysinfo 0.37. On Linux there are two extra dependencies, linux-taskstats and procfs, which is the visible reason per-process disk usage and delay accounting are Linux-only. Battery data comes from the starship-battery crate. Persistent history is the design decision that separates Zenith from htop. The README says performance data is saved between runs, and Cargo.toml shows flate2 and bincode in the dependency list, which is consistent with a compressed serialized snapshot written to disk. The practical consequence is that when you start Zenith you are not starting from an empty graph. You can scroll back in time and zoom the chart views, which is only meaningful because the previous run left data behind. GPU metrics are compiled in, not runtime-detected. The nvidia feature pulls in nvml-wrapper 0.10.0, and without that feature the binary has no GPU path at all. Per-process GPU usage is listed as part of the NVIDIA feature, so on an AMD card the GPU charts are simply absent rather than degraded. Delay accounting is also conditional: the README states it works on Linux when running zenith with root permissions, which means the same binary shows more information depending on how you launched it. ## Installing Zenith and reading your first chart The fastest path on Debian or Ubuntu is the deb-get route the README documents. First install deb-get itself, then use it for Zenith, then keep it current with the same tool. ```bash sudo apt install curl curl -sL https://raw.githubusercontent.com/wimpysworld/deb-get/main/deb-get | sudo -E bash -s install deb-get deb-get install zenith deb-get update deb-get upgrade ``` On Arch, Zenith is in the extra repository, so pacman is enough. The AUR also carries zenith-git and zenith-bin, and the README notes that zenith-bin reuses the deb package to avoid a source build. ```bash pacman -S zenith ``` On macOS, Homebrew installs the packaged build. ```bash brew install zenith ``` If you want the current master or the NVIDIA build, Cargo is the route. The README gives the plain install and the feature-flagged variant separately. Expect the NVIDIA build to need the driver libraries present at link time, since nvml-wrapper binds against them. ```bash cargo install --git https://github.com/bvaisvil/zenith.git cargo install --features nvidia --git https://github.com/bvaisvil/zenith.git ``` Building from a clone needs rustc 1.40 or newer plus libclang development packages, then a release build. The Makefile wraps this and auto-detects NVIDIA on Linux. ```bash sudo apt-get install libclang-dev cd zenith cargo build --release make && sudo make install ``` When it starts, the README's screenshots show the layout: charts across the top, quick-glance values, and a filterable process table below that you can sort, signal, and reprioritize. The first thing worth doing is letting it run for a few minutes so the charts have something to draw, then zooming in on a spike to confirm the history from the previous run is still there. ## Where Zenith is the wrong tool Platform coverage is the first hard boundary. The README lists Linux and macOS as current platforms and BSD and Redox OS as planned. Windows is not mentioned anywhere, so if your team is on Windows this is not a candidate at all. The GPU story is narrower than the feature list suggests. NVIDIA support requires compiling with the nvidia feature, and the README states the minimum supported NVIDIA driver version is 418.56. AMD GPU metrics appear only under planned features. If your fleet is AMD or Intel integrated graphics, the GPU half of Zenith does not exist for you. The Makefile's NVIDIA detection is a known sharp edge that the README itself calls out. It says that if detection is wrong, or if the installation is broken in the specific way where libnvidia-ml.so.1 is present but libnvidia-ml.so is not, you should skip it explicitly with the base target. That is a real failure mode, not a hypothetical one, and it means a plain make can produce a binary that fails at runtime on a machine where the driver is half-installed. Finally, Zenith is a TUI. There is no documented HTTP endpoint, no Prometheus exporter, no JSON output. If you need to feed metrics into a dashboard or an alerting pipeline, you are looking at the wrong class of tool. It is also not a profiler: it tells you which process is using resources, not which function inside it is. ## Zenith against htop and btop htop is the baseline everyone knows. It is a process viewer with a static set of meters at the top, and it does not persist anything between runs. Close it and the history is gone. It also has no concept of per-process disk usage or GPU metrics. Zenith's difference is the time axis: charts you can zoom and scroll because the data survives the process exit. btop is the closer comparison, since it also draws graphs and has a heavier visual style. The distinction that matters here is the data model rather than the look. Zenith's saved-between-runs history and its Linux-specific per-process disk accounting via linux-taskstats and procfs are the concrete mechanisms. If you want a single binary that starts instantly with no state on disk, a stateless monitor is the better fit; if you want to look backwards after something already happened, Zenith's persisted history is the reason to pick it. For GPU work specifically, the comparison is not another TUI but nvidia-smi, which reports utilization and per-process GPU memory on NVIDIA hardware without any build flags. Zenith's advantage there is putting that information in the same view as CPU and disk rather than in a second terminal. ## Maintenance, licence and what upgrading costs The repository is not archived, and the last push was on 2026-09-02, the same day release 0.15.1 was tagged. The previous releases were 0.15.0 on 2026-05-08 and 0.14.3 on 2026-01-09. That cadence, roughly a minor release every few months with patch releases in between, is the practical upgrade story: you are not chasing a fast-moving target, but you should expect to rebuild or reinstall a few times a year. Zenith is MIT licensed, which is permissive and imposes no copyleft obligation on your own code. That is a statement about the licence text, not legal advice; if you redistribute a modified binary, read the LICENSE file in the repository rather than this paragraph. The upgrade cost is mostly about how you installed it. If you came in through deb-get or pacman, upgrading is one command and the toolchain never enters the picture. If you installed with cargo install --git, you are tracking master, and every upgrade means a fresh compile against whatever the current dependency set is. That matters more here than for a typical Rust CLI because the heim dependency is a git fork on the zenith_changes branch rather than a crates.io release, so the build depends on a branch that the project controls. The static build path adds another wrinkle: the README states that NVIDIA drivers normally do not ship static libraries, so make linux-static skips GPU support unless you set BUILD_NVIDIA=true and accept dynamic linking for that executable. ## Conclusion Adopt Zenith if you already live in a terminal on Linux or macOS and want historical charts next to a process table, and you accept that the Rust toolchain plus libclang are build prerequisites unless a distro package fits. Skip it on Windows, BSD, or AMD GPUs, and skip it if you need a supported library API rather than a TUI. Verify first that your distro package matches release 0.15.1, that your NVIDIA driver is at least 418.56 if you want per-process GPU metrics, and that the Makefile's NVIDIA auto-detection behaves on your machine, falling back to make base if it does not. ## FAQ ### How do you install Zenith on Linux or macOS? On Debian or Ubuntu the README documents deb-get, on Arch it is in the extra repository so pacman -S zenith works, and on macOS Homebrew installs it with brew install zenith. Cargo can install from the git repository, with --features nvidia for GPU support. ### Is Zenith still active? The repository is not archived and the last push was on 2026-09-02, the same day version 0.15.1 was released. The prior releases were 0.15.0 on 2026-05-08 and 0.14.3 on 2026-01-09. ### How do you install Zenith with NVIDIA GPU support? Install with cargo install --features nvidia --git https://github.com/bvaisvil/zenith.git, or build from a clone with cargo build --release --features nvidia. The README states the minimum supported NVIDIA driver version is 418.56. ### Does Zenith run on Windows or BSD? No. The README lists Linux and macOS as current platforms, with BSD (OpenBSD/FreeBSD) and perhaps Redox OS under planned platforms. Windows is not listed at all. ### What happens if the Zenith Makefile detects NVIDIA incorrectly? The README says to skip NVIDIA explicitly by building the base target instead, as in make base && sudo make install. This covers the case where libnvidia-ml.so.1 is present but libnvidia-ml.so is not. ## Sources - [bvaisvil/zenith on GitHub](https://github.com/bvaisvil/zenith) - [Issues](https://github.com/bvaisvil/zenith/issues) - [License: MIT](https://github.com/bvaisvil/zenith/blob/master/LICENSE) - [README](https://github.com/bvaisvil/zenith/blob/master/README.md) - [Releases](https://github.com/bvaisvil/zenith/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/bvaisvil-zenith