let's start with a really simple mobile automation. i wanted my phone to use cellular data when i'm out, but automatically switch to airplane mode at night when i'm home. the goal was simply to save battery and avoid unnecessary radiation while i sleep.

if you try to build this using native tools like ios shortcuts, you quickly realize you're forced into an event-driven spaghetti. "if sleep mode starts -> turn on airplane mode." "if sleep mode ends -> turn it off." "if i leave home -> turn it off." but what if i come back home, and it's already night? i didn't create a trigger for that edge case.

what i actually wanted wasn't a chain of event listeners. i wanted a background daemon constantly doing a complex state poll: "am i home? is it night? is airplane mode off? if yes to all, keep it in airplane mode."

but mobile operating systems don't give you complex state polling as a default api. if you try to force it using background workarounds like persistent notifications or infinite loops, ios jetsam or android doze will hunt your process down and quietly kill it.

this isn't apple or google being bad at software design. we usually optimize code for time and latency, but on a mobile device, the ultimate currency is joules. the os simply refuses to pay the thermodynamic bill for my little script.

underneath this simple os limitation lies the physical reality of mobile hardware, and a preview of how tech giants plan to shift their massive server costs onto our batteries under the guise of privacy.

the illusion of continuous compute

desktops are deterministic; you are plugged into the wall and the cpu is at your disposal. mobile operating systems, however, are opportunistic. they are essentially asleep, waking up in a panic only when there is a window to batch tasks together.

the highest "transaction tax" on a phone is waking up the cellular radio. moving the rrc (radio resource control) state machine from idle to connected causes a massive energy spike. to avoid paying this tax every second, the os delegates passive listening to the aop (always-on processor).

the aop runs on just 1 to 2 milliwatts, checking accelerometer data or pinging wi-fi mac addresses. unless the aop decides the sensor data is critical enough to wake the main application processor and write to ram, your custom background shortcut never gets the clearance to run.

wirth's law and the battery

so what happens if a battery breakthrough gives us 10x capacity tomorrow? will the os finally let us poll whatever we want in the background?

jevons paradox and wirth's law suggest otherwise. as hardware gets faster, software gets sloppier. if energy constraints disappear, the extra capacity won't go towards running your neat little utilities; it will be immediately eaten by bloat. today, strict os energy limits act like a central bank, disciplining developers.

but we will probably never see that theoretical hardware surplus anyway. because big tech already knows exactly what they are going to spend it on.

the cost transfer: edge ai as a trojan horse

we saw this happen with the web. servers used to render everything. then modern js frameworks came along and shifted the compute cost to the user's browser—the thick client architecture.

now, the exact same evolution is happening with ai.

for companies running massive llms, the biggest bottleneck isn't training models. it's the astronomical hardware and electricity costs of running billions of daily inferences in the cloud. the solution is slms (small language models) and edge ai: take the compute load off the cloud and push it down to the silicon in your pocket.

zero latency and offline capabilities are great ux features, but behind the curtain, this is a massive transfer of infrastructure costs. and it is perfectly packaged and marketed to us: "your data never leaves your device. 100% privacy."

privacy here is a trojan horse. they get to shut down expensive server racks, and you get to feel secure.

joules per token

the industry is already shifting its metrics from token latency to "joules per token."

if you run a 4-bit quantized model like llama 3.2 3b on a phone, you get decent speeds. but you immediately hit the memory wall. a server gpu pushes terabytes per second; a flagship phone maxes out around 50 to 80 gb/s.

they don't quantize these models just to save storage space. physically moving weights from dram to the cpu dies uses orders of magnitude more energy than the actual matrix math. moving data costs joules. soon, the "always-on background agents" reading your screen or analyzing your emails will bypass the 1-milliwatt aop. they will fire up the npu, hit thermal limits (dark silicon), and aggressively drain your battery.

the trade-off

my location shortcut failing wasn't a bug; it was strict capital management by the os. but the rules of capital allocation are changing.

the future of operating systems is local, on-device compute. the clear reward for this architecture shift is actual data privacy. however, in this new ecosystem, privacy ceases to be an abstract, free digital right. it becomes a thermodynamic transaction—a luxury you will finance directly with your own battery capacity.