Measure the electrical energy (joules) a shell command consumes while running.

Methodology: samples CPU package power at 100 ms during the run, subtracts a separately measured idle baseline, repeats the run (default 3x) and reports mean/stdev/CV. Use absolute paths; wrap any path containing spaces in double quotes. Expect ~(idle_seconds + repeats x runtime) of wall time.

Measure two commands and report which consumes less energy and by what margin.

Only meaningful if both commands are functionally equivalent (same outputs for the same inputs) — verify that separately before drawing conclusions.

Report whether energy measurement is available on this host and which backend would be used. Call this before measure_energy to know if the energy axis works here — on a machine with no reachable CPU power sensor it returns energy_available: false, and you should rely on the token axis (or say energy can't be measured) rather than estimate.

Run two commands and compare stdout + exit code. The gate before any energy/token comparison.

With no stdin_inputs it's a single-input smoke test. Pass stdin_inputs (a list of strings fed to each program's stdin) to run an input BATTERY — all inputs must match. Stronger evidence still comes from running the project's own test suite.

Measure how many LLM tokens a program consumes when it runs (works on any machine — no special hardware). The program must read base_url_env for its LLM endpoint (most SDKs do); we point that at a non-blocking counting proxy forwarding to upstream, run the program, and report real provider usage (input/output/total tokens, call count). For a non-Anthropic target, pass its provider's base-url env var and upstream (e.g. OPENAI_BASE_URL, https://api.openai.com). If llm_calls is 0, the target didn't route through base_url_env.

Measure two programs' token use and report which uses fewer, by how much. Only meaningful if both produce acceptable equivalent results — verify that separately (fewer tokens with worse answers is not a win).