Why your laptop is a bad place to run AI coding agents

The most common way a long-running agent dies on a MacBook is that somebody picked the machine up. Without an external display, an external keyboard and connected power, closing the lid puts the machine to sleep, and a sleeping machine is not running your test suite. There is no partial credit: the process is not slow, it is not executing.

The details matter because they explain the most misleading data point people have — the time it kept working. macOS portables default to hibernatemode 3, and power management is configured separately per power source: pmset -b for battery, pmset -c for the charger. So "it stayed up that one time" almost always decodes to "it was plugged in that one time, into a dock, with a display attached" — a configuration you happened to be in, not a property of the machine.

caffeinate is a mitigation, not an architecture

The standard answer is caffeinate, and it genuinely works: an IOKit power assertion that lives as long as the invoking process does, with -i to prevent idle sleep and -w <pid> to tie it to a specific job. But read the man page carefully. The system-sleep assertion, -s, "is valid only when system is running on AC power" — on battery, with the lid shut, it does not save you. And because the assertion dies with the process holding it, quitting the terminal that started it quietly removes the guardrail.

Uptime that depends on remembering a flag is not uptime. It is a habit with a failure rate.

Power Nap is not a compute service

People assume a sleeping Mac keeps doing things, and it does — a very short list of things. Power Nap wakes the machine periodically to check Mail, update Calendar and refresh other iCloud events on battery, plus download software updates and run Time Machine backups on the adapter. That is the whole list. It does not resume your agent, your build, or your language server.

App Nap deprioritises whatever you are not looking at

Even fully awake, macOS de-prioritises background work. An app that is not in the foreground, has not recently drawn to a visible window and holds no power-management assertion becomes a candidate for App Nap, which applies priority reduction, timer throttling and I/O throttling. Apple's own guidance is blunt that these measures "do not necessarily save energy" — their purpose is to reduce a background app's impact on the foreground. That is the right trade for a chat client, and precisely the wrong one for the eight-hour job you deliberately left running behind your browser.

Apple silicon laptops are extraordinarily fast, and that is not the argument. The argument is that an agent run is not shaped like a benchmark run. Benchmarks are seconds to minutes; a fleet of agents is hours of near-continuous compilation, type-checking, container builds and file I/O, restarted the moment each one finishes. What governs that workload is steady-state throughput after the heatsink has saturated, not the peak your machine posts in the first ninety seconds.

Apple is unusually direct about the mechanism. High Power Mode exists on the 14- and 16-inch MacBook Pro specifically to let the fans spin faster, because the extra cooling capacity is what enables higher performance in very intensive workloads. That is the vendor stating plainly that sustained performance on a laptop is gated by how much heat you can move — and a chassis designed to be carried moves less of it than a box that never leaves a desk. In the other direction, Low Power Mode trades throughput for battery runtime: the right decision for a laptop, the wrong one for a job queue.

Then there is the environment, which nobody controls. A laptop runs on a lap, a duvet, a sofa or a train tray table — surfaces that block intake vents — at whatever temperature the room happens to be. Datacenters spend enormous sums on exactly this boring problem: moving air at a known temperature past hardware in a known orientation. Your bedroom spends nothing, and throttling becomes the steady state rather than the exception.

Long-lived agent sessions assume a stable network path — a persistent SSH connection, a WebSocket to a model API, a streaming response measured in minutes. Laptops are the one class of computer that guarantees an unstable one, because their defining feature is that they change location while running.

• Captive portals need a human. RFC 8908 standardises the captive portal API, and the model is explicit: the portal is a URL "with which a user can interact." A background session has no user and no browser tab. What it observes instead is DNS resolving to a router login page and every request returning something that is not the API it asked for.
• Roaming breaks connections. Walking between access points, dropping from WiFi to a phone hotspot, or undocking from Ethernet means a new path and usually a new address. TCP connections bound to the old one do not survive, so the SSH session and the streaming request end together — mid-clone, if the timing is unkind.
• Sleep and wake tear down state. Even a brief sleep drops sockets that had no idea anything was wrong, and the far end learns about it via a timeout minutes later.
• Corporate VPNs re-authenticate on a schedule. Many require an interactive MFA tap to renew. When that lands at 03:00, the agent does not tap anything.

The structural point is that your agent's connectivity has your mobility as a dependency. Move the agent to a host that never moves and the relationship inverts: the long-lived connection lives between the agent and the services it needs, and your laptop becomes a client whose disconnection means nothing more than a closed window.

