Tachyon v1.1.0

Two new answers, both worked out from what Tachyon already records. Read-only as before.

Pre-render check ("will this job fit?")

• When a render job starts, its peak VRAM and duration are predicted from earlier runs of the same job, the same project or a similar name, at the same resolution (from the job name, the log path or the log's first 16 KB: 4k, 2160p, uhd, 3840x2160, scale=W:H...).
• Verdict should fit, tight (over 95% of the card) or likely out of memory, against what other apps hold right now, with idle VRAM hogs named ("closing it would leave 15.2 GB free"). A past run that filled the card counts as a lower bound.
• Confidence from the kind of match, the number of runs and how much they agree; below 0.4 there is no verdict, and Hex only speaks up (once per job) at 0.65 or more. Re-checked every 30 s during the job's first 15 minutes.
• Job history lines now also keep the project, resolution, frame count, the job's own peak VRAM, the VRAM in use at the start and the card size (older lines still read).
• Panel line under the bottleneck, a Hex line and announcement, and the MCP tool preflight (name, project, resolution, frames; no arguments = the running job).

Crash diagnosis

• The crash report ranks the probable cause with a percentage: unstable RAM / EXPO, GPU overclock, power / PSU, overheating, driver timeout (TDR), application bug, each with its evidence and one piece of advice, and a confidence (likely, possibly or unclear). Never 100%; Tachyon changes no settings.
• New evidence: the Application log (LiveKernelEvent 141/117 GPU timeout reports, application crashes), bug check codes from Kernel-Power 41 and WER 1001, the GPU clock offsets and power limit vs default (read once a minute and saved next to the flight recorder, so the report knows the settings from before the crash), and the RAM's configured speed vs its standard (JEDEC) speed and the kit's rated EXPO/XMP speed, decoded from the SMBIOS part number (Corsair, G.Skill, Kingston Fury, Crucial / Ballistix, TeamGroup). Running at or below the kit's rating counts as an EXPO/XMP profile in use (a mild factor), only above it as beyond its rating; four DDR5 modules from two kits are flagged.
• In the report view (with Evidence ›), Hex's crash announcement, get_status (crash_report.probable_cause) and the new MCP tool diagnose_crash (it also works out older 1.0 reports; without a report, or with around: "2026-10-22", it diagnoses the latest unexpected restart in the Windows Event Log, with the RAM speed and clock offsets as they are now).

Fixes from a real power loss (26 Oct 2026: the PC went off at idle, Kernel-Power 41 code 0, no dump; the BIOS came back on its defaults)

• diagnose_crash with around (or without a crash report) now uses the flight recorder for the minutes before the stop: GPU load, power against the limit, temperatures, the processes on the GPU and whether the PC was idle (before_the_stop). It no longer says there are no readings when the recorder has them.
• A power-off with no blue screen while the GPU was idle and at low power now points to a whole-system power loss or a manual power-off (new cause, with advice on the socket, PSU switch and what was plugged in or pressed, e.g. the BIOS FlashBack port); GPU power delivery or the PSU keeps only a small share. At full load it still points to the PSU.
• around is matched against when the PC actually stopped (the recorder's last sample, Windows' last log entry and EventLog 6008's last sign of life), not the restart time, with tolerance_minutes (default 90); restart reports logged up to 3 h later are found. The answer gives the stop window (stopped), what matched and the other restarts nearby.
• Windows' own times from before the stop are not taken for the stop when the flight recorder ran later: EventLog 6008's "last sign of life" (written only now and then, so 17:31:14 on 26 Oct for a stop at 18:09:04) is marked stale in the events list and the report timeline, and last_log_entry gets a last_log_entry_note saying it is earlier than the recorder's last sample.
• The clock after the restart is checked against the recording: a restart logged an hour after the last sign of life, or a Windows clock correction afterwards (Kernel-General 1), is noted in clock_note.
• RAM running below its standard (JEDEC) speed, e.g. 3600 MT/s on 4800 modules, is flagged as BIOS likely reset to safe defaults (EXPO/XMP off), together with a clock that jumped and a slow BIOS start (Windows' "Last BIOS time") when known (diagnosis.hints, the report view and the text export).
• get_blackbox reads older data: since/until (local time or Unix ms) or session: "previous"/"current", plus a plain summary of the last minute, clock_limits in words and the sessions on disk.
• Process names: 1.0 recorder files wrote the third name over the record checksum, so it read back with garbage (CrossDeviceResume.ex\x03\xdc,m). Old files now read back only its 20 real bytes, on whole UTF-8 characters, and a name cut inside .exe gets its extension back (CrossDeviceResume.exe). New ring files (TACHYBB2, 256-byte records) keep names up to 44 bytes; 1.0 files are still read. The flight recorder now takes about 460 KB on disk.
• NVML clock limit 0x400 is named (reliability policy), with the other known reasons.

Build and tests

• 169 tests on Linux, 172 under wine (132 in 1.0.1): diagnosis rules incl. the real EXPO case, the prediction and its thresholds, resolution parsing (fuzzed), job hints from a projects tree, SMBIOS parsing, the new MCP tools, and a regression on the real 26 Oct recording (tests/samples/blackbox_2026-10-26_idle_power_loss.bin, the last 5 minutes; process names only, no paths).
• The fake NVML has an oc scenario; tests/wine.sh can run on its own prefix/display; tests/shots_v1_1.sh makes the 1.1 screenshots.

Tachyon v1.0.1

Hardening for public use: safer for everyone, easier for anyone. No new readings; everything from 1.0.0 works as before.

Easier to use

• First start: defaults with no personal paths, and the panel opens with a short hint on where to find Settings. In a folder you cannot write to, tachyon.toml goes to %LOCALAPPDATA%\Tachyon instead.
• Damaged settings: a tachyon.toml that cannot be read (syntax, wrong types, not UTF-8, over 1 MB) is kept as tachyon.toml.corrupt-<date>-<time>; Tachyon starts with the defaults and says so.
• No GPU readings: plain messages for no NVIDIA driver, an old driver and a driver reset (TDR). After a reset Tachyon reconnects every 2 s for a minute, then every 10 s, and keeps running.
• One instance: starting it again brings the running one to the front. TACHYON_CONFIG and TACHYON_DATA_DIR let a second copy run with its own settings and data.
• Settings: Start with Windows (a shortcut in the Startup folder; off by default, no registry), a GPU picker when there is more than one, Reset settings (two clicks, keeps the old file as .bak and the window positions), and where the data lives and how to remove Tachyon.
• Keyboard: Tab, Shift+Tab, Space, Enter, arrows, Ctrl+Tab and Esc in Settings, with a focus ring; Ctrl+, opens Settings.
• Monitors: windows left on a monitor that was unplugged come back to the nearest screen; the island and panel stop drawing while a fullscreen app is in front, as Hex already did.
• Crash log: if Tachyon itself panics it writes %LOCALAPPDATA%\Tachyon\logs\panic-<time>.txt, shows a short message and exits; the next start mentions it.

Safer

• The agent API's shared memory and the single-instance mutex allow only the current user (and SYSTEM), at medium integrity; tachyon mcp refuses a section created by another account.
• Run-time DLLs are loaded from System32 only.
• Size caps and damage tolerance for everything read from disk: render logs, the flight recorder and its session.json (which can no longer name a file outside the recorder folder), jobs.jsonl (one damaged line no longer hides the jobs after it), the crash report and the event log XML (a panic on some non-ASCII attributes is fixed). MCP: 1 MB per request line, 64 per batch, invalid UTF-8 answered with an error instead of stopping the server.
• Randomised and mutated input tests for the settings loader, render log scanner, job history, flight recorder, crash report and MCP server.
• SECURITY.md and a privacy section in the README.

Builds

• CI runs cargo deny and cargo audit; all actions pinned by commit SHA with Dependabot updates; job and step timeouts (the 1.0.0 release run hung on apt); Rust build cache.
• Releases carry a signed build-provenance attestation for tachyon.exe and the zip, next to SHA256SUMS.txt.
• winget and Scoop manifests in packaging/ (not submitted yet).
• Claude Desktop extension: each release also carries tachyon-<version>-windows-x64.mcpb (in SHA256SUMS.txt and the attestation); it asks for your tachyon.toml so it follows the same Agent API switch.
• MCP Registry entry (packaging/mcp/server.json, io.github.formray/tachyon) and a manual-only Publish to MCP Registry workflow; an agent skill in packaging/skill/tachyon-gpu/; README setup for Claude, Codex and Grok.

Tachyon v1.0.0

Tachyon 1.0 is the first release. It supersedes the 5.x preview builds: those numbers were development iterations, and versioning restarts here. Everything from the previews is in, plus four things that explain what the GPU is doing, worked out from the readings Tachyon already takes (no extra polling, nothing leaves the PC).

• Flight recorder and crash report: the last 15 minutes of readings in two fixed-size ring files (192-byte checksummed records, written every 5 s, flushed every 30 s). After an unexpected restart or a killed session, the next start builds a report: what happened just before, the peaks, the process holding the most VRAM, a per-minute timeline and the matching Windows events (Kernel-Power 41, bug checks, unexpected shutdowns, WHEA hardware errors, NVIDIA driver resets) in plain words. Hex announces a restart once with Open report. Export flight recorder writes CSV and JSON. Settings: blackbox, blackbox_minutes.
• "Why is it slow?": one sentence on what is holding the work back (GPU, power cap, heat, video decoder or encoder, one CPU thread, all cores, VRAM, PCIe), with sure, likely or possibly and the evidence. A new answer must hold for four evaluations before it replaces the old one. In the panel (Why? ›) and Hex's bubble (Why is it slow? ›).
• VRAM forecast: Theil-Sen trend over two minutes for the card and each process; a warning only when the trend is steady and the card would be full within 15 minutes; idle background apps holding VRAM.
• Job history: finished render jobs and GPU-busy sessions in %LOCALAPPDATA%\Tachyon\history\jobs.jsonl with duration, load, fps, energy (driver energy counter, or integrated power), peak VRAM and temperature, throttled time and main limit, compared with the previous run of the same job. History view in the panel. Optional price_per_kwh and currency.
• tachyon.exe mcp: a local MCP server (stdio, protocol 2025-06-18 and earlier) with seven read-only tools for AI agents. Off unless agent_api = true; the running app then publishes its status in shared memory every two ticks.
• Settings page: Settings… in the right-click menu (island, Hex, panel) or the gear in the panel. Five tabs: General (mode, Hex announcements, bubble close time, refresh rate), Projects (render folders with a folder picker), Alerts (temperature and VRAM thresholds, forecast horizon), Data (flight recorder, history, energy price and currency) and AI agents (agent API with its live state, Copy MCP config with the full exe path). Values are checked, saved as you change them and applied live; only the flight recorder needs a restart. Saves go through a temporary file and a rename, keep tachyon.toml.bak and preserve comments and unknown keys. New settings: hex_announce, bubble_close_secs, vram_forecast_minutes.
• VRAM used matches nvidia-smi: read with nvmlDeviceGetMemoryInfo_v2, which leaves out the memory the driver reserves (about 300 MiB on a 16 GB card); older drivers fall back to the first version.
• Job history energy: a job whose first reading was quiet now still uses the driver's energy counter instead of integrating power.
• New menu items: Crash report, Job history, Export flight recorder, Settings….
• Exe about 1.85 MB (was 1.4 MB).

Measured on Windows 11 with an RTX 5080: about 0.05 % of total CPU and 32 MB working set in Hex mode during a GPU render, 0.025 % and 25 MB idle; tachyon.exe mcp answers in under a millisecond with Tachyon running. Figures and method in the README.

Known limits: checked on one Windows 11 PC so far; the crash report after a real restart, its Windows events and the restart detection are tested with synthetic data only (wine does not answer event log queries). See the README.

Tachyon v5.1.1

• Fixed: on Windows a render log still held open by its writer could look stale to the scan; its last-write time is now read from the file itself, and the scan tests no longer depend on Windows keeping file times when copying (the failed v5.1.0 Windows CI run).