Read an energy receipt

Every Lux program can produce a receipt — a structured statement of what it spent. Reading one well means knowing which tier each figure came from.

The receipt

Execution APIs return energy alongside output:

{
  "total_uj":   23,
  "compute_uj": 18,
  "io_uj":      5,
  "wall_us":    120
}

At the web-framework level the report breaks down by unit of work — render, route, fetch, state update — plus an operation count.

Where the numbers come from

Energy is reported from the most accurate source the host provides, and every figure carries its source and uncertainty:

Where sensors are absent or too coarse, a calibrated per-platform cost model prices operations instead — microjoules per MFLOP, per byte of I/O, per discrete operation — tuned per target (STM32N6, Jetson Orin/Thor, OpenMV AE3, workstation).

The resolution floor

Hardware counters bottom out around a millijoule (RAPL). Two consequences, both by design:

1. Aggregate operations are measured. A render cycle or a route is large enough to read meaningfully.
2. Sub-millijoule operations are modeled, not measured. A single hash is below the noise floor; its figure comes from the calibrated table, validated by batched measurement (run K operations, subtract the idle baseline, take the median).

A meter, not a benchmark

The receipt is your program’s own statement of account on your machine — like a household electricity meter. It is not a comparison against someone else’s framework, and a figure without its source attached would not be honest. The playground’s energy figure, for example, is always labeled as a static estimate from the operation-mix model.

Deeper: whitepaper §5 — Energy Observability.