How we count watts per app and battery minutes

Updated 6 November 2026 · Who measures this.

In short

Two things here are measured, not guessed: how much power the whole Mac uses, and how much energy the chip spends. Everything else (who spent it, and what quitting would give back) is worked out from those two. This page says how the working-out goes, and where it stops.

It describes the version downloaded from this site. The App Store version runs in Apple's sandbox, which closes several of the instruments below: it has no once a second power reading and no "Screen backlight" line, it uses one fixed floor for every Mac instead of measuring yours, and it does not measure graphics, so a window in front is not credited to its app. Its own Measurements screen describes that version.

What is measured

Where the watts come from

Each second we read the whole Mac's power from its system management controller, on battery and plugged in alike. On battery it closely tracks what the battery reports, but the battery publishes its figure only about once a minute; plugged in, the adapter covers part or all of it. Separately we read the chip's energy counters: processor, graphics, Neural Engine and a few hardware blocks. The first says how much the machine uses; the second shows where it went, and for processor work, which app caused it. Where a Mac does not report that power, we fall back to the battery's own current and voltage, and then a number can sit still for a while and then jump.

The kernel counter that makes watts per app possible

Watts per app are possible on Apple silicon because the kernel measures each process's processor energy. It keeps an energy total for every process, so dividing by the time between two readings gives watts. Activity Monitor never shows that figure, and powermetrics gives no watts per process at all.

The counter is Apple silicon only. On an Intel Mac the same field compiles and returns zero, which is silence rather than an error, so the app checks that the counter exists before it reads anything, and treats a missing counter as a missing instrument rather than as an app that used nothing.

What the counter covers is processor energy. Graphics has a measured total and no per-app energy counter, so its split between apps comes from a GPU activity counter macOS keeps for each app. The graphics the macOS window server renders goes to the app whose window is in front. The power spent simply being awake (screen, memory, radios) is never charged to an app: it stays in "Screen and system".

How an app gets its watts

One watt on the chip is not one watt from the battery

The chip's counters measure the chip. The battery also pays for converting the power, and for memory and the rest of the board that work along with it, none of which have counters of their own. WattMate uses one rate on every Mac to turn each joule of processor work an app's counter shows into joules from the battery. It is a rounded compromise chosen from the app's own records, not a constant the battery obeys; switching a known processor load on and off gave mostly a lower rate on the Macs we tested. It stays as it is for now: changing it moves every app row at once, so it needs its own check on our test Macs first. Since 1.6 the app also learns a second number on your Mac: how the chip's own processor meter compares with the apps' counters. It puts the energy that only the chip's meters see, such as graphics, on the same scale as an app's processor work.

Why the apps don't add up to the whole

Each app is charged for the measured work that can be tied to it: its processor work at the rate above, plus the graphics tied to it. For the app in front, that graphics can include drawing for other windows on the screen (see the limits below). Everything else the machine uses is the block you see as "Screen and system": the screen, the idle chip, memory, storage, radios, and work no app can be named for. That block is not measured on its own. It is what is left of the machine's total once the apps are taken out, so the two always add up to the whole. If the apps' work would leave the machine less than its own floor, all their figures are scaled down together, and what they lose stays in "Screen and system". The floor is what this Mac uses with the screen on while nothing is working. It is measured on your Mac in quiet minutes on battery, separately for each screen brightness. Until there are such minutes, the floor is a default: the low end of the floor measured on a MacBook Pro 14″ with M3 Max.

What "Screen and system" is

"Screen and system" is everything that uses power with no app assigned to it. It holds three rows, four on a MacBook Pro with a mini-LED display. "Backlight and services" is the backlight, the idle chip, memory, storage and radios. "Graphics" is measured graphics and Neural Engine work that macOS does not tie to any one app. "Background work" is kernel work and processes that ended between two of our readings: real work, with no owner we are allowed to name. On a MacBook Pro with a mini-LED display (14 and 16-inch), whose controller reports the backlight, it is measured on its own and shown first as "Screen backlight", and the rest is called "Services and chips". Quitting an app removes its own row, and often part of these rows as well: the graphics the window server renders for the window in front is already in that app's row, but memory and the window server's own processor work are not.

Why an app's number moves

Every number is an average, and the caption on the screen names the span it covers. One window is not a speed: during a single uninterrupted video call, Chrome's share of the machine moved between 18% and 65% from window to window. Averaging is what makes the figure usable, and it also means the figure follows the app with a few minutes' delay.

What the Energy Impact number in Activity Monitor means

It is a dimensionless score, not a physical quantity: Apple describes it as "a relative measure of the current energy consumption of the app", where lower numbers are better, and never names a unit. You cannot compare two Macs by it, and you cannot turn it into hours of work. The best public explanation of the formula dates from 2015 and describes Intel processors this machine does not have.

We print watts. A watt is a joule per second: it adds up, it divides into the battery's capacity, and it becomes time. That is why an app here carries "12.5 W" rather than "40 points".

