Scott Hanselman's free terminal tool shows which program is eating your GPU memory
He announced it November 3 and asked for pull requests. By November 7 outside contributors had added Linux, macOS and AMD support, and the README still calls it early, experimental software with some figures that are estimates.
The number that says your graphics card is full tells you nothing about who filled it. Scott Hanselman put that gap in one line on X: “There’s a lot going on in my GPU. I’m making a GPU Taskman to get insights to where my GPU memory is going. PRs welcome.”
The README’s tagline is the pitch: “An htop for what’s inside your GPU, not just how full it is.” It’s a terminal interface that connects per-process GPU memory and engine activity with loaded runtimes, model files and buffer breakdowns for local language models. It asks the question people actually have, too: “And why is so much GPU memory in system RAM?”
@shanselman's post on X
The method matters more than the screen. The README says it “combines evidence rather than reading arbitrary GPU memory.” On Windows, counters supply per-process memory and engine data. NVIDIA’s NVML or AMD’s ADL/SMI supply device metrics. Loaded DLLs, mapped files and command lines hint at which runtime and model a process is using. The README is careful about what that proves: “This does not dump VRAM or enumerate a game’s textures,” and a runtime DLL or filename alone “does not prove which allocation contains which object.”
Model files get the most careful treatment. The app reads GGUF headers (the metadata in local-model files) and tensor offsets to estimate weight and KV-cache sizes, and compatible llama.cpp load logs can add the buffer sizes the program itself reported. The README draws the line in one sentence: “Device and process counters are measurements; classifications and GGUF-derived breakdowns are estimates.” Windows labels get the same honesty. “Spill” means GPU-accessible system RAM, not proven overflow, and “Paged” is an estimate, not a measured pagefile figure. That’s a lot more candor than the average task manager, which just shows a number with a straight face.
The README’s own label for all of it is “Early, experimental software.”
The releases page shows how fast the help arrived. On November 3, v0.1.0 went out, then v0.2.0 with Linux and WSL support from samehkhamis, then v0.3.0 with AMD support from kdrapel. By November 7, v0.3.1 had macOS on Apple Silicon (samehkhamis again), AMD on native Linux through amdgpu sysfs and DRM fdinfo from Pinta365, a Nix flake, and gputaskman diff to compare two JSON snapshots. Version 0.3.4, dated November 9, added an optional slim monitoring view and a fix that recovers GPUs after Windows adapter changes.
What it covers today, per the README: Windows 10 and 11 (64-bit) with NVIDIA or AMD GPUs; Linux and WSL with NVIDIA, plus AMD and Intel on native Linux; macOS on Apple Silicon from a clone. CPU-only and NPU-only workloads are out of scope.
A project that picks up Linux, macOS and AMD support in four days from other people’s pull requests will probably keep growing in the directions its contributors own hardware for, which makes the README’s platform list the thing to watch, more than the feature list. The measured-versus-estimated split looks like the part worth copying: any GPU tool will eventually have to say which of its numbers came from a driver and which from a guess about a file.
Pull requests welcome.