When should an AI device sleep? The hidden cost of waking up

The problem: a small model, a short battery life

A sensor collects a reading, a small AI model interprets it, and the device waits for the next measurement. If computation takes only a few milliseconds, why can the battery still drain quickly? One possible answer is that the system spends most of its time waiting while consuming energy. Putting it into a sleep mode seems natural. Yet when pauses are short, this choice can consume more energy than it saves.

The central question is: how long must a pause last for sleep savings to offset the cost of entering and leaving that state? We will build an energy budget for a hypothetical device, separating power, energy, pause duration and response delay. The result will be a calculable threshold and a way to identify what to measure on a board. All numerical parameters are synthetic: they are not measurements of a commercial microcontroller, an EL-AI product or a real battery.

Power and energy: tap and tank, with a caveat

Power describes how quickly energy is consumed: it is measured in watts, equivalent to joules per second. Energy is the quantity consumed over an interval, measured in joules. A more open tap resembles higher power; the water delivered resembles energy. The analogy only separates rate and quantity: a battery has electrical and chemical behaviour that an ideal tank does not describe. For our budget, E = P × t suffices when power is constant.

Processing at 100 milliwatts for 20 milliseconds consumes 2 millijoules: 0.100 W × 0.020 s = 0.002 J. “100 mW” alone does not give the cost of a decision because duration is missing; “2 mJ per decision” does not give average power without the decision rate. This is why comparing two models also requires execution frequency, work performed and the boundary of the measured system.

The same work, two ways of waiting

Define a cycle of duration T, from the start of one decision to the start of the next. The active phase lasts tA = 20 ms at PA = 100 mW. The remaining time is G = T − tA. Compare two strategies performing exactly the same work: in the first, the processor remains idle but ready at PI = 30 mW; in the second, it transitions, sleeps at PS = 0.1 mW and becomes ready before the next cycle. “Idle” and “asleep” describe different states, not synonyms.

Entering and leaving sleep together take tX = 4 ms and consume EX = 0.3 mJ. EX is the total energy during those four milliseconds, not an overhead added to another consumption already counted over that interval. This convention avoids double counting. Assume sleep retains what is needed to resume and does not change active work: if the model must be reloaded or buffers rebuilt, include that cost. G must be at least tX for the state to fit in time.

The budget, one term at a time

The first quantitative question is how much energy the whole cycle consumes. Both strategies include PA × tA, the useful work. The always-ready strategy adds PI × G. The sleep strategy adds EX and only PS × (G − tX), because transitions have already occupied part of the pause. All times must use the same units: the code uses seconds, watts and joules, converting results only for display.

With one decision per second, T = 1 s and G = 0.98 s. Remaining ready costs 2 + 29.4 = 31.4 mJ per cycle. Sleeping costs 2 + 0.3 + 0.0976 = 2.3976 mJ. The sleep term uses 0.976 s, not 0.98 s. In this example waiting costs far more than computation when the processor stays ready. Optimising only the neural network would leave most of that strategy’s consumption untouched.

The surprise of short pauses

Repeat exactly the same work every 25 ms. The pause is now only 5 ms. Sleep fits, since four milliseconds suffice for transitions, but only one millisecond of sleep remains. Staying ready costs 2.15 mJ per cycle; sleeping costs 2.3001 mJ. Sleep power is still very low, yet total energy is higher. We paid for entry and return for too short an interval: this is the hidden cost that a power figure alone cannot show.

Deriving the threshold: how long must the pause last?

We can now answer without trying every duration. Subtract the energies: active work cancels because it is identical. Sleep wins when its transition cost is smaller than the savings over the wait. Rearranging, with PI greater than PS, gives threshold G*. The small term PS × tX corrects for EX already covering the entire transition interval. Do not remove it by silently changing the definition of EX.

In our example the pause must exceed about 10.02 ms and must also contain the transitions. Since active computation takes 20 ms, the full period must exceed about 30.02 ms. The pause threshold and period threshold are different. At 30 ms we are just on the unfavourable side: the difference is only 0.0006 mJ per cycle. Treating those synthetic decimals as guaranteed measurement precision would be unreasonable; near break-even, measurement error and variability can reverse the choice.

To read the plot, first follow the idle line: it rises quickly because every millisecond adds consumption at 30 mW. The sleep line starts higher because of the fixed transition cost, then rises slowly at only 0.1 mW. Left of the crossing, staying ready wins; to the right, sleep wins under these assumptions. The plot does not show total decision energy: adding 2 mJ to both curves would shift them upwards without changing the crossing.

