btop: the prebuilt binary has no GPU support, and the macOS recipe still names old branches

Release binaries and continuous builds are compiled without GPU support

This is the single most important line in the repository for anyone who installs rather than compiles. The news entry that introduced GPU monitoring on Linux states that the binaries provided on the release page and the continuous builds will not have GPU support enabled, and it gives the reason: GPU support relies on loading dynamic GPU libraries, so it will not work when static linking is also used. That produces an awkward pair of facts. The project offers statically compiled binaries for a range of architectures in every release specifically for people having problems compiling, and the prebuilt path and the GPU feature are mutually exclusive. So the easy install gives you no GPU boxes, and the hard install only works if you leave the linking dynamic. If GPU telemetry is the reason you are considering this monitor, budget for a toolchain, and check the GPU compatibility section and the compilation notes before you assume the released artefact will do it.

Intel GPUs expose three metrics, and the rest of the per-device detail is not there

The v1.4.0 news entry adds Intel GPU support and immediately narrows the scope in the same sentence, noting that only GPU utilization, power usage and clock speed are available to monitor. That is the whole of what you get on Intel hardware, and it is worth being clear that this is a monitoring subset rather than a device manager. The interface reflects the same scale. GPU monitoring appears as separate boxes rather than as one panel, and they are toggled with the number keys, where 5 shows or hides GPU 1, 6 does the same for GPU 2, and the sequence continues with 7 and 0. There is also a way to fold the numbers into the Cpu box, which the page notes is not as verbose, and which is configured through the cpu options menu. So if you need per-process GPU attribution or memory-level detail, this is not the tool providing it, and the three Intel metrics are what you should plan a dashboard around.

The AI disclosure rule tightened from a majority of the code to any of the code

The contributing policy changed twice in five months, and the direction matters. The December 2025 entry says submissions where the majority of the code is AI generated must be marked. The March 2026 entry replaces that with submissions where any of the code is AI generated, and defines the scope as code generated by prompting either directly to an LLM or through comment prompting. It carves out one exemption, namely AI suggestions used in autocomplete mode only for boilerplate or other repetitive code. The sanctions are stated plainly: failure to disclose results in a closed pull request, and deliberately trying to obfuscate the use of AI results in an account being blocked from contributing again, while vibe coded submissions where the author does not appear to understand the generated code are dismissed. For a contributor the practical effect is that a two-line change suggested by a model now needs a marker, which is a low bar, and that the penalty for concealment is account level rather than request level.

Windows is a separate repository, with no build workflow in this one

The August 2022 news entry points to a first release of btop4win at github.com/aristocratos/btop4win, and that is where Windows lives. Nothing in this repository builds for it. The continuous build badges at the top of the page cover five platforms, linux, macos, freebsd, netbsd and openbsd, and the root contains a Makefile, a CMakeLists.txt and a cmake directory, with compilation sections indexed for Linux, macOS, FreeBSD, NetBSD and OpenBSD. The documented toolchain is GCC 11, and the build guidance for the BSDs and macOS uses gmake with GNU coreutils. So a Windows user is installing a different project from a different repository, and there is no guarantee that its version numbers, feature set or issue tracker line up with this one. Check which repository a Windows answer came from before you assume the feature you read about exists in the build you have.

The Makefile scrapes the version out of the first hundred lines of the C++ source

There is no version variable in the build file. The Makefile declares MAKEFILE_VERSION as 1.6 for itself, then overrides BTOP_VERSION by running head with a hundred line limit against src/btop.cpp, grepping the output for the text Version =, and cutting the second field using a double quote as the delimiter. The version of the program is therefore a string literal living in the first hundred lines of a C++ file, and the build reads it by pattern match. The consequences are predictable. Move that line further down the file, or reword the label, and the match fails, at which point the shell command falls back to its own default and the binary reports a version that came from nowhere. The repository also carries two build systems maintained side by side, the Makefile and the CMake project, so a change that updates one may leave the other reading stale metadata, and there is no single place to look that guarantees the answer.

GNU date and GNU du assumptions run through the build output

Look at what the Makefile uses to print its own progress. A helper that reports step duration computes an epoch difference and pipes it into the date command with a minus d and an at sign, which is GNU date syntax, and a helper that prints a file with its size shells out to du with the a and h flags. Neither is portable to a stock BSD userland. That is the reason the project's own guidance for macOS and the BSDs is to install GNU coreutils first, and it is why gmake is described as recommended but not required on macOS while being required on FreeBSD. The banner is the same story in a different form, since the Makefile reads pre-rendered escape sequences out of ansi_banner.utf8 in the root. The upshot is that building this on anything other than Linux assumes you have GNU tools available under g-prefixed names, and the porting work lives in the build tooling rather than in the program.

The most complete build recipes on the page are four years old and check out branches that are not main

The two dependency recipes the page gives in full both come from the October 2021 news entry, when macOS and FreeBSD support were work in progress. The macOS one reads:

# Install and use Homebrew or MacPorts package managers for easy dependency installation
brew install coreutils make gcc@11 lowdown
git clone https://github.com/aristocratos/btop.git
cd btop
git checkout OSX
gmake

They are accurate as a record of that moment, and they are still the only complete dependency lists on the page. But the default branch of this repository is main, the index now carries separate compilation sections for macOS, FreeBSD, NetBSD and OpenBSD, and the news entry itself describes those branches as having had memory leaks and problems with the processes cpu usage calculation at the time. Following the recipe literally therefore lands you on a branch that is not the release line. Treat it as a list of dependencies, not as a procedure, and confirm the branch against the compilation section you actually need.

The last tagged release is about five months behind the last commit

The release history shows v1.4.7 on 2026-05-01, v1.4.6 on 2025-12-26 and v1.4.5 on 2025-09-19, while the last push to main is dated 2026-09-26. The branch is therefore being worked on well past the newest tag, which matters when you are deciding what to run. The root also shows the distribution surfaces: a snap directory, a btop.desktop entry, a manpage written in Markdown, a themes directory and an Img directory for imagery. Those surfaces are not interchangeable. A snap, a release binary, and a package built from the branch can each be at a different version, and the desktop entry and the man page only do anything for you if your distribution packaged them. If you need to name the exact revision you validated, record it yourself, because the version string alone will not tell you which of those four you were looking at.

Editorial conclusion

Use it when you want one monitor across Linux, macOS and the BSDs and do not need GPU telemetry, or when you are willing to compile it to get GPU numbers. Do not install the release binary expecting per-GPU boxes, because they are not in that build, and do not statically link your own build, because GPU support depends on loading dynamic GPU libraries. Before you contribute, read the AI disclosure rule, which now applies to any generated code rather than a majority of it, and check which branch a build recipe names before you follow it.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes