How AI Agents Changed Laptop Power Management
You kick off an AI coding agent before dinner — a multi-file refactor that will run for two hours. You come back to find your MacBook asleep, the job dead, and a half-applied diff in your working tree. That failure mode did not exist five years ago, and it points to a real gap between how macOS handles power and how developers actually use their machines today.
How Laptops Were Designed to Sleep (and Why It Worked)
Laptop power management was built for human rhythms. No keyboard for a few minutes: dim the display. A bit longer: sleep. Apple's idle timers made sense because the machine's job was to wait for you, and waiting cost battery.
The model held through a decade of background downloads, long compiles, and video encodes because those tasks either finished quickly or held IOKit assertions to signal the OS. A video renderer holds a media assertion; xcodebuild completes in minutes and exits. The machine always had some signal to work with.
Nothing in that design anticipated a workload that runs for hours with zero user input and no natural completion boundary. That scenario simply did not exist when the power model was written.
What Agentic AI Workloads Changed About Developer Needs
AI coding agents — Claude Code, Cursor's background agent, Aider, GitHub Copilot Workspace — work by chaining dozens of steps: read a file, plan an edit, write code, run a test, interpret output, loop. A single refactoring task can run for two or three hours.
macOS sees none of that as activity. There is no keyboard event, no mouse movement, no display frame being rendered. The idle timer counts down to zero. The display sleeps. The system follows shortly after, terminating the terminal session mid-job.
This is not a macOS bug. Idle sleep is correct for a machine that is genuinely idle. The structural problem is that the OS has no built-in concept of a process doing cognitive work on the user's behalf — work the user actually wants to finish.
Related guideWhat Is a Safe Runtime Layer for Mac?Why a Simple Wake Lock Creates New Risks
The obvious fix is a wake lock: caffeinate, Amphetamine, or a pmset change. These hold an IOKit power assertion and suspend the idle timer. The agent keeps running. For a short daytime session while you are plugged in and nearby, this is often all you need.
The picture shifts for overnight or on-battery work. A blind wake lock has no battery floor. Leave a MacBook running caffeinate on a 40% charge with a heavy agent loop, and four hours later you may find the battery at zero, the session lost, and a partial commit in an inconsistent state. The tool did its job — it kept the machine awake — but it had no way to stop gracefully before the power ran out.
Heat is the subtler concern. A MacBook under sustained load with limited airflow throttles, and a wake lock that never checks thermal state has no guardrail. This risk grows in confined spaces — a nearly-closed lid, a soft surface that blocks vents, or a bag. The agent runs; the machine runs warm with no mechanism to back off.
The Safe Runtime Pattern for AI-Driven Work
A safe runtime layer holds the wake assertion and watches the conditions that would make continued running unsafe. The difference is roughly: a wake lock holds a door open; a runtime layer holds it open until the system signals trouble, then closes it gracefully. Understanding what a safe runtime layer does is useful context if you run long AI workloads regularly.
In practice this means a low-battery floor — auto-stop at 15 or 20 percent so the machine can still wake cleanly afterward. It means checking the thermal signal the OS exposes and backing off when the system reports heat pressure. An optional process watcher adds another guardrail: stop the session when the agent process exits rather than running until the battery hits zero.
For a quick daytime run on AC power, caffeinate is fine — no extra tooling needed. For overnight, on-battery, or lid-closed sessions, a layer that monitors conditions alongside the wake assertion helps reduce the risk of waking up to a dead machine or a job that died in a bad state.
A feature of LidRun's keep-awake engine.
LidRun keeps your work running with the lid closed, with battery and thermal safety built in.
Frequently asked
Not always. For a short run while you are at your desk and plugged in, a simple caffeinate command or keep-awake app handles the main problem: the idle sleep timer. For longer runs, overnight sessions, or battery-only work, you also want a low-battery floor and some thermal awareness. Without those, the machine can drain or get warm with no way to stop gracefully before something breaks.
macOS measures idle time by user input — keyboard events, mouse movement, and display activity. An AI agent generates none of these; it runs in the background without touching input devices. Once the idle timer reaches its threshold, the system sleeps and terminates the agent's terminal session or suspends its process entirely.
For a plugged-in machine in a stable environment, caffeinate usually works well. It becomes a risk on battery: caffeinate holds the wake assertion but has no battery floor, so the machine can drain to zero mid-job. If the battery starts at 40% and the job takes four hours, the session may not survive. A tool that auto-stops at a low-battery threshold reduces that risk without requiring you to babysit the run.
A long build runs for minutes, exits cleanly, and many build tools hold IOKit assertions during compilation. AI agents are open-ended: they loop, call external APIs, write and test code, and may run for hours with no defined completion time. The combination of long duration and unpredictable finish is what makes power management a real concern — a build finishing early costs you nothing; an agent dying overnight costs you the whole session.