Saving energy is not enough: waking on time matters

The energy criterion does not guarantee timely response. tX combines entry and exit; wake-up latency is the portion needed to become operational after an event. With a known periodic measurement, wake-up can be scheduled early. With an unpredictable event it cannot: exit latency becomes part of response time. A mode can therefore save energy while being incompatible with the deadline for producing a result.

Zephyr documents a residency policy that compares time until the next scheduled event with minimum residency plus exit latency. This connects the reasoning to embedded software, but the parameters belong to the platform: our G* does not automatically configure a board. Check which wake sources remain active, which peripherals lose state and what constraints the application imposes. An energy equation does not replace that information.

The sensor can change the battery conclusion

The budget so far covers only the chosen processing subsystem. Suppose a separate sensor, excluded from those power values, remains on at 5 mW. Over a one-second cycle it adds 5 mJ to both strategies. Sleep therefore rises from 2.3976 to 7.3976 mJ per decision. The choice between strategies does not change because the common term cancels; total energy and the potential for further processor improvements change substantially.

We cannot switch the sensor off and still claim the same service without checking. It might need settling time, recalibration or continuous samples that would be lost during sleep. If a model must recognise brief events, sampling less often changes what it can observe. This trades information availability against energy; it is not a free saving. A radio, regulator and supply losses also belong in the budget when the target is battery life for the complete device.

Three different numbers: energy, average and peak

Average power is cycle energy divided by T. In the one-second case, 2.3976 mJ corresponds to 2.3976 mW average for the subsystem without the sensor. At 25 ms, 2.3001 mJ becomes 92.004 mW: energy per decision is similar, but there are forty decisions per second. Similar millijoules do not imply similar battery life. Always ask how often the work repeats.

Peak power is another piece of information. Transition energy and duration determine only average transition power, 75 mW here. They do not describe its time profile or rule out a much larger peak. Without a sufficiently resolved current and voltage trace, we cannot infer supply sizing. Likewise, average wake-up latency does not guarantee a high percentile or a deadline on every cycle.

From calculation to measurement: what is actually missing

To turn the model into a hardware evaluation, identify board and revision, microcontroller or SoC, firmware, AI runtime, compiler, clock and power mode. Specify input, batch size and included active work: acquisition, preprocessing, inference and communication are not interchangeable. A protocol should integrate V(t) × I(t) over complete cycles, include transitions, and separate cold start from steady operation. Record temperature and supply conditions because parameters can change.

These are proposed checks, not experiments already performed. The downloadable material only executes model arithmetic, verifies break-even and generates plots. It uses no randomness and needs no seed; it preserves inputs, versions and results. The short code exposes the decisive step: subtract transition time from the pause and avoid counting the same energy twice. The JSON lets readers compare every table row with computed output.

The answer: sleep must earn its keep

Letting an AI device sleep pays when the available time both recovers transition cost and preserves the required service. In our example energy breaks even at a pause of about 10.02 ms: a 5 ms pause makes consumption worse, while 980 ms reduces it substantially. The lesson is to measure the entire cycle and ask whether savings arrive soon enough, rather than always selecting a deeper mode. Only then does it make sense to discuss battery life, still accounting for sensors, communication and losses.

Sources and reproducibility

The primary software source is Zephyr documentation on power states and management policies, accessed at the latest URL on 27 September 2026. The budget and numerical parameters are an independent educational construction, not a Zephyr benchmark. We claim neither a board implementation nor existing EL-AI embedded products. This study explores a requested editorial topic without turning it into a commercial claim.

Zephyr Project — System Power Management: Power States and Policies.

P_idle, P_sleep = 0.030, 0.0001  # W
E_transition, t_transition = 0.0003, 0.004  # J, s
P_active, t_active, T = 0.100, 0.020, 1.0
G = T - t_active
assert G >= t_transition
E_idle = P_active*t_active + P_idle*G
E_sleep = P_active*t_active + E_transition + P_sleep*(G-t_transition)
G_break_even = (E_transition-P_sleep*t_transition)/(P_idle-P_sleep)
print(f"{1000*E_idle:.4f} mJ; {1000*E_sleep:.4f} mJ")
print(f"{1000*G_break_even:.6f} ms")

Code, data, and instructions · JSON. Educational calculations executed with Python 3.14.0; figures with Matplotlib 3.11.2. AI-assisted analysis, without claiming peer review or human review. Original illustrative ImageGen cover: it does not document EL-AI people, premises, or installations. Sources accessed 27 September 2026.