What Low Power Mode costs on an M4 MacBook Air

The short version

Apple places Low Power Mode among the battery settings, which makes it sound like a little housekeeping at the edges. On this MacBook Air, it behaved more like a choice between two performance classes. Both a native cryptographic loop and a browser full of JavaScript applications lost roughly half their throughput.

That consistency matters. OpenSSL and Speedometer exercise very different software stacks; seeing the same broad result in both makes it unlikely that I had merely found an odd corner of one benchmark.

Where the browser feels it

Speedometer is where the trade-off stops being an abstract CPU number. It repeatedly drives small web applications built with common JavaScript frameworks—the sort of work hiding behind rich editors, dashboards, and complex forms. The official score fell from 53.4 to 28.9, a 45.9% drop.

Both modes began with a slower cold iteration. Looking only at the next four runs gives a cleaner picture of sustained use: a median of 58.33 in normal mode and 30.68 in Low Power Mode. In other words, once the browser was warm, Low Power Mode still left it with just over half the throughput.

That does not make every website 47% slower. A page waiting on DNS, a server response, or a download spends much of its time beyond the CPU's control. But when the work is already on the machine—rendering a large view, updating a client-side application, or responding inside an editor—there is less waiting to hide the difference. Those are the moments in which this power setting is most likely to feel like a slower computer, rather than merely a more economical one.

A native workload tells the same story

Speedometer is intentionally broad, so I wanted a smaller test with less browser machinery between the setting and the result. OpenSSL's speed command provides one: a sustained EVP SHA-256 loop in a single process.

I used its 8192-byte result, ran three five-second samples in each mode, and compared the medians. Normal mode reached 3.362 GB/s; Low Power Mode managed 1.591 GB/s. The normal setting was 2.113 times as fast—remarkably close to the gap in the warm browser runs.

openssl speed -seconds 5 -evp sha256

What the power saving buys

Losing half the performance only makes sense if the machine saves enough energy in return. To measure that side of the bargain, I removed Chrome and ran a second paired OpenSSL test while sampling the battery's current and voltage every five seconds.

Each mode sat idle for 90 seconds, warmed up under load for 60 seconds so the battery gauge could settle, then ran a measured three-minute SHA-256 phase. Before starting, the harness checked that macOS actually reported lowpowermode=0 for normal or lowpowermode=1 for Low Power Mode.

The loaded machine drew 8.78 W in normal mode and 2.91 W in Low Power Mode. That 66.8% reduction looks spectacular, but watts alone do not settle the question: the slower machine must run longer to complete the job. After correcting for the 2.108× difference in throughput, Low Power Mode still used only 69.9% as much energy per byte hashed. The net saving for equal work was 30.1%.

The tempting battery-life calculation

Divide a nominal 53.8 Wh battery by those average power readings and the result is about 6.1 hours in normal mode versus 18.5 hours in Low Power Mode, or 3.01 times the runtime. It is an irresistible figure—and an easy one to misuse. I did not run the battery from full to empty, and almost nobody spends an entire charge hashing data without pause.

How I tested it

The aim was not to produce a universal M4 score. I wanted a comparison in which the power setting changed and as little else as practical did. The machine, software versions, browser geometry, profiles, and benchmark duration were therefore fixed or recorded.

Machine

• MacBook Air Mac16,12, fanless
• Apple M4: four performance and six efficiency cores
• 16 GB unified memory
• macOS 26.6, build 25G72
• Battery power: 83% at the normal run, 82% at the Low Power run

Software

• Google Chrome 150.0.7871.188
• V8 15.0.245.21
• Official Speedometer 3.1
• OpenSSL 3.6.3
• Node.js 26.5.0 for Chrome DevTools automation

Power-mode boundary

I changed the setting through System Settings: Never for normal mode, then Only on Battery for Low Power Mode. The harness did not take that selection on faith; it checked the effective battery value before every run:

