Learn

A letter scale for software energy efficiency

Every fridge in Europe carries a letter from A to G for the energy it uses. Every app on your Mac carries nothing at all. Here is a scale that would fix that, the method behind it, and WheelClick measured against it — feature by feature, including where it does badly.

Nobody has drawn the line

This is not for lack of trying. Four separate bodies work on software energy, and every one of them stops one step short of a class.

Blue Angel DE-UZ 215

A government eco-label for software products, since 2020, revised in 2024 to cover mobile and server software. Consumption must be measured and disclosed — but its level does not affect whether the label is awarded.

Software Carbon Intensity, ISO/IEC 21031:2024

A carbon rate per functional unit: operational plus embodied emissions, divided by whatever the software scales on. The specification defines no grades, classes or thresholds. Lower is better; compare against your own baseline.

SPECpower_ssj2008

Server throughput per watt across eleven load levels, including active idle as a level of its own. Servers only, and it publishes a results table rather than classes.

The EU energy label

The A–G classes everyone recognizes, mandatory on phones and tablets since June 2025. Hardware only. Software is out of scope entirely.

So the numerator exists, and the letters exist, and no one has joined them for the software on a desktop. That is all this page does: draw the boundaries, and say honestly how they were drawn.

The scale

Seven classes, A to G, one factor of ten each. A class means one plain thing: ten times the cost of the class above it.

The anchor is the clock in your menu bar. macOS draws it continuously, nobody has ever called it expensive, and on the reference machine it averages 0.4833 mW — class B. Every other boundary is a power of ten away from it.

Why not A+++

Because the plus signs were never a design. The EU pinned its first boundaries to the market of 1994, appliances got better, everything drifted into the top class, and instead of moving the lines they bolted on A+, then A++, then A+++. By the end, almost everything in the shop was A+++ and the label had stopped telling two products apart. The 2021 rescale threw the plus signs out: A+++ became B or C, A++ became D or E, A+ became F or G — and class A was deliberately left empty, as room for products nobody had built yet.

The instinct behind the plus signs is sound, though. Software really does span a wider range than refrigerators — six orders of magnitude between a suspended event tap and a background animation. Powers of ten answer that without extra letters, and an anchor that is a piece of physics rather than a snapshot of the market does not drift into needing them later.

What goes in the denominator

A class means nothing until you say per what — and the honest way to do it is to fix the denominator before you know your own result, or the scale is just a costume for a conclusion you already wanted.

The headline class is average power over a stated duty cycle: what the software costs in a day, divided by the day. That follows the three standards above rather than departing from them. The EU rates phones on battery endurance per cycle, not on watts under load. SPECpower weighs eleven load levels into one number. SCI demands a functional unit describing how the software scales. Instantaneous power is a slice, not a unit.

So the duty cycle is published next to the class, always. For an input-layer utility on a laptop, the assumption used here is four hours of hand-on-trackpad time per 24. Rate something else, state your own.

Two axes underneath the letter

One letter on top, two beneath it, and both get published: the rest class, what it costs while doing nothing, and the load class, what it costs while working. For anything that runs all day, rest dominates the daily total — so an app that is cheap in use and expensive at rest earns a bad first letter that no amount of hot-path optimization can hide. This is the same split SPECpower makes by treating active idle as a load level of its own.

The method

Black box, start to finish. The rated software is measured from outside its own process: no source code, no instrumentation, no cooperation from the thing being rated. proc_pid_rusage reads any process id; powermetrics reads the whole machine.

1. Release build, on stated hardware, with the date recorded.
2. Rest: sample in buckets, throw away any bucket touched by real user input, take the quietest clean bucket as the floor.
3. Load: drive the software's own hot path at a stated rate and measure processor time per event.
4. Convert processor time to power through a constant measured on that machine — here, 250.1 mJ per CPU-second.
5. Publish the machine, the date, the build and the duty cycle with every class. A class without them is not a result.

What the method cannot see

Stated rather than left out, because a scale that hides its blind spots is worth less than no scale:

• Work done on someone else's ledger. Per-process energy covers the rated process only. When it wakes a system daemon, that cost is charged to the daemon — so it has to be chased down separately, with a whole-machine sampler. WheelClick checks its Accessibility permission every five seconds; the resulting work inside tccd comes to roughly 0.0025 mW, and that is an upper bound, since tccd serves every app on the machine and none of it is provably ours. Counted in, the resting figure below goes from 0.023 mW to 0.026 — the same class, with room to spare.
• Rates that were assumed instead of measured. A cost per event is worthless without the event rate, and where the rate is unknown, so is the class.
• Anything not measured is not rated. Reading an app's source and inferring a class from it is out of scope. A letter arrived at that way is an accusation wearing the clothes of a measurement.

WheelClick, rated

Apple M5, Release build, measured 2026-07-19. WheelClick is a background utility that gives a Mac the middle click its hardware never had, so it runs all day and its energy profile is a feature rather than an afterthought.

