Tachyon GPU monitor

Tachyon

The lightest real-time GPU monitor for NVIDIA cards, and the one that explains itself:

what is holding your work back, when VRAM will run out, why the PC went down, and how this

render compares with the last one. It only reads: it never touches clocks, fans, power

limits or the network.

By Formray.

Tachyon 1.0 is the first release. The 5.0 to 5.1.1 builds were previews before 1.0; see the changelog.

Features

New in 1.3:

• Tachy v5, a redrawn Hex. A cleaner hexagon with calm, shape-driven eyes and ambient motion around him: sparkles while rendering, heat waves when hot, a sweat drop when VRAM is full, z's when sleepy. Two built-in skins, Velvet (default) and Aurora flat, switched in Settings > General > *Companion skin* and applied at once.
• Two new states. *VRAM full* (92 % or more for about 3 s, off below 85 %) and *alarm* (a new crash report, a GPU driver reset or the red temperature; at least 10 s, after a crash until you click Hex or the next render starts). Priority: alarm > hot > VRAM full > render > sleepy > idle.
• Preview flags. tachyon.exe --hex-demo cycles through the six states; tachyon.exe --hex-state=alarm holds one. Nothing is recorded in preview mode.

New in 1.2:

• 100 ms fast sampling. A small thread reads the clocks, power against the limit, temperature, load, the clock-limit reasons and the PCIe link ten times a second into a second fixed-size ring next to the flight recorder (15 minutes, about 352 KB). After a crash, diagnose_crash shows the last 30 s at that resolution (last_seconds): a +200 W step within 100 ms, power brake or a hardware slowdown just before the stop are named as hints. Measured on an RTX 5080: no extra CPU above the run-to-run noise (the whole Tachyon stays at 1-1.7% of one core, as 1.1.0), one extra thread.
• PCIe link history. The link against the best the GPU and slot can do. Dropping to Gen1/Gen2 at idle is normal and only counted; a narrower link (x8 in an x16 slot) or a lower generation under load is logged as *degraded*, with the recovery. In the status, the bottleneck evidence and the get_pcie_link tool.
• VRAM per process over time. Every 5 s, from the same per-process counters Task Manager uses (NVML has no per-process VRAM under Windows' WDDM), logged when it changes. get_process_vram answers "who held VRAM between 18:00 and 18:30?" with peak, average and a timeline per process.
• Render job markers. A render script calls tachyon mark start --job "shot 12" and tachyon mark end --job "shot 12"; Tachyon reports the job: duration, average and peak GPU load, peak VRAM, average and peak power, energy (and cost), time clock-limited by power or heat, the PCIe link and the processes holding the most VRAM. In the status and the get_job_reports tool.

New in 1.1:

• Pre-render check: "will this job fit?". When a render job starts, Tachyon looks for earlier runs of the same job (then the same project, then a similar name) at the same resolution, read from the job name, the log path or the log's first 16 KB (4k, 2160p, uhd, 3840x2160, ffmpeg scale=). From the VRAM those runs' own processes needed and what other apps hold right now it says *should fit*, *tight* or *likely out of memory* ("At 4K this job needs ~15.2 GB of VRAM; 14.0 GB is free. Likely out of memory, or very slow."), names idle apps whose memory closing would free, and gives the expected duration. With one loose match or runs that differ a lot it gives no verdict rather than a false alarm. Hex says it once per job when it is confident; the panel shows it under the bottleneck; agents get the preflight tool.
• Crash diagnosis. The crash report now ranks the probable causes with a rough percentage: unstable RAM or EXPO/XMP, GPU core/memory overclock, power or PSU, overheating, a driver timeout (TDR) or an application bug. Rules weigh the bug check code (0x1A, 0x124, 0x116...), NVIDIA driver resets (nvlddmkm 153/13/14), GPU timeout reports (LiveKernelEvent 141/117), WHEA errors, Kernel-Power 41, application crashes, the temperatures, power and load before the stop, the GPU's clock offsets and power limit (saved before the crash) and the RAM speed against its rated speed (SMBIOS). Each cause lists its evidence and one piece of advice; it says *likely* or *possibly*, never certain, and changes no settings. In the report view (*Evidence ›*), in Hex's announcement and in the diagnose_crash tool, which can also diagnose an older crash straight from the Event Log and the flight recorder (around: "2026-10-22" or "2026-10-26 18:09", matched against the moment the PC actually stopped). A power-off while the GPU was idle points to a power cut or a manual power-off rather than the GPU's power draw; RAM running below its standard speed, a clock that jumped at the restart and a slow BIOS start are reported as signs that the BIOS settings were reset. Times Windows wrote before the stop that are older than the flight recorder's last sample (EventLog 6008's "last sign of life", the last log entry) are marked as stale, never given as the moment the PC stopped.

New in 1.0, all worked out on the PC from the readings Tachyon already takes (no extra polling, no cloud, no AI model):

• Flight recorder. The last 15 minutes of readings (load, temperature, power, VRAM, clocks, limiters, top processes) go into two small fixed-size files on disk, about 170 KB each. If Windows restarts or Tachyon is killed, the next start shows a crash report: what happened in the last minutes, the peaks, which process held the most VRAM and the matching Windows events (Kernel-Power, bug checks, WHEA hardware errors, NVIDIA driver resets), in plain words. Hex mentions it once, with *Open report*. *Export flight recorder* in the menu writes CSV and JSON.
• "Why is it slow?" A one-sentence answer to what is holding the work back: the GPU itself, the power cap, heat, the video decoder or encoder, one CPU thread, all CPU cores, VRAM or PCIe, with *sure*, *likely* or *possibly* and the readings behind it. It only changes after the new answer has held for a few seconds, so it does not flicker. In the panel, and in Hex's bubble.
• VRAM forecast. A robust trend of video memory (median slope, so one spike does not count) for the card and each process. It warns only when the trend is steady and the card would be full within 15 minutes ("At this rate VRAM will be full in ~6 min (python.exe is growing by 25 MB/s)"), and points out background apps holding VRAM without using the GPU.
• Job history. Each finished render job, or each GPU-busy stretch of a minute or more, is saved as one line: duration, average and peak load, fps, energy in Wh (from the driver's energy counter), peak VRAM and temperature, time spent throttled and the main limit. The next run of the same job is compared with it ("14% slower than last time; GPU spent 6 min power-throttled"). Set price_per_kwh to see what each job cost.
• For AI agents: `tachyon.exe mcp`. A local MCP server with twelve read-only tools (nine before 1.2), so an assistant like Claude Desktop or Cursor can ask what the GPU is doing and why. Off until you turn it on in Settings (or set agent_api = true); it runs on pipes, not the network.
• Settings page. Right-click the island, Hex or the panel and pick *Settings…*, or use the gear in the panel. Mode, refresh rate, project folders, alert thresholds, the flight recorder, the job history, the energy price and the agent API, with a *Copy MCP config* button. Changes are saved as you make them and apply at once; only the flight recorder needs a restart.

Carried over from the previews:

• One portable exe, under 3 MB. No installer, no runtime, no OpenGL, no GPU context of its own: it does not wake the GPU it is measuring.
• Aurora glass: frosted glass with a soft live colour field. Its hue follows the GPU load (blue to violet) and an ember warms up with the temperature; it only moves when the values change. Truly borderless: per-pixel alpha, rounded shape, soft shadow, and clicks on the empty area around it go through to the desktop.
• Three modes, switched from the right-click menu (and remembered):
• Island: a capsule at the top of the screen, always on top, with load, temperature, VRAM and power. While a render runs the glow fills it like a progress bar, with the job, the frames and the ETA.
• Companion (Hex): a small hexagon with eyes that sits on your desktop, in two skins (Velvet or Aurora flat). It breathes and blinks now and then, draws a glowing progress line round its edge with sparkles during a render, gets warm (with heat waves) when the card is hot, sweats when VRAM is full, raises the alarm after a crash, a driver reset or at the red temperature, and falls asleep after ten quiet minutes. Click it for a speech bubble: render progress, load and temperature, the biggest VRAM user, four key numbers and *Open panel*.
• Panel: the full window, sized to its content.
• Everything NVML knows, live: load, temperature, VRAM, power against the limit, core and memory clock, fan, NVENC/NVDEC, PCIe RX/TX, 60 s load and heat traces, and the clock limiters in plain words (power cap, thermal, power brake, …).
• GPU process attribution: each process with a category chip (Game, Creative app, Script/Python, Browser, AI/agent, System, Other), the program that launched it (python.exe via ComfyUI.exe) and its own SM / ENC / DEC % and VRAM. Idle desktop processes are hidden until you click *show all*. The categories are rules in a toml file.
• Optional render tracking: point it at folders of render logs (ffmpeg, tqdm, progress.json, batch and chunk logs) for progress, fps and ETA.
• Light by design: one thread; no constant animation timer (Hex arms one one-shot timer per frame it actually draws); nothing drawn while hidden or behind a fullscreen app; the working set is trimmed after start-up. The 1.0 analysis runs on the samples already taken, and the recorder writes every 5 s and flushes every 30 s.

What is here

| src/gui/companion.rs | Hex and its bubble: windows, hit testing, frame scheduling, dragg