One objection worth answering up front: every menu bar monitor reads the same powermetrics numbers and only renders them differently. For the machine as a whole, that is true. Per app it is not: powermetrics gives no watts per process (its task list shows only an energy impact score), so we build that ourselves from the kernel's own counters, including the energy of children that have already exited. Hence the gap with any list that merely restates Activity Monitor.

Where the minutes come from

Where "+N minutes" comes from

Take what the machine uses now, subtract what the app's own work costs the battery, and the charge left lasts proportionally longer. That is the whole arithmetic. The app's cost comes from the energy counters of its processes, turned into battery watts the same way as its row in the list. One source of uncertainty is the app itself, whose power use swings from minute to minute, so the answer is a range, and we show its low end. The rate and the graphics split add uncertainty of their own that the range does not cover. An app with a busy window in front can give back more than that. The graphics the window server renders for it is already in the row and its minutes; the rest of what its window costs, such as memory and the window server's own processor work, sits outside every per-app counter, so the row and its minutes leave it out. We measure the machine again a couple of minutes after you actually quit something and print what really changed; if the load moved for other reasons in that time, we say the effect could not be isolated instead of claiming a win.

Why minutes take a while to appear

Minutes need the charge to be actually falling. Right after you unplug, and especially at 100%, the battery is still settling, and a window that catches that is not a measurement. Half the time the first number arrives within 3 minutes; sometimes it takes much longer, which is why we never promise a countdown. The app list is there from the first seconds; only the minutes wait. After the Mac wakes from sleep the wait starts over: numbers taken before the sleep are not about now.

Minutes do not add up

An app's minutes answer one question: what if I quit this one, now. They cannot be added up: the same watt is worth many more minutes on a full battery than near the end, because a full battery has more hours left to stretch, and quitting two apps is not the sum of quitting each. Where a total is needed we compute it for the whole group at once, and say so.

The hours left

The hours-left figure at the top is Apple's own estimate, taken as macOS reports it. Under "How long it lasts" we add how far that estimate usually misses: the range is the middle half of its error on 3 of our Macs.

Why not a number of our own? We tested that: we replayed our own estimates, such as how fast the charge fell over the last half hour, against how fast the battery really ran down on 5 Macs, with the pass rule written down first. None beat Apple's figure on at least 3 Macs for typical error, bias and big misses at once. Most of the miss on our estimates comes from what you do next, and no formula knows that. So the number stays Apple's and matches what macOS shows you.

What is ours is the ratio: "without this app the Mac uses 14 W instead of 20". If the two ever disagree, believe Apple about the hours and us about the difference.

Special cases

Coding agents

Claude Code, Codex CLI, Gemini CLI and other terminal agents get a row of their own among your apps. The row is the agent itself plus what it has running: a build it started counts for the agent while it lives. A compiler that starts and ends between two of our readings stays in the terminal's row, because by then only the terminal's total shows it.

Watching video

Most video decoding and encoding happens in a dedicated hardware block, not inside the app. The block has its own counter, so the energy is measured, but macOS does not say who asked for it, so it appears under "Graphics" and not under the player. Two consequences worth knowing: an app playing video looks cheaper in the list than it is, and quitting it can free a little more than its row promises. In absolute terms these blocks are small: during a call with background blur we measured the camera at 64 mW and the codec at 10 mW, while the Neural Engine doing the blur ran at about 0.5 W.

What we can measure in sleep

What each wake-up cost, we don't know: a wake-up lasts seconds, and the battery's charge reading does not move within the few seconds most of them take. We name how many times and for how long. Per-app watts don't exist in sleep at all.

Service names come from the macOS power log, which records who scheduled each wake-up; wake-ups from Wi-Fi, Bluetooth and the cable have no requester at all, because nobody scheduled them. Occasionally a scheduled wake-up finds no request either, and that row falls back to the cause class too.

A device charging from the Mac drops off the bus before it is unplugged, so the end of its window is taken from the port event in the same log. Its own charge level is there only when the device reports one: phones do, cases and mice do not.

Screen and brightness

On a MacBook Pro with a mini-LED display (14 and 16-inch), whose controller reports the backlight, the screen has its own line, "Screen backlight". On other Macs, such as MacBook Air or the 13-inch MacBook Pro, we can see that the screen costs several watts, but not precisely enough to print a number, so there it sits inside "Backlight and services". What a dimmer screen would give back is worked out from how the backlight's power follows the brightness on this Mac: measured on mini-LED, estimated from the whole machine on the others. Its minutes appear only after brightness changes on this Mac have been checked against what the battery actually did, and only while the two agree; until then the scale shows no minutes.

A phone charging from the Mac

When a phone charges from the Mac, we can see how much the port is allowed to give, not how much the phone takes. So the figure is a ceiling and is written as "up to".

On the cable

Runs and their history are recorded only while the Mac runs on battery, because only there does power use cost charge. Plugged in, the panel still shows what the machine uses right now, from the same once-a-second reading, but no run is logged. Each time on the cable leaves one short record instead: when it started and ended, the charge at both ends, the adapter's rating and the most it actually delivered, and how the charge rose. A Mac without a battery shows each app's share of the work instead.