Two rows were measured in milliwatts directly rather than per event, because per event is not their shape. Autoscroll is a self-driven timer, so a live scrolling session is what there is to measure. And the Magic Mouse cannot be driven by a script at all — synthetic events carry no finger data — so its figure comes from a separate session with a real hand on the shell, sampled across both processes, with the same rub repeated with the feature switched off as a control.

Three things this table would mislead you about

The column does not add up. Each figure was measured with that feature enabled alone, and almost none of what it measures is the feature. It is the touch tap the feature needs — one tap, shared by all of them. Turning on all five trackpad gestures costs about 2 mW, not 10. That number is the price of admission, paid by whichever feature you switch on first and already included for every one after it.

Nothing lands in class B, and the gap is real. The app has two states: the touch tap is suspended, or it is not. Anything needing it costs about 2 mW; anything avoiding it costs hundredths of that. There is nothing in between to be found.

A factor of ten per class hides real differences. The Magic Mouse path costs 0.9 mW against the trackpad gestures' 2.1 — two and a half times cheaper, same class. That is why the number is printed beside the letter here, and inside the app's own menu: the letter compares categories, the number compares within one.

Why some features are cheap and others cannot be

The split in that table is not a coincidence of two numbers. Every feature that costs hundredths of a milliwatt is riding something the system already does. Every feature that costs around two is asking for a stream of raw finger positions that nothing was built to provide. The gap between them is not effort — it is how close to the hardware the work is allowed to happen.

There is no standard name for that. Computer architecture calls the information lost on the way down the semantic gap; chip designers talk about offloading work to fixed-function silicon. Neither names the ladder itself, so: call it silicon proximity — how close a feature runs to hardware that was built with it in mind.

1. 1 Pure hardware No software at all. The middle button on a three-button mouse is a wire: pressing it costs nothing, forever, because nothing is running.
2. 2 Purpose-built silicon A chip designed for this one job, with software only configuring it. An always-on processor listening for a wake word; a neural engine; a display pipeline.
3. 3 Device firmware The work never leaves the peripheral. The trackpad turning capacitance into finger positions is doing this while your Mac sleeps on it.
4. 4 Kernel and drivers Inside the operating system, below anything a user installs.
5. 5 A system service The OS does it once, for everyone. The trackpad driver's own gestures live here — which is why they cost you nothing extra.
6. 6 An app on system APIs Every utility that adds behavior the system did not ship. A client of the machine rather than a part of it.
7. 7 An app on a runtime on the OS Interpreted languages, embedded browsers. Every layer has to be crossed on the way down, and crossed again on the way back.

WheelClick sits between five and six, and the half rung is worth being exact about. It is an ordinary app, but it does not call an API and wait to be told what happened: it is spliced into the system's own event delivery, at the head of the stream, ahead of every other tap and ahead of the applications themselves — and while a system zoom gesture is running, at the lowest point user space can reach at all. Its decision about a click is made on behalf of the whole machine, which is the seat a system service occupies, and it is why macOS gates the position behind an Accessibility grant instead of handing it out.

That half rung buys authority, not energy. Standing earlier in the pipeline changes what WheelClick sees first, not what it costs: it is still a user process being woken for every event, and the 87 microseconds are the same at either stage. Position in the queue and closeness to silicon are different axes, and only the second one is what this ladder is about — so the rating does not improve, and it would be a small dishonesty to let it.

This ladder is ordinal, not measured. Nothing on this page was rated with it, and no class above was derived from it — it is here because it explains the measurements, not because it produced them.

It also explains the hole in the middle of our own table. fn+click reads a modifier flag on a click the system was going to deliver anyway, so it is nearly free. The three-finger gestures need the raw touch stream, which means work in our process for every finger movement while your hand rests on the trackpad. Same app, same care, two orders of magnitude apart — because one of them borrows a rung and the other has to climb.

WheelClick exists because of a missing rung

On a three-button mouse, the middle click is rung one. It is a switch. It costs nothing, and no rating scale has anything to say about it.

A trackpad has no third button, and macOS ships no gesture for one — so a middle click on a trackpad cannot be built below the rung WheelClick already stands on. It has to be assembled, in an ordinary app, out of fingers reported one movement at a time. The class C under load is the price of hardware that never anticipated this. It is a ceiling nobody here can raise: not by writing better code, not by optimizing the hot path, which is already down to 87 microseconds of processor time per event.

Which makes the honest version of the sales pitch a strange one to write down. The most energy-efficient middle click in the world is a mouse that has one. If you own that mouse, it wins, and nothing on this page competes with it. WheelClick is the best available answer for the hardware that does not — and being measured about it is the least it owes you.

What this page is not

It is not a ranking of WheelClick's competitors. They are not measured here, and they will not be. A vendor grading its rivals on a scale of its own design is not evidence, whatever the numbers say — which is exactly why the EU does not let manufacturers print their own classes.

So the claim on offer is narrower than “the most efficient app in its category”, and harder to wave away: WheelClick's cost is measured, published per feature, and checkable. The scale is here, the method is here, and the harness that produced every figure is public — welded to this app's own source, so it is something to read rather than to run on yours, but it means no number here has to be taken on trust.