pmset -g custom
# normal: battery lowpowermode 0
# low:    battery lowpowermode 1

Nothing in the scripts uses a privileged pmset setter. Mode changes stay on Apple's supported UI path, and a mismatched setting stops the benchmark instead of silently contaminating a run. pmset -g therm reported no thermal or performance warning in either mode.

Browser isolation

Every browser run started with a fresh temporary Chrome profile and deleted it afterward. Extensions and sync were disabled. Both modes used the same executable and build, a requested 1200×900 window, a measured 1200×813 content viewport, and Speedometer's automatic five-iteration runner. I also captured Chrome's DevTools version response; that makes a stale or silently updated binary visible in the record.

Battery telemetry

For the power batch, the script read InstantAmperage, Voltage, AppleRawCurrentCapacity, and PowerTelemetryData from AppleSmartBattery with unprivileged ioreg. Whole-system battery power is abs(current_mA) × voltage_mV / 1,000,000. The integrated current-and-voltage samples are the primary estimate. I kept the raw capacity counter only as a coarse cross-check and did not use powermetrics, which requires administrator access.

An exploratory pair made the battery gauge's stepwise updates obvious, so I discarded it and added the 60-second loaded warmup before collecting 180 seconds of data. These remain whole-machine readings at the current automatic display brightness and background activity—not CPU package power. During the batch, the battery moved from roughly 79% to 77%, had 13 cycles, and reported about 4,684 mAh of full-charge capacity.

The numbers

The summaries above use medians for the short performance samples and averages across 37 battery readings for each three-minute loaded phase. The individual values are included here so the size—and the consistency— of the differences remains visible.

SHA-256, kB/s

Speedometer iteration scores

Corrected steady-state power batch

Every captured value, along with the calculations behind the derived ratios, is preserved in the benchmark record.

Run it yourself

The scripts are deliberately less convenient than a benchmark that flips settings for you. Select each mode in System Settings, then tell the harness which one you expect. If macOS reports something different, the run stops. The benchmark never asks for administrator access and never changes the power policy itself.

git clone git@github.com:marianposaceanu/dot-files.git ~/dot-files
cd ~/dot-files

# System Settings → Battery → Low Power Mode → Never
./benchmarks/m4_low_power_benchmark.sh normal

# System Settings → Battery → Low Power Mode → Only on Battery
./benchmarks/m4_low_power_benchmark.sh low

# Power batch: run once in each already-selected mode
python3 benchmarks/m4_power_benchmark.py normal
python3 benchmarks/m4_power_benchmark.py low

• m4_low_power_benchmark.shmode verification, environment capture, OpenSSL samples, and result logging
• speedometer_runner.mjsfresh Chrome profile, exact flags, DevTools automation, version capture, and cleanup
• m4_power_benchmark.pymode verification, idle and loaded sampling, battery telemetry, warmup, and timestamped JSON output
• m4-low-power-mode-20260731.mdraw measurements and derived ratios

How far to trust the result

The gap is too large and too consistent to dismiss, but the scope is still one laptop, one operating-system build, and one browser build. These are the boundaries I would keep in mind before generalising from it:

• SHA-256 is a sustained native cryptographic workload, not a universal single-thread score.
• Speedometer leans into CPU- and browser-heavy interaction. Network-bound browsing should show a smaller end-to-end penalty.
• Other Apple chips and macOS versions are free to apply a different power policy.
• Five browser iterations reveal the cold-to-warm pattern, but repeated randomized A/B/A trials would provide a stronger estimate.
• The Mac's battery telemetry updates far more slowly than dedicated lab equipment. More randomized runs and a physical power meter would tighten the energy result.
• The battery-life figures are arithmetic extrapolations from continuous SHA-256 load, not measured browsing runtimes.

On this M4 MacBook Air, Low Power Mode earns its name: it saves meaningful energy by giving up meaningful speed. Whether that is a good trade depends less on the battery icon than on the work in front of you.