GPU Taskman: Per-Process VRAM Tool, v0.3.3 [2026] - shattered.io

Windows and Linux users often see a vague total for GPU memory usage, but cannot tell which process is responsible. A new terminal tool called gputaskman attempts to answer that question by exposing per-process VRAM, GPU activity and LLM model and KV-cache details.

The project is described as a GPU task manager for Windows, Linux and WSL that reports memory splits and engine activity. It positions itself as an 'htop for what’s inside your GPU, not just how full it is,' focusing on users who already know their card is full and want to know why.

The tool distinguishes between processes that merely hold memory and those actively using the GPU. It also aims to separate model weights from KV caches, which grow with context length and can crowd out other workloads on a single card.

Windows Report covered the release and tied it to a Microsoft engineer, while the project metadata lists Scott Hanselman as the author. No official Microsoft announcement or product page has appeared in the verified record, so the affiliation is reported rather than confirmed.

The project’s README frames the problem in a single question: if Task Manager says 15 GB is used, what is actually using it? It lists suspects such as model weights, KV cache, browsers and the desktop compositor, highlighting how a single aggregate number hides the split between workloads.

This gap is especially painful for local AI workloads, which share a single card with games, video calls and dozens of browser tabs. As memory prices climb, wasting a gigabyte of VRAM on an unidentified process costs real money, making precise visibility valuable.

The repository documents a terminal user interface, not a windowed application. Its capabilities fall into two groups: per-process GPU memory and engine activity, and loaded runtimes, model files and LLM buffer breakdowns. Each group answers a different kind of diagnostic question.

Per-process VRAM and engine activity

Per-process VRAM answers the plain question of who holds how much memory, while engine activity adds a second axis: which process is actually busy on the card right now versus which one merely holds memory while idle. This distinction helps separate hoarders from workers.

The second group is the more unusual part, as it surfaces loaded runtimes, model files and LLM buffer breakdowns. For a local-model user, the KV cache is the number that surprises people, as it grows with context length and can crowd out everything else on a card that looked comfortable at load time.

The repository does not publish figures for how accurate these breakdowns are across runtimes, so the feature set should be treated as documented intent until independent testers weigh in. The tool aims to make conflicts obvious, such as when two inference servers assume they own the whole card.

Developers already have partial answers: Windows Task Manager shows GPU usage and memory, vendor command-line tools list processes and their memory, and terminal monitors like htop cover CPU and RAM very well. The project claims none of these go inside the memory to say what it holds for AI workloads.

Platform and GPU support

Support is where the repository text and project metadata need careful reading. The metadata lists three platform families: Windows, Linux/POSIX and macOS, with specific vendor support for each. Windows supports NVIDIA and AMD cards, while NVIDIA is supported on Linux and WSL.

AMD is supported on native Linux, and macOS support targets Apple Silicon. The record names NVIDIA, AMD and Apple Silicon, and says nothing about Intel graphics, so owners of Intel Arc cards or integrated GPUs should not assume coverage. Likewise, AMD support is not listed for WSL.

The cross-platform scope is ambitious for a project at this stage, as reading per-process GPU data differs sharply between Windows, Linux driver stacks and Apple’s tooling. Each platform needs its own collection path, and whether all of them work equally well remains to be seen.

The project metadata in pyproject.toml lists version 0.3.3 and requires Python 3.11 or newer. The license is MIT, which lets individuals and companies use, modify and redistribute the code with minimal conditions. GitHub’s release listing shows two titled releases, v0.2.0 and v0.3.0, suggesting ongoing work between tagged releases.

Why local LLM users need this most

The phrase 'LLM model/KV-cache insights' in the project description tells you who the tool is for. People running local models face a memory budget problem that gamers rarely hit, where weights take a fixed slab and the cache grows with every token of context.

Add a browser and a compositor, and a card that fits a model on paper can start swapping into system RAM. A per-process breakdown helps with this quieter failure mode, making it easier to diagnose when a model server reserves memory at load time and then grows a cache that crowds out other workloads.

The tool could justify a look for anyone juggling several runtimes, as it makes conflicts obvious in seconds. It sits squarely in hardware coverage, since the story is about how people manage scarce graphics memory in an era where memory prices are climbing.

The release listing and metadata show the intent, and user reports will show the reality. The project is available under the MIT license, with no distribution channel, bundle or fee mentioned in the cited records, so this article makes no claim about cost beyond the license.