Why Zoom drained an M4 MacBook Air while the CPU looked quiet

An unplugged video call consumed 15 battery points over roughly 86 minutes. That sounds like a simple battery story until Activity Monitor refuses to provide a simple villain: the CPU was not screaming, the battery was healthy, Zoom was native Apple Silicon code, and hardware video compression was active.

So where did the energy go?

The answer lives in the rest of the video pipeline. Encoding and decoding are only two stages. Camera effects, crop and scale, colour conversion, incoming participant layout, Zoom rendering and WindowServer composition still need work, and a large part of that work was attributed to the GPU-facing Zoom coalition.

The controlled preview gave the effects a measurable but modest cost: plain camera was about 4% global CPU, macOS Background about 5%, and Background plus Center Stage about 6%. Touch up my appearance made no measurable difference in that preview. Those increments are real, but they do not explain the complete drain.

Apple's Energy Impact and coalition percentages are attribution scores, not a clean electrical split. They are useful for comparison and diagnosis; they cannot be added up as watts.

The machine was not sick

• MacBook Air M4 (Mac16,12)
• 16 GB RAM
• macOS 26.6.1, build 25G76
• Zoom Workplace 7.0.6 (84834)
• Zoom and its helpers were native arm64; Rosetta was not involved
• Battery health: Normal
• Maximum capacity: 100%
• No external display or screen sharing was found during the session
• No thermal throttling, crash loop, or runaway process was found

What the battery actually did

• Began the unplugged interval at 80% charge
• Ended the unplugged interval at 65% charge
• Whole unplugged interval: 15 percentage points over 86 minutes, approximately 10.5% per hour
• The actual Zoom activity occurred in separate call segments rather than throughout that entire interval
• Representative active-call samples projected approximately 18% and 24% per hour; these short-window projections are coarse because battery percentage is quantized
• Approximate active-call average: around 21% per hour, corresponding to roughly 10–13 W of whole-machine power on this battery

Zoom dominated the attribution score

Across the broader 55-minute analysis window, Apple SystemStats attributed its relative application Energy Impact approximately as follows:

These percentages are shares of Apple's process-attribution score, not percentages of total battery wattage. Display-panel power, camera sensor/ISP activity, media engines, Wi-Fi radio, DRAM, and other hardware are not cleanly represented as separate process rows.

Two ten-minute windows

The following figures come from cumulative SystemStats coalition counters. “Energy score” is Apple's relative Energy Impact metric, not joules or watts. CPU and GPU figures are attributed execution time accumulated over each ten-minute interval.

First ten-minute call segment

The camera capture pipeline was observed at 1280×720, 30 fps.

System-wide coalition activity for this interval:

• CPU time: 4.75% of wall time
• GPU-attributed time: 33.50% of wall time
• Short-window battery projection: approximately 18% per hour

Second ten-minute call segment

The camera capture pipeline was observed at 1920×1080, 30 fps. This is the camera input format and does not prove that Zoom transmitted 1080p.

System-wide coalition activity for this interval:

• CPU time: 4.71% of wall time
• GPU-attributed time: 31.25% of wall time
• Short-window battery projection: approximately 24% per hour

Against a pre-call baseline

During a ten-minute baseline before Zoom video was active:

• CPU time: 2.20% of wall time
• GPU-attributed time: 4.50% of wall time

During the calls, CPU activity was roughly twice the pre-call level while GPU-attributed activity was approximately seven times the baseline. The video workload was therefore much more GPU/media-pipeline-heavy than CPU-heavy.

The second call cost more, but cameracaptured did not run away

Between the representative first and second segments:

• Zoom's raw Energy Impact score increased by approximately 51%
• Zoom-attributed GPU time increased from 64.3s to 90.1s, approximately 40%
• Zoom CPU time increased only from 11.2s to 13.0s
• The direct cameracaptured Energy Impact score stayed almost unchanged
• Direct cameracaptured GPU time decreased from 59.1s to 29.9s
• Total system GPU-attributed time remained similar: 33.5% versus 31.25%

This is evidence that the larger second-segment expense was attributed principally to Zoom's own pipeline, not to a runaway macOS camera daemon. The 1080p camera input correlates with more Zoom-side work, but it is not sufficient to prove causation: the incoming participant streams, meeting layout, rendered content, network conditions, and exact effect state may also have changed.

The direct cameracaptured percentage must not be interpreted as the complete cost of the camera or macOS effects. Some hardware work may be billed to Zoom, and camera ISP or Neural Engine power may not appear as a separate historical process coalition.

Hardware codecs do not make the rest of video free

The hardware media engines perform video compression and decompression. They do not perform the complete video pipeline.

Local camera
    → camera sensor and ISP
    → segmentation / Background / Center Stage
    → crop, scale, color conversion and composition on GPU/ANE/camera services
    → hardware media encoder
    → network

Remote video
    → network
    → hardware media decoder
    → scaling and participant composition on GPU
    → Zoom rendering
    → WindowServer desktop composition
    → display

Expected GPU tasks include:

• Center Stage cropping, tracking, and rescaling
• Background segmentation and compositing
• Pixel-format and color-space conversion
• Camera-frame preparation before encoding
• Scaling decoded participant streams
• Composing Speaker or Gallery layouts
• Rendering Zoom's video surfaces and interface
• WindowServer's final desktop composition

