Inspiration
AI coding agents can optimize for correctness, speed, and cost, but the energy impact of the code they produce is still mostly invisible. We built Wattch because “faster” does not always mean “less energy,” and an energy number is only useful when its source, measurement boundary, and uncertainty are clear. Our goal is to give agents trustworthy local evidence they can use while improving code.
What it does
Wattch is a trace-first measurement platform that gives coding agents a local power meter through MCP and a command-line interface. It discovers telemetry sources, captures workloads inside a coordinator-owned window, and preserves raw samples, timestamps, source descriptors, events, command provenance, stdout, stderr, and exit status in replayable artifacts.
A reusable Wattch skill guides an agent through a correctness-preserving loop: measure, change one thing, test, measure again, and report only what the evidence supports. Wattch can use deterministic synthetic sources for development, Linux RAPL, or Apple powermetrics behind a privileged daemon. It explicitly does not claim to measure provider-side model inference, private per-process energy, or whole-machine energy without the required evidence.
How we built it
We built Wattch as a Rust workspace with a strict daemon/client boundary. A versioned protocol carries compact raw samples over local Unix sockets. The deterministic test daemon makes protocol behavior reproducible, while the power daemon isolates privileged hardware access. The unprivileged wattch CLI handles source discovery, shell-free workload capture, inspection, and validation. A bounded MCP server exposes the same raw-evidence workflow to coding agents, and Python tools handle experiment scheduling and offline analysis.
We used Codex with GPT-5.6 Luna and Terra to test the system. Both models received the same optimization prompt and Wattch access. Each produced an implementation with and without the Wattch skill available. We froze all four candidates and ran 32 Williams-balanced, correctness-gated local trials.
Challenges we ran into
The hardest part was not collecting a number; it was knowing when that number supported a claim. We had to handle privileged hardware access, sampling gaps, counter semantics, post-exit telemetry, shared-system noise, calibration, and benchmark loopholes.
We prevented the code under test from choosing its own measurement window and hash-bound every trial to the prompt, candidate, plan, and raw artifacts. When the Apple meter failed our preregistered absolute-calibration gate, Wattch kept the absolute energy fields null instead of substituting timing or synthetic data. We redesigned the experiment around a sealed paired-differential uncertainty threshold.
Accomplishments that we're proud of
Both Luna and Terra successfully accessed Wattch through MCP and CLI. All four generated implementations passed exact correctness and mutation-scope checks. All 32 paired trials were retained with zero source-sequence gaps or required-source missingness, and 288 sealed artifact hashes were independently verified.
The experiment also caught a real regression. Luna's skill-conditioned implementation showed no meaningful local difference from its control, while Terra's skill-conditioned implementation consumed more local Apple CPU-domain energy because it left repeated work inside the hot loop. Wattch identified the code-level cause while refusing to generalize one submission into a claim about an entire model, skill, whole machine, or provider-side inference.
What we learned
Energy optimization needs the same discipline as correctness and performance engineering: explicit contracts, repeatable workloads, raw evidence, uncertainty, and narrow claims. We also learned that giving an agent an optimization skill does not automatically produce a better implementation. Measurement is what closes the loop.
A trustworthy energy tool must be willing to say “no meaningful difference” or “not eligible” instead of manufacturing a positive result. That honesty became one of Wattch's most important features.
What's next for Wattch
Next, we want to expand Wattch's Energy Tests and VS Code workflow, support more physical backends and platforms, and run larger studies across more prompts and repeated agent submissions. We also want to make Wattch easy to add to CI so teams can catch energy regressions alongside unit tests and performance benchmarks.
Our long-term goal is simple: whenever an agent changes code, it should be able to show not only that the code works, but what that change caused the system to do.
Log in or sign up for Devpost to join the conversation.