Microsoft VP builds a free tool that shows what's eating your VRAM

What's going on

If you run AI models on your own machine, you know the problem: your graphics card's video memory (VRAM) is tight, and it decides which models will fit at all. But Windows Task Manager only gives you rough numbers, like "15 GB in use". It won't tell you how much of that is the AI model, how much is its cache and how much is your web browser.

gputaskman aims to fill exactly that gap. It was built by Scott Hanselman, Vice President and Member of Technical Staff at Microsoft and GitHub and one of the best-known faces in the Microsoft developer community. He announced the project on X on November 3, 2026:

"There's a lot going on in my GPU. I'm building a GPU task manager to see where my VRAM is going. Pull requests welcome."

The tool is free and open source on GitHub under the permissive MIT license. In the project description, Hanselman calls it "an htop for what's inside your GPU, not just how full it is". htop is a popular Linux program that shows running processes and their resource usage in the terminal.

What Windows Task Manager can't do

According to Betanews, the Performance tab in Windows Task Manager shows your graphics card's overall load, utilization and temperature. You can add per-process memory columns under Details, but the setting is hidden and doesn't tell you much about individual programs. NVIDIA card owners can also add the "NVIDIA GPU Activity" indicator to the taskbar, but it only shows which processes are currently using the GPU. Until now, digging deeper usually meant PowerShell commands.

What gputaskman shows you

The program runs in the terminal, the text window of the command line, and has several views:

• Device view: Charts for VRAM usage, temperature, GPU and memory activity, power draw and PCIe traffic, meaning the data moving back and forth between the graphics card and the rest of the PC. You also get clock speeds, video encode and decode activity and history graphs. On machines with multiple GPUs, each card gets its own group of charts.
• Process view: Every process using the GPU gets its own row showing the VRAM it has allocated locally. It also shows system RAM the GPU can access, marked as "Spill", meaning data that has overflowed from VRAM into regular RAM. An estimate of paged-out memory appears as "Paged". The view also shows the load on the 3D, compute (general-purpose calculations, such as AI), copy and video engines. The tool detects which runtime a process is using: CUDA, HIP, Vulkan, Direct3D, ggml or ONNX Runtime.
• Model inspector: This view is for anyone running language models locally. It lists loaded models by type and shows quantization (shrinking a model by storing its numbers at lower precision), architecture, layer count, weight size and the estimated size of the KV cache. That's the cache where a language model keeps track of the conversation so far, and it grows as the text gets longer.

Model detection works with llama.cpp, LM Studio, Ollama and stable-diffusion.cpp. According to Betanews, the tool backs up every detection with evidence, such as an API response, a loaded file or a command-line argument. In one screenshot in the GitHub repository, for example, gputaskman detects that the llama-server.exe process is running the Qwen3-0.6B model and breaks down its weights, KV cache and parameter count.

For scripting, there's a --json snapshot and a recording mode that logs readings in JSON Lines format. Values the tool can't get at show up as "N/A", or as null in JSON. According to the project notes, null never stands for a measured zero. The project explicitly labels its attributions and per-model memory breakdowns as estimates.

A week of rapid development

The project is moving fast. Versions 0.1.0, 0.2.0 and 0.3.0 all landed on November 3. Version 0.2.0 added Linux and WSL (the Linux subsystem in Windows), and 0.3.0 added AMD graphics cards on Windows. Versions 0.3.1 through 0.3.3 followed on November 7, bringing support for Apple Silicon Macs, a Nix flake for NixOS and AMD cards on native Linux. Version 0.3.4 arrived on November 9 with an optional compact view.

AMD support came from an outside contributor named kdrapel, and Hanselman merged the change the same day. According to Betanews, a Copilot agent, an AI helper from GitHub, fixed a temperature bug under Hanselman's account. The code had divided the value by 1,000 even though AMD's interface already reports degrees Celsius, so the reading was about 1,000 times too low. The bot says it tested the fix on a Radeon 860M.

First tests and criticism

Tom's Hardware tried the portable Windows version 0.3.0 on a laptop with an RTX 4060. At first, no process was using the dedicated GPU. Data only showed up once the Unigine Valley graphics benchmark was running, with live charts for load, VRAM and temperature front and center. Betanews says the Windows version ran mostly stable in an early test, though the temperature reading sometimes got stuck on one value. The project description itself calls gputaskman early, experimental software.

Readers in the Tom's Hardware comments also had criticism. One user reported that the tool caused noticeable CPU load through a Windows system process, which went away when it was closed. Another disagreed, saying the Python process itself uses less than one percent of a core. Another commenter complained that the total usage alone doesn't help much, because a lot of VRAM is just used as cache. A third accused the article of ignoring that similar tools have been around for ages.

What you need to try it

gputaskman runs on 64-bit Windows 10 and 11 with an NVIDIA or AMD graphics card, on Linux, in WSL and on Apple Silicon Macs. By default it runs on Python. For Windows, there's a portable version that starts without installation. Mac users need to clone the repository, since there's no portable version for macOS yet. Which readings are available varies by platform. You'll find the repository on GitHub under Hanselman's account.

The bigger picture

If you work with Ollama, LM Studio or llama.cpp, gputaskman gives you an easy, free way to see why a model no longer fits in VRAM, for the first time. It shows whether the KV cache grows with long contexts, whether your browser and the Desktop Window Manager are taking a cut of memory, or whether data is already spilling over into slower system RAM. Incidentally, on Hanselman's own system with an RTX 4080 Super, the biggest VRAM user was the Windows Desktop Window Manager.

The idea itself isn't new: tools like nvtop and nvidia-smi also show GPU processes. What's new is mainly the focus on AI models and the fact that it runs across platforms. Because it's still experimental, the per-model memory figures are explicitly estimates. One more interesting detail: according to Tom's Hardware, Hanselman hinted in the comments that more advanced GPU monitoring could eventually come to Windows itself. That hasn't been confirmed.