Consequently, GPU activity does not mean Zoom encoded video on the GPU. Logs support Apple VideoToolbox/hardware compression. Hardware acceleration was working: CPU usage remained low while substantial processing and rendering were offloaded.

The first segment's attributed GPU-time breakdown was approximately:

The second segment was approximately:

GPU times are attributed execution counters, not a direct wattage split. Different GPU clients can also have overlapping work; the values should not be treated as independent electrical measurements.

The helper names are easy to misread

Both call segments launched the following Zoom helpers in addition to the main application:

• caphost
• CptHost
• aomhost

SystemStats grouped these helpers into the us.zoom.xos coalition and did not retain a per-helper historical energy split.

aomhost is an AI/video-effects host, not proof that Zoom was software-encoding AV1. Inspection showed modules related to background replacement, portrait segmentation, denoising, and super-resolution. It also opened the Apple Neural Engine. The historical logs do not reveal which model was active or how much power it consumed.

The available historical data also does not separate Zoom's send/encode work from receive/decode/render work.

What the effects cost in a controlled preview

With a 720p/30 Zoom preview:

Additional tests:

• Touch up my appearance on versus off: no measurable difference
• HD on versus off: no preview difference; both captures remained 720p

The HD preview result does not prove that HD is irrelevant inside a real meeting. Zoom can negotiate different camera, send, and receive resolutions once connected. The Video section of Zoom's Statistics window should be checked during an actual test meeting.

The settings worth changing

For the required use case—camera on, Background and Center Stage needed—the lowest-cost configuration supported by the evidence is:

1. Keep macOS Background and Center Stage enabled.
2. Disable duplicate Zoom background, auto-framing, portrait lighting, low-light adjustment, temporal denoise, and super-resolution features.
3. Leave Zoom hardware acceleration enabled for video sending, receiving, and processing.
4. Leave Touch up my appearance according to visual preference; it had no measurable effect in this preview test.
5. Keep HD off if higher local/send resolution is unnecessary, but verify actual negotiated resolution during a meeting rather than relying on preview.
6. Prefer Speaker View to a large Gallery View when practical; rendering many simultaneous incoming videos can increase decode, scaling, and composition work.
7. Avoid overlapping Zoom and macOS versions of the same effect.

The tempting hidden flags lead nowhere

The installed Zoom binaries contain internal names such as:

• EnablePowerSaverMode
• LocalPowerSaverModeEnabled
• WebPowerSaverModeEnabled
• videoapp_power_saver_mode
• EnableGPUComputeUtilization
• EnableGPUAccWithSmartMode
• EnableHardwareAccForVideoSend
• EnableHardwareAccForVideoReceive
• EnableForceMaximumCameraSizeForSending
• EnableTemporalDeNoise

These are not supported command-line options. No corresponding normal user preference, managed preference, or feature-toggle database entry was found. EnablePowerSaverMode appears to be internal or server-controlled. Writing speculative plist keys is not recommended because it could be ignored, inverted, or disable beneficial hardware acceleration.

No verified, supported hidden low-CPU flag was found.

Where the evidence stops

Supported by the evidence

• The battery is healthy.
• Zoom was native Apple Silicon software.
• The call caused a large video/GPU workload.
• Zoom's coalition dominated process-attributed energy.
• Hardware video compression was in use.
• Background and Center Stage add measurable CPU load.
• Touch up my appearance was not measurable in the preview test.
• Zoom's own visual-effect implementations were observed to be more CPU-intensive than the macOS equivalents.
• The second call segment had materially more Zoom-attributed work.

Not recoverable from the historical logs

• Exact watts for Zoom, GPU, ANE, camera ISP, display, Wi-Fi, or media engines
• Exact cost of Center Stage alone during the observed call
• Exact cost of Background alone during the observed call
• Per-helper Zoom energy for caphost, CptHost, and aomhost
• Encode-versus-decode-versus-render energy inside Zoom
• Whether 1080p camera capture meant 1080p transmission
• A complete electrical total obtained by adding process Energy Impact percentages

The next test should measure power live

For a future controlled test, run this command in Terminal while Zoom preview or a test meeting is active:

sudo powermetrics \
  --samplers tasks,cpu_power,gpu_power,ane_power \
  --show-process-energy \
  --show-process-gpu \
  --show-process-coalition \
  --sample-rate 1000 \
  --sample-count 60 \
  --output-file "$HOME/Desktop/zoom-powermetrics.txt"

The administrator password is entered locally into Terminal and should not be shared. powermetrics can provide estimated CPU, GPU, and ANE rail power plus live per-process activity. Its power estimates are useful for comparing configurations on the same Mac but are not laboratory-grade measurements and may still omit a clean ISP/media-engine split.

A useful controlled sequence would be:

1. Plain camera, all effects off — 60 seconds
2. macOS Background only — 60 seconds
3. Background + Center Stage — 60 seconds
4. A real test meeting in Speaker View — 60 seconds
5. The same meeting in Gallery View — 60 seconds

Keep screen brightness, window size, participant count, charger state, camera resolution, and other applications unchanged between samples.

What the evidence supports

The Mac's media engines were being used, but they solve only codec compression and decompression. Zoom still generated a substantial GPU workload for camera processing, incoming-video scaling, layout composition, rendering, and desktop presentation. macOS Background and Center Stage add a visible but smaller incremental expense. The most important remaining optimization target is the amount and resolution of video Zoom processes and renders during a real call, not Touch up my appearance and not a speculative hidden preference.