Microsoft VP Scott Hanselman has released gputaskman, a free, open-source terminal tool that shows exactly what is eating your GPU memory — per process, and down to the model weights and KV cache of any locally loaded LLM. Task Manager will tell you that 15 GB of VRAM is used. gputaskman answers the next question: used by what — the browser, the compositor, or the Qwen model you left running in Ollama? It is Hanselman's personal project, not a Microsoft product, it is MIT-licensed, and the current version is v0.4.0, released 11 November 2026.
What gputaskman is
The README pitches it in one line: "An htop for what's inside your GPU, not just how full it is." If you have ever run a local AI model and watched your VRAM fill up, you know the frustration: Windows Task Manager shows a big number and no explanation. gputaskman is a terminal UI that connects per-process GPU memory and engine activity with the loaded runtimes, model files and LLM buffer breakdowns behind them.
It was built in the open, and fast: Hanselman announced it on X on 3 November 2026, saying he was building it "to get insights to where my GPU memory is going", and invited pull requests. The first three versions — v0.1.0, v0.2.0 and v0.3.0 — were all tagged the same day; Neowin first reported it on 6 November, and it has since reached 2,586 stars and 122 forks (13 November 2026), with v0.3.5 on 10 November and v0.4.0 on 11 November.
The screenshot Asad shared tells the story. It shows the tool on an NVIDIA GeForce RTX 4080 SUPER with 15.99 GB of VRAM, 5.01 GB in use: the compositor at 2.18 GB, llama-server.exe holding a Qwen3-0.6B model at Q8_0 quantization, the browser at 977 MB, and the rest in small slices. Below, the model inspector breaks the LLM into weights, KV cache and compute buffers, with the model file named. That is the difference between a number and an answer.
Who made it — and what it is not
Scott Hanselman is a Vice President and Member of Technical Staff at Microsoft and GitHub. But gputaskman is his personal project, not a Microsoft product, and Microsoft does not support it. The README is explicit that it is early, experimental software built by Hanselman and community contributors — pull requests from outside Microsoft include Intel GPU support on Linux and a Huawei Ascend NPU backend.
That matters: support comes from the GitHub repository — issues and pull requests, not a Microsoft help desk — and it explains the tool's shape, a terminal utility built by a developer for his own machine. It follows the same pattern as Hanselman's PeekDesktop utility from earlier in 2026, which reveals the desktop when you click empty wallpaper, macOS-style — also MIT-licensed, also a personal project. The code is MIT-licensed, so anyone can use, copy, modify and redistribute it, including commercially, with only the licence notice kept, and every release is published at github.com/shanselman/gputaskman.
What it shows
Four areas work together: the device view, the process view, the model inspector, and scriptable output.
| View | What it shows | Why it matters |
|---|---|---|
| Device view | VRAM usage, GPU and memory activity, PCIe traffic, temperature, power, video-engine clock, and history charts (load, clock, VRAM, memory, temperature, power, encoder, decoder) | The card's health at a glance — and whether the load is compute, video, or memory-bound |
| Process view | Per-process local VRAM, GPU-accessible system RAM ("Spill"), estimated non-resident commit ("Paged"), engine activity (3D, compute, copy, video), detected runtime (CUDA, HIP, Vulkan, Direct3D, ggml, ONNX Runtime) | Names the process behind every gigabyte |
| Model inspector | For each loaded model: kind (LLM, decision, embedding, speech, diffusion), identification method, architecture, quantization, layer count, weight size, estimated KV-cache cost, buffer sizes from load logs | Splits a model's VRAM into weights vs KV cache vs compute buffers |
| System RAM and CPU | A panel plus RAM and CPU% columns, as the OS reports them — machine memory and load, never GPU memory | Shows whether the bottleneck is the GPU or the rest of the machine (added in v0.3.5) |
The device view is the one you will watch most: eight history charts (GPU load, SM clock, VRAM, memory activity, temperature, power, encoder, decoder) with a single-metric focus on the c key. A wide terminal, roughly 140 columns, makes the full table readable.
The process view is where the tool earns its name. Each row is a process with its local VRAM, Spill (GPU-accessible system RAM) and Paged (estimated non-resident commit) columns, plus engine activity split into 3D, compute, copy and video. Press s to cycle the sort — by VRAM, GPU%, shared memory, paged, name, RAM or CPU% — and a to switch between top processes and all of them. Select a row and the inspector opens below with everything the tool knows about that process, including what is measured, what is inferred and what is unavailable. Press ? for the counters' limits, m to toggle slim monitoring, p to pause, and q to quit. Multi-GPU stacks a header per GPU, though two discrete GPUs and multi-GPU on Windows are not yet validated.
Everything is also available without the UI: --once prints one text snapshot, --json prints one JSON snapshot from the same collector, diff compares two snapshots, and record captures a session. Readings the tool cannot obtain show as N/A in the UI and null in JSON — a missing reading is never silently reported as zero.
How it finds your LLMs
This is the feature that sets gputaskman apart from every other GPU monitor — and also where its limits live. It does not dump VRAM. Instead it combines evidence: Windows' graphics kernel supplies per-process memory and engine counters, NVML or AMD's ADL/SMI supplies device metrics, process DLLs suggest the runtime, and mapped files or command-line arguments identify candidate models. GGUF metadata and tensor offsets then let it estimate weights and KV-cache costs, while runtime logs and local server APIs add allocated buffer sizes and live state.
The runtimes it recognises, from the README's support table:
- llama.cpp / llama-server — GGUF discovery, CLI settings, buffer logs,
/props+/v1/modelsstate. Exercised live. - Ollama — bundled runners, mapped GGUF blobs named from Ollama manifests (
qwen3:14b, not a hash),/api/ps, compatibleserver.log. Also exercised live. - LM Studio — mapped files named from its models folder,
/api/v1/models(fallback/api/v0/models). Fixture-tested, not yet end to end. - vLLM — recognised launch/worker signatures; model IDs from its own listener or a verified parent, labelled API-reported. Live hardware not yet validated.
- stable-diffusion.cpp — diffusion, text-encoder and VAE files from launch arguments; no LLM memory breakdown.
- Hugging Face cache —
models--org--repopaths are shown asorg/repo, so a cached model is recognisable at a glance.
Runtime detection covers CUDA, HIP, Vulkan, Direct3D, ggml and ONNX Runtime. The README's worked example is an RTX 4080 SUPER running Docker Model Runner's llama-server over Vulkan with gemma-3-270m — the same card as in Asad's screenshot, where the tool instead found a local llama-server.exe running Qwen3-0.6B at Q8_0. In another spot check, a llama.cpp ROCm server running Qwen3-4B-Instruct-2507 at Q4_K_M with -ngl 99 -c 8192 held 3.95 GB of VRAM — 2.49 GB of weights plus 1.21 GB of f16 KV cache plus compute buffers — and an Ollama qwen3:0.6b runner was detected and named from Ollama's store.
Two terms in that breakdown decide how much VRAM a model needs. Quantization is how precisely the weights are stored: Q8_0 means 8-bit weights, Q4_K_M means roughly 4-bit. A smaller quantization means a smaller model and less VRAM — that is why a 4-bit 4B model can fit where an 8-bit one cannot — at the cost of some accuracy. KV cache is the memory the model uses to remember the conversation: it grows with context length, so a long chat with a big context window can eat more VRAM in KV cache than the weights themselves. That is the split gputaskman shows you. Newly loaded models may take about 15 seconds to appear, because discovery is throttled.
Install, step by step
The portable download is the route most Windows users will want: no Python, no uv, no CUDA Toolkit and no model download is required — just a supported GPU with a current WDDM driver.
Option 1 — portable Windows download (no Python needed). Download the windows-x64.zip from the GitHub Releases page — windows-arm64.zip for Snapdragon — extract the entire ZIP, keeping the _internal folder beside gputaskman.exe, open Windows Terminal or PowerShell in the extracted folder, and run it. No admin rights and no install step are needed.
.\gputaskman.exe .\gputaskman.exe --once .\gputaskman.exe --json
Option 2 — install from PyPI (Windows, Linux/WSL and macOS, Python 3.11+). The package has been on PyPI since v0.3.2; uv tool install or pipx keeps it in an isolated environment, the shorter gtm command is also available, and upgrades work with uv tool upgrade gputaskman or pipx upgrade gputaskman.
uv tool install gputaskman gputaskman
Or with pipx:
pipx install gputaskman gputaskman
Option 3 — run from a clone. This is also the only route on macOS for now, since there is no portable Mac download yet: clone the repository and run it with uv run gputaskman. On Apple Silicon, macOS shares one pool of memory between CPU and GPU, so there is no VRAM to split and no spill or commit counters — the tool shows GPU memory as a share of physical RAM, with spill, paged, clocks, power and temperature unavailable.
git clone https://github.com/shanselman/gputaskman.git cd gputaskman uv run gputaskman
Linux and WSL. On native Linux, NVIDIA works everywhere, and AMD and Intel work too — Intel support (i915/xe, including GT clock and throttle status) arrived in v0.3.5. WSL is supported, with Windows host counters matched to Linux processes; enable [interop] in /etc/wsl.conf and run wsl --shutdown if the tool reports host counters are off. Processes owned by other users need sudo, and Docker and other WSL distributions are not visible from the one you are running in. Sample every two seconds for a calmer display:
gputaskman -i 2 gputaskman record -o session.jsonl --duration 300
Safety note: Windows builds are currently unsigned and there is no installer — download only from the official GitHub Releases page and verify the .zip.sha256 companion file. An unsigned executable from anywhere else is not this tool.
What it can't do — read this before you trust it
The README is unusually honest about its limits, and this section matters most. gputaskman is early, experimental software, and its model and memory breakdowns are estimates, not measurements. They assume llama.cpp-style placement, and partial offload, KV quantization and multiple models in one process can change the result. Treat the numbers as a guide to where your memory went, not as a laboratory measurement.
max(Total Committed − Local Usage − Non Local Usage, 0)), not an eviction trace or proof that Windows moved those bytes out of VRAM.Two more traps are easy to fall into. First, DWM is not everything. Windows' per-process "Dedicated Usage" includes resources shared between processes, so the same surface can appear against its application, csrss.exe and dwm.exe at once — adding those rows double-counts memory. gputaskman prefers "Local Usage" and "Non Local Usage" instead; in one live sample, DWM's older counter read about 15.3 GiB while Local Usage was about 1.4 GiB. Second, a DLL is not proof of work. A process can load a CUDA or PyTorch DLL and never run a kernel, and a model file can be mapped into a process without ever being loaded onto the GPU. The tool labels what it can prove and what it only infers — read those labels before quoting a number to anyone.
gputaskman vs Task Manager
Task Manager is the baseline, and gputaskman is built for the question it leaves unanswered. Its Performance tab shows total GPU load, utilization and temperature, and its Details tab shows per-process GPU memory. What it does not show is the composition: how much is model weights, how much is KV cache, how much is the browser, and how much is the compositor double-counting shared surfaces.
| Question | Task Manager | gputaskman |
|---|---|---|
| How full is the GPU? | Yes — total usage and utilization | Yes — plus history charts |
| Which process uses how much? | Yes — per-process GPU memory in Details | Yes — local VRAM, Spill and Paged per process, with engine splits |
| Is a model loaded, and which one? | No | Yes — model name, architecture, quantization, weights and KV-cache estimate |
| Weights vs KV cache? | No | Yes — estimated breakdown from GGUF metadata and server APIs |
| System RAM and CPU too? | Yes — separate tabs | Yes — in the same terminal |
| Scriptable / JSON output? | No | Yes — --once, --json, diff and record |
| Works on Linux / WSL / Mac? | Windows only | Yes — Linux, WSL and Apple Silicon macOS |
There is also a gap in the other direction. nvidia-smi, the command-line tool NVIDIA ships, is the usual alternative on Linux — but on GeForce cards under Windows' WDDM driver model, Windows manages GPU memory and NVML may report per-process memory as N/A, and under WSL nvidia-smi lists no processes at all. That is the hole gputaskman fills. Use Task Manager for a quick glance, nvidia-smi where it works, and gputaskman when you need to know what is inside the number.
Who it's for — and who should skip it
Run it if you run local AI. If you use Ollama, LM Studio or llama.cpp and have ever wondered why a 16 GB card is full with a 4 GB model loaded, this is the tool that answers it — usually KV cache, a second model you forgot about, or the browser holding a gigabyte of textures. It is also the tool for anyone debugging VRAM pressure before a game or a render: it shows you in seconds whether the game or the model server is holding the memory.
Run it if you manage GPU machines, too. Snapshot before and after a job, diff the two, and you have a record of what the job actually held — a cheap way to answer "who filled the card?" on a shared workstation or a small local inference box.
Skip it — for now — if you need guarantees. If you are writing a benchmark, a paper or a bug report that depends on exact VRAM accounting, the estimates are not good enough yet, and the README says so. Skip it too if you only want a prettier Task Manager and never run local models: the device view is nice, but the model inspector is the reason the tool exists, and without a local LLM you will not use half of it. And if you cannot run unsigned executables — a locked-down work laptop, for example — wait for signed builds.
Frequently asked questions
Is gputaskman a Microsoft product?
No. It is Scott Hanselman's personal project — he is a Vice President and Member of Technical Staff at Microsoft and GitHub, but the tool is not a Microsoft product and Microsoft does not support it. It is MIT-licensed open source, developed in the open on GitHub with community contributors.
Is gputaskman free?
Yes. It is free and open source under the MIT licence, with no paid version, no account and no telemetry. Download it from the GitHub Releases page, or install it from PyPI with uv tool install gputaskman or pipx install gputaskman.
Which GPUs and platforms does it support?
64-bit Windows 10/11 (NVIDIA, AMD), Linux (NVIDIA, AMD, Intel), WSL, and Apple Silicon macOS (from a clone — no portable Mac build yet). You need a supported GPU with a current WDDM driver on Windows. Metrics differ by platform: macOS has no VRAM split, no spill or paged counters, and no engine split.
Can it really tell me which LLM is loaded?
Yes, for the runtimes it supports — llama.cpp, Ollama, LM Studio, vLLM and stable-diffusion.cpp — by combining mapped files, command-line arguments, GGUF metadata, load logs and local server APIs. It names the model, its quantization and architecture, and estimates the weights and KV-cache sizes. The breakdowns are estimates, not measurements: a mapped file does not prove the model is in VRAM, and partial offload or KV quantization can change the result.
Why does Task Manager show a different VRAM number?
Because the two tools count differently. Task Manager's "Dedicated Usage" includes resources shared between processes, so the same surface can be counted against the application, csrss.exe and dwm.exe at once. gputaskman prefers "Local Usage" and "Non Local Usage", which avoids most double-counting — in one live sample, about 15.3 GiB versus about 1.4 GiB for the compositor. The adapter total is the reference either way.
Is it safe to run? Does it send data anywhere?
It sends no telemetry and reads only local process metadata, model headers, load logs and local server responses. It does not dump VRAM or model weights. Two cautions: Windows builds are currently unsigned, so download only from the official GitHub page and verify the .zip.sha256 file — and the inspector and JSON output can contain file paths, command-line flags, model names and local ports, so redact captures before posting them publicly.
Related reading: uv: the Python package manager that replaces pip, venv, pyenv and pip-tools · Colibri: run 744B AI models on a potato PC · TurboFieldfare: run Gemma 4 26B on an 8GB Mac — complete install guide · Asad Webs free tools
Sources
- GitHub — shanselman/gputaskman
- WindowsForum — Scott Hanselman's gputaskman tracks per-process VRAM and LLM usage on Windows, Linux and WSL
- MezoSoft — gputaskman GPU VRAM monitoring tool
- BetaNews — GPU memory monitoring tool
- Free-Codecs — What's using your GPU? A Microsoft engineer's free tool shows you, plus the Task Manager trick
Be the first to share a useful question or thought.