Strip the joke away and "production" is a short list of properties: redundant power, health checks, automatic restart on failure, alerting, someone reachable when the alert fires, and enough capacity isolation that one workload cannot starve another. Region us-bedroom-1 has none of them. It has one machine, one charger, and a battery that is a countdown rather than a UPS.

Recovery is the underrated part. On a laptop, mean time to detect is "whenever I next look at that particular window", so a job that dies at 02:14 is found at 09:40 and the seven hours in between are not degraded service — they are nothing happening at all. No supervisor process, no retry policy, no page. There is a person, and the person went to lunch.

None of this would be acceptable from a vendor. We accept it from ourselves because the machine is right there and feels responsive when we touch it, which measures interactive latency and not availability.

If your instinct here is to move the work onto a Mac mini in a closet, that is a real improvement and an honest first step — the lid never closes, the power is stable, the thermals are a box on a shelf rather than a laptop on a duvet. It is also still a single node with nobody on call, which is why it gets its own status page at macministat.us.

The usual answer to lid closure and dropped connections is tmux, and tmux is genuinely good at what it does: it decouples your session from the terminal emulator, so quitting the app no longer kills the shell. What it does not do is make anything durable. The tmux server is a process on the same machine, and it dies with the same kernel panic, the same overnight OS update and the same flat battery.

What is at risk is rarely the files. It is the work-in-progress around them: the branch that was never pushed, the scratch state in /tmp that a restart clears, the half-applied refactor spread across a working tree, and — the expensive one — the agent's accumulated context. The plan it built, the dead ends it ruled out and the reasoning behind the current diff are usually worth more than the diff, and they are the least durable thing on the machine.

Committing early and pushing constantly helps, and it is also discipline compensating for architecture, which is the pattern this whole page is about.

The reason to care about agents at all is parallelism: several tasks progressing at once on separate branches while you do something else. On a single laptop, parallelism is contention. Every agent shares one CPU package, one memory bus, one SSD and one uplink — not only with each other but with your editor, your language server, your own test run, your container runtime, your browser and the video call you are on.

Adding an agent does not add capacity; it divides existing capacity, and the divisor includes your own interactive latency, so a meaningful share of the cost is paid by you, in the foreground, all day. Memory pressure usually shows up first: the machine swaps, everything slows in a way that is hard to attribute, and the natural response is to close a tab rather than to conclude the topology is wrong.

Isolation is what makes parallel agents feel free rather than expensive — each in its own environment with its own CPU and memory allocation, failing independently, competing with nothing you are typing into. That is not something you configure your way into on one laptop. It is a property of running the work somewhere else.

This one applies with particular force to laptops, because a laptop is a personal machine. The host running your agent also holds ~/.ssh, your cloud credentials, your .env files, your kubeconfig, your keychain and a browser logged into everything you use. There is no separation because you never wanted one — it is your computer.

Meanwhile an agent's behaviour is partly authored by content it did not write and you did not review: READMEs, issue threads, dependency install scripts, pages it fetched while researching. Prompt injection is not a thought experiment; it is the ordinary consequence of letting a capable process read the internet and then act. The question stops being "will my agent misbehave" and becomes "what can it reach if it does".

Anthropic's sandboxing work states the coupling plainly: without network isolation a compromised agent could exfiltrate sensitive files like SSH keys, and without filesystem isolation it can escape the boundary and reach the network anyway. The same work reports an 84% reduction in permission prompts once real boundaries replace prompting — safety and speed stop trading off. Claude Code's own documentation is more direct still, advising that --dangerously-skip-permissions sessions always run inside a container, a VM, or the sandbox runtime. It also notes something people miss: the built-in Bash sandbox constrains Bash commands only, while file tools, MCP servers and hooks keep running on your host.

To put a number on how contained your current setup is, that is the entire subject of our sibling site, safely-skip-permissions.dev.

For short, supervised, interactive work, your laptop is the best machine you own and none of the above applies. Latency to your own filesystem is zero, your tooling is configured, your credentials are where you want them, and you can read the diff as it appears and hit ⌘C when it goes somewhere strange. Debugging, pairing, exploring an unfamiliar codebase, a tightly scoped edit — do that locally and ignore this page while you do.

The dividing line is attention, not task size. While you are watching, you are the control plane: the health check, the retry policy and the alerting, and a laptop is a fine substrate for a control plane that is currently paying attention. The moment the work outlives your attention — an overnight run, a queue of tasks, ten agents on ten branches while you are in meetings — the control plane goes to lunch, and every property that makes the machine portable turns into an unhandled failure mode.

Which is the whole argument, in one sentence: laptops are excellent clients and poor hosts.

Every substantive claim above traces to one of these. Where no number was available from a primary source, the point is made qualitatively rather than invented.