Workstation control for builds and heat

A Linux controller that keeps a workstation usable while compilation, ordinary desktop work, and overheating compete for resources.

What the workstation needs

Temperature, fan state, resource pressure, and the active workload are read together before a freeze or noise spike becomes the only signal.

Which mode takes priority

Quiet idle, fast compilation, a desktop-safe build, and thermal protection apply different CPU, cooling, and resource limits.

When normal work returns

Thermal protection releases only after fresh safe readings; a controller failure remains visible instead of being hidden by an automatic reset.

Why one workstation policy is not enough

AI engineering creates bursts of heavy Rust compilation, browser automation, media processing, and long local model sessions. A workstation cannot be tuned once and forgotten.

The conditions that compete

Conflicting priorities: The same machine needs fast builds during compile work and quiet, cooler behavior when idle.
The problem appears too late: If the user notices freezing or fan spikes first, the controller is not exposing the machine's state soon enough.
Protection must recover: Thermal protection must be strict, but a temporary heat event should not permanently disable normal control.
Resource contention: Compiler jobs, foreground desktop work, and background AI runs need explicit resource limits instead of manual process policing.

How the controller decides

MACHINE STATE
  temperature | fan state | resource pressure | active workload
          ↓
POLICY
  quiet idle | fast compile | limited build | heat protection
          ↓
CONTROL
  CPU policy | fan PWM | CPU and memory limits
          ↓
STATUS
  current mode | reason | sensor readings | recovery state

What remains visible

fast compile mode

Build Load

reserved headroom

Desktop Use

recovers after cooling

Heat Protection

named and explained

Current Mode

systemd watchdog

Supervision

regression suite

Verification

Why build modes are separate

Problem

Fast Rust builds and usable desktop responsiveness compete for CPU, memory, IO, and thermal headroom.

Solution

Separate an unrestricted compile mode from a limited build mode. The limited mode reserves CPU and memory for the desktop; the fast mode uses available cooling before slowing the compiler.

Why not that option

Manual priority and kill commands react after the problem, are hard to repeat, and disappear before the next AI run.

How thermal protection releases

Problem

A critical temperature event must protect hardware but should recover after fresh cooldown evidence.

Solution

Hold maximum cooling during critical heat, then return to normal only after sensors remain safe. Failures that make control unreliable stay blocked for inspection.

Implementation

Core

Rust 2024, serde, toml, tracing

Linux Control

sysfs, cgroups, CPU governor, EPP

Reliability

systemd notify, watchdog, explicit fail-safe modes

Verification

fake sysfs tests, fan policy and run-mode regressions

What stays observable

Machine state without guesswork

The current mode, reason, temperatures, and limits are readable, so AI does not need the user to describe fan noise or freezes.

Automatic recovery after cooling

Temporary heat protection clears only after safe readings; failures that undermine control remain blocked instead of being hidden.

Hardware and workload move together

CPU policy, cooling, resource limits, and system supervision respond to the same named machine state.

Faster builds without losing the desktop

Compilation can use the machine aggressively while foreground work keeps enough resources to remain usable.