Battery health comes from the battery controller

Cycles, remaining capacity, lifetime temperature and hours powered on come from the battery controller through macOS. They cover the whole life of this Mac, including the years before WattMate was installed; we read them and lay them out, with one rule of our own: while the pack stays the same, the health figure never rises above last month's. One chart on that page is ours: the month-by-month aging curve, which starts the day you install the app.

What we can't measure

Graphics

Graphics energy is measured as a total. Which app used it we work out from a per-app GPU counter that macOS names accumulated GPU time, because macOS publishes no per-app energy counter for graphics. Despite the name it measures neither energy nor how long the GPU was busy, and the same work can move it by different amounts, so the split between apps is approximate even though the total is not.

The window in front

Graphics drawn by the macOS window server goes to the app whose window is in front, as long as that app has a window on the screen and the screen is on. A video playing in a window behind it, a video call, or several windows side by side are drawn by the same window server, and their share goes to the app in front as well: we cannot see which window on the screen the work was for. The processor rate for apps with windows already includes a little of this drawing, so a small part of it is counted twice.

Neural Engine

Neural Engine energy is measured, but nothing in macOS says which app asked for it. It is never charged to an app: it stays inside "Graphics" under its own name.

Work between two readings

We ask the system about running processes every few seconds, more often while the Mac is working than when the work is close to nothing. Anything that starts and finishes in between is invisible to that question: a compiler, a helper, a script. The kernel keeps a per-app tally that gives most of it back, but the kernel's own work and daemons we are not allowed to read stay nameless. They show up as "Background work", and are never blamed on an app.

What is measured on your Mac

Some figures on this page were measured on the Macs we test on, and another Mac has a different chip and a different screen. So two of them the app measures on yours. How much your Mac uses when idle, it measures in quiet minutes and uses as soon as it has them; until then it uses the figure measured here. The ratio between the chip's own processor meter and the apps' counters, it measures whenever the chip reports it. The rate at which a joule of an app's processor work is counted against the battery is the same on every Mac; it is not measured again on yours.

How these numbers are checked

We checked WattMate's numbers ourselves on 6 Macs in our lab: the app against each Mac's own power sensor, and that sensor against a USB-C meter not made by Apple. Rules, thresholds and scripts were published before the first counted run. On all 6 Macs, WattMate listed our test programs first, and Apple's sensor stayed within about 0.3 W of the meter. In the preregistration's own words: "None of the checks confirms an app's watts as such, and none tests the battery minutes." The checks and their results.

What leaves the Mac

What stays on this Mac, and what leaves

All of it is computed here. App names, process names and the measurements themselves never leave the Mac; only the counts listed under "What exactly is sent" do. Detailed measurements are kept only for a short time; run summaries stay for good, because they are small. "Erase measurements" in General clears both. Anonymous statistics are on by default and can be switched off in Settings › General; the same switch stops crash reports from the next launch. Everything they carry is listed under "What exactly is sent": never a name of anything you run, and counts as ranges, apart from the few exact figures named there.

What exactly is sent

"The switch" is Settings › General › Send usage statistics inside the app.

Only if the switch above is on. Two kinds of statistics leave this Mac.

Once each, for the steps of getting started and buying: the first launch, how many minutes it took to reach its first numbers, which card met you first, whether you quit an app on our advice, whether you opened the statistics window, whether a licence activated, and whether this Mac suits the app at all. Every time: each lock tap, each time the price is shown and from which lock, each trip to the checkout and on which plan, and each failed activation. And each time a receipt appears after you quit an app on our advice: the minutes we promised, the minutes measured, whether the measurement held, and the chip family (for example M1 Pro). Once per installation, and again after each major macOS update (say, from 26 to 27): the shape of your chip's energy-counter names (for example "numbered" or "bare"), roughly how many counters there are and the chip family; the counter names and their readings stay on this Mac.

Once a week, a single summary: how many of the 7 days the Mac ran off the cable, what you opened and how often, how much of the power use went to sleep, how many banners were shown and tapped, whether they are allowed, which card came up most, whether you are on the trial or licensed, how many minutes the app gave back, and three facts about our estimate of the power floor, without a single watt: whether it came from fixed values or was learned on this Mac, how it compares with what the Mac itself shows (one of 4 verdicts), and how often it capped the numbers for apps that week (as a quarter). And how much WattMate itself used that week, as a range in milliwatts, by the same kernel counter it reads for other apps. Counts leave as ranges, not exact figures; exact are only the days off the cable, the minutes given back, the minutes to the first numbers and the two figures on a receipt.

The statistics library (TelemetryDeck) also attaches fields of its own to every signal: the app version, the Mac model (for example Mac15,10), the macOS version, time zone, language and region, appearance and screen size; the privacy page lists them all.

Never: the names of your apps or processes, window titles, file paths, the watts of any app you run, your name or the Mac's serial number. Statistics carry a random installation identifier the app makes for itself; a crash report also carries a device identifier the crash library (Sentry) computes, described on the privacy page.

The privacy page lists everything stored and everything that leaves.