Detection App CPU and Battery Impact

A reasonable thing to worry about

Running two machine learning models against a live camera feed for eight hours a day sounds expensive, and the concern comes up often enough to deserve a direct answer rather than reassurance.

The short version: the cost is real but modest, and it is modest because of deliberate choices about how often inference runs rather than because the models are trivial. Continuous computer vision can absolutely make a laptop hot and drain a battery. Avoiding that requires not doing the obvious thing.

The choice that does most of the work

The obvious implementation runs inference on every frame the camera produces — thirty or sixty times a second. That is how most real-time vision demos are built, and it is enormously wasteful for this application.

Stop Biting runs inference five times a second instead. That is roughly a twelvefold reduction in compute compared with a 60fps loop, and it costs nothing in effectiveness, because the thing being detected lasts seconds rather than milliseconds. A hand approaching a mouth is not a fast event on the timescale of video frames.

The detection logic then requires three consecutive positive samples before alerting, which at five samples per second means around 600 milliseconds of sustained proximity. So the sampling rate is low, and the alerting logic is built around that rate rather than fighting it.

What the models themselves cost

Both models come from MediaPipe, Google's on-device vision framework, and they are compiled to WebAssembly to run locally in the browser. These are small models designed for phones and laptops, not large models designed for servers — the same family of technology behind background blur in video calling, which runs acceptably on modest hardware while doing considerably more per second than this does.

The camera resolution is also deliberately unambitious — around 640 by 480 — because landmark detection does not benefit from more, and processing cost scales with pixel count.

Worth noting what does not happen: no video is uploaded, so there is no network cost and no upload bandwidth being consumed continuously in the background. The absence of a network round trip is a meaningful part of why the ongoing cost stays low.

What to expect in practice

On a reasonably modern laptop, detection runs as a background cost you are unlikely to notice during ordinary work — browsing, writing, email, meetings.

You will notice it more in a few situations. Older or low-power machines have less headroom. Running it alongside something already saturating the CPU — video editing, compilation, gaming at high settings — means competing for the same resources. And any continuous camera use has a battery cost, since the camera sensor itself draws power regardless of what is done with the frames.

On battery specifically, expect a measurable but not dramatic reduction in runtime. If you are working unplugged and short on charge, it is a reasonable thing to pause.

Getting the cost down further

A few practical options if the impact is more than you want.

Run it only during your high-frequency contexts rather than all day. Most people have two or three periods that account for the majority of their biting, and covering those captures most of the therapeutic value for a fraction of the runtime.

Close other camera-using applications, since multiple applications contending for the same camera is a common source of unexpected load and unreliable behaviour.

And keep it plugged in during long sessions, which sidesteps the battery question entirely.

The underlying trade-off is straightforward: continuous detection has a continuous cost, and the design decisions here are aimed at keeping it low enough to be worth paying rather than pretending it is zero.