Apple Silicon can sustain more background compute than the battery can comfortably support. Lowbeer tracks per-process energy use, throttles background agent workloads on battery, and surfaces drain conditions before they become costly.
Lowbeer
Lowbeer is a macOS energy-monitoring tool for Apple Silicon in the GSV tools domain (not currently in the GSV registry). It addresses a specific operational gap: Apple Silicon machines can sustain more background compute than their batteries can comfortably support, and that becomes a real problem once background agent workloads -- long-running AI agent processes, not just user apps -- are part of the normal workload mix. The mechanism is per-process energy tracking: Lowbeer monitors how much power individual processes draw, not just aggregate system load, so drain can be attributed to the specific agent or task responsible rather than treated as an undifferentiated battery drop. Built on that visibility, it throttles background agent workloads specifically when the machine is running on battery, and it surfaces drain conditions as they develop rather than after the battery is already critical, so a user can intervene before an agent session becomes operationally expensive -- a dead laptop mid-task, an unexpected low-battery state while mobile. The design decision worth naming is the choice of granularity: process-level attribution rather than system-level averages, which is what makes targeted throttling of agent workloads (versus everything) possible. Lowbeer sits among a set of zklw-hosted repos -- alongside tools like tool-time and agent-rig -- that are visible in the workspace and in IdeaGUI tracking but sit outside the portfolio's seed/thesis-stage narrative, meaning it functions as a working operational utility rather than a research bet. Its natural connection point in the broader GSV portfolio is other infrastructure-tooling projects concerned with keeping agent operations safe and legible to run unattended, such as Mahrai's control-plane reconciliation work, since both are about making autonomous or semi-autonomous agent workloads observable and governable. Current status: it exists and functions for its stated monitoring/throttling purpose; the provided material does not describe further internal architecture, language, or packaging details beyond per-process tracking and battery-aware throttling.