gputaskman: Scott Hanselman GPU Task Manager for LLM VRAM and KV Cache

The gputaskman repository by Scott Hanselman surged past 2,400 GitHub stars in early November 2026 as a cross-platform GPU task manager tuned for developers who run local large language models. The README pitches per-process VRAM, GPU activity, and LLM model and KV-cache insights on Windows AMD and NVIDIA, with Linux and WSL paths — a niche nvidia-smi and Task Manager gap when you are juggling Ollama, llama.cpp, and IDE experiments on one machine.

TL;DR

Why local LLM builders want a GPU task manager

Running open weights locally means failures are silent OOMs, split VRAM between a browser and a server, or zombie processes after a crashed notebook. Command-line tools show totals; Windows Task Manager shows GPU percent without tying it to which model context grew.

Microsoft's DXGI documentation describes a per-process video memory budget that can fluctuate as background processes wake and sleep, which is why per-process views matter.

explainx.ai covers the inference stack — llama.cpp releases, tensor runtimes, Botpsy on-device agents — but operators still need OS-level attribution. gputaskman targets that debugging layer, similar in spirit to how htop helped CPU-bound services before cloud-native observability existed.

KV cache slots illustrating how gputaskman helps debug local LLM GPU memory per process

What the README claims

Candidate feed summary and repository description align on:

• Per-process VRAM and GPU activity views.
• LLM model and KV cache oriented insights — wording implies awareness of transformer serving footprints, not only graphics APIs.
• Cross-platform coverage: native Windows for AMD/NVIDIA, plus Linux and WSL for developers who train on Windows laptops but compile in WSL.

We did not run the binary in this news cycle. Treat performance numbers as unverified until you benchmark on your SKU. Star velocity suggests HN and .NET community interest, not a corporate support contract.

GPU compute stack illustrating desktop VRAM attribution for local LLM workloads

How it fits beside other tools

If you ship agent harnesses that spawn local models — see ScoutCode fallbacks — give testers a shared GPU hygiene doc: one chart from gputaskman plus harness logs cuts "works on my machine" fights.

Install and safety notes

1. Clone from the official shanselman/gputaskman path; trending forks may lag.
2. Read LICENSE and SECURITY policy if your employer blocks unofficial GPU drivers.
3. On WSL, confirm GPU paravirtualization matches your Windows build — mismatches still cause empty process lists.
4. Do not run untrusted prebuilt binaries from third-party threads; build from source when possible.

Limitations to expect

Open GPU utilities on Windows historically break across driver branches and Hybrid graphics laptops. AMD paths especially vary by Adrenalin versus ROCm-on-Windows experiments. Plan for issue tracker reality: fast star growth often outpaces edge-case QA.

For production Kubernetes GPU nodes, stay with DCGM and cloud vendor monitors; gputaskman is a developer laptop tool in the explainx.ai read.

Typical debugging workflow

1. Start local server (Ollama, llama.cpp, vLLM).
2. Launch gputaskman alongside Task Manager baseline.
3. Reproduce spike — note process name and VRAM staircase when context grows.
4. Kill orphan python.exe or node.exe holders after crashed notebooks.
5. Compare against expected KV footprint for context length from model card.

Windows versus Linux paths

README promises both. Linux users may still prefer nvidia-smi dmon for scripting; gputaskman's value is GUI integrators and LLM-labeled fields if the author delivers them.

WSL2 users should confirm whether metrics reflect Windows host GPU or Linux guest — misconfiguration produces empty charts that look like tool bugs.

AMD Radeon angle

AMD adoption in local LLM communities rose with ROCm and Vulkan backends. A task manager that surfaces per-process VRAM on Adrenalin drivers helps Windows users who do not live in terminals — star growth may partly reflect AMD desktop inference curiosity.

Security note

GPU monitors are local-only but still sensitive: process names reveal project codenames. Do not screenshot gputaskman windows into public bug reports without redaction.

Roadmap signals from trending repos

Repos hitting ~2.5k stars in a week often receive feature PRs for CUDA version pinning and LLM server detection. Watch releases before baking into CI golden images.

