AI Features and Phone Battery Life

A phone’s battery use comes from the complete workflow, not simply the label “AI.” A short on-device model call can use compute for a limited time; a cloud feature can use radio and display power while communicating; live audio or camera processing may keep sensors and processors active. The relative cost varies with model size, input, signal conditions, screen brightness, network state, and device design. Apple documents that its Foundation Models framework can use on-device models, Private Cloud Compute, or other providers, so the processing path is feature-dependent. Android developer guidance treats power as a measured performance issue. Android Studio profiles and system traces can help identify CPU, memory, timing, and battery behavior. Android also applies power limits based on device state and app standby bucket; its documentation cautions that execution quotas are approximate and change with conditions. Those app-scheduling rules are not an AI-specific estimate and should not be used to claim a universal battery cost for a model. To investigate a drain, compare like-for-like sessions on the same device and software version. Record screen-on time, network conditions, input duration, app state, and battery percentage; repeat a baseline without the feature. Check whether the feature runs in the foreground, schedules background work, or sends data over a weak connection. Avoid concluding that an NPU always uses less energy than a CPU for every workload: chip, model, hardware acceleration, and duration affect the result. Use the manufacturer’s battery diagnostics and app profiling where available.