Integration with agent harnesses

Coding agents that spawn multiple model processes — Herdr terminal runtime, ScoutCode — benefit from one pane showing which subprocess holds the GPU. Add gputaskman to internal runbooks beside nvidia-smi.

Hanselman ecosystem context

Scott Hanselman long promoted developer ergonomics on Windows — terminal upgrades, Git visualizations, and now GPU visibility for the local AI wave. gputaskman fits that lineage: meet practitioners on desktop OS first, polish for servers later. Star velocity may reflect trust in author as much as feature depth on day nine of the repo.

When not to use it

• Remote cloud training — use cloud vendor dashboards.
• Apple Silicon Mac — outside README's stated OS/GPU matrix unless ports appear.
• Compliance audits — not a log retention system.

Command-line alternatives table

Run gputaskman beside nvidia-smi until you trust its readings.

Packaging and distribution watch

Early repos often ship manual build only. Watch for winget, Chocolatey, or signed MSIX releases before standardizing on help desks — security teams block unsigned GPU utilities.

Corporate IT perspective

Help desks see "GPU at 100%" tickets when agents loop. A task manager that names Ollama versus Teams reduces mean-time-to-diagnosis — worth a pilot even if stars are hype.

Open source sustainability

Trending repos need maintainer time. If gputaskman stalls, fork or contribute AMD telemetry patches — the community that stars fast also complains fast.

Classroom and workshop use

Bootcamps teaching local LLM labs can standardize on gputaskman plus a written GPU budget per student (for example eight gigabytes VRAM cap). Instructors spot runaway contexts faster than walking the room asking who launched a second Ollama.

Future metrics to request from maintainers

If the project matures, ask for per-process token throughput, KV cache bytes, and CUDA MPS awareness — fields power users want but README has not promised yet.

Comparison to cloud notebook GPUs

When you rent A100s for training but debug locally, gputaskman does not replace cloud monitoring. Use it on the laptop that orchestrates SSH sessions to catch forgotten local inference eating RAM before you wonder why VS Code freezes.

Contributors considering PRs should prioritize stable process names on Windows 11 24H2 and documented support matrix in the README before adding niche features — adoption at this star velocity will crash into “works on my machine” GitHub issues otherwise.

Multi-GPU workstations

Creators running two consumer cards for speculative decoding should verify whether the tool attributes memory per device or sums misleading totals. Until the README documents multi-GPU, treat readings as single-adapter first.

Quantization workflows

When switching between Q4 and Q8 llama.cpp builds, VRAM footprints jump. Capture before and after screenshots in bug reports so maintainers see context length and quant together.

Model server naming

Ollama, LM Studio, and custom vLLM ports often spawn identical process names. Rename Windows shortcuts or use per-project WSL distros so gputaskman rows map to repos.

Idle GPU tax

Background Windows Copilot or Game Bar overlays occasionally reserve VRAM. If gputaskman shows mystery usage with no training job running, check other vendor AI shells before blaming your checkpoint.

Driver upgrade weeks

Major NVIDIA driver releases break monitoring utilities first. Pin a known-good driver branch for workshop weeks when curriculum depends on this tool.

File GitHub issues with OS build, driver version, GPU SKU, and repro steps when numbers look wrong — early trending repos improve fastest with structured feedback.

Treat star count as interest, not maturity: wait for a 0.1.0 tag before deploying to non-technical teammates.

Pair with power-capped training schedules so laptop GPUs stay inside thermal limits during all-day agent hacking sessions.

When teaching quantization tradeoffs, snapshot gputaskman before and after loading a larger context window — students remember VRAM stairs better than abstract kilobyte estimates from slides alone.

Add the tool to on-call runbooks for local reproducer laptops when production bugs only reproduce with a specific quantized checkpoint.

Star the repo if it saves you a long debugging afternoon.

Related on explainx.ai

• TensorFold Zig local inference
• Botpsy on-device agent
• Gemini trains on chats debate
• ScoutCode harness fallbacks
• Herdr agent terminal runtime

Star counts and README feature lists are accurate as of November 12, 2026.