My laptop kept throttling my AI agent. I fixed it by moving the shell off the machine.

Last month, I kicked off a long-running AI coding agent on my laptop before bed. It was supposed to refactor a sprawling Python codebase while I slept. I woke up to a thermal throttled CPU, a 40% battery drain, and a process that had been suspended halfway through because macOS decided to put the machine to sleep. That was the nudge I needed to finally move my persistent shell off local hardware.

The local machine was never meant to be always-on

Laptops are built for bursty work, not continuous 24/7 operation. Modern operating systems are aggressive about entering low-power states. Close the lid, walk away, and your running process is either paused or killed. Even when you keep the lid open, CPU frequency scaling shaves performance to keep thermals and battery life in check. On an Intel MacBook, a prolonged all-core workload can drop the CPU below base clock after a few minutes. On ARM chips, the efficiency cores can take over when you want the performance cores to stay lit.

Network is another weak point. Wi-Fi can stutter, IP addresses change, and VPNs drop. An AI agent that relies on API calls or a distributed build that fetches dependencies will die mid-stream if the connection blips. Laptop sleep is the obvious killer, but even temporary network loss can corrupt a long-running task that isn't designed to checkpoint and restart.

I've lost count of how many times I've run a model training session, a multi-hour test suite, or a borg run refactor on my local machine only to find it hanging at 80% the next morning because the laptop suspended itself. The hardware is capable, but the operating system's priorities are not aligned with keeping a process alive for 6 hours.

A persistent remote shell is a digital twin for your dev environment

A remote Linux VM, whether it's a $5 droplet or a dedicated shell host, has none of those problems. It doesn't sleep. The CPU stays at a consistent speed. The network is on a wired backbone, and the machine is up 24/7. It's not a replacement for your local editor; it's a resident shell that acts as your always-on development twin.

When you SSH into a remote box, you're not asking a hypervisor to wake up a laptop. The process is already running. If you attach tmux, you can see the output from 5 hours ago, and the session is still alive. You can disconnect, kill your local terminal, and fly across the country. When you reconnect (using mosh for roaming), you're back where you left off. The state is on the remote machine, not on your local terminal.

This concept is old hat for sysadmins who run screen or tmux on servers, but developers often still treat their laptop as the primary compute node. The shift is treating your remote shell as the ground truth for any task that takes longer than a few minutes.

The AI agent case: why I now run the agent on a remote shell

AI coding agents like borg (the terminal agent my company, xShellz, builds) can run large-scale refactors, analyze entire codebases, or generate test suites for hours. They open multiple files, make tree-wide edits, and might need to stay in a loop until they're satisfied. The agent's process is not a quick edit; it's a long-running conversation with a codebase.

I fired up borg on a remote xShellz VM and gave it the same refactoring task that failed on my laptop. The command was simple:

ssh user@box tmux attach -t borg-session

Inside the tmux session, I ran borg run refactor --target src/. Then I detached, closed my laptop, and went to bed. The next morning, I reattached and saw the session had completed without a single interruption. The CPU was never throttled, the network never dropped, and the agent never got stuck waiting for a retry. The output was waiting for me, exactly as if I had stayed up all night.

This isn't magic. It's just a machine that never naps. The agent ran on a dedicated Linux host with a stable clock and persistent I/O. The same pattern works for any long-running tool: a nightly integration test suite, a data pipeline that takes 3 hours, or a compression job that crunches a multi-gigabyte log file.

The cost is pocket change, the habit is what matters

A remote shell costs a few dollars a month. An xShellz shell comes with tmux persistence, mosh, and borg pre-installed, but you can replicate the pattern with any Linux VPS. The real investment is building the habit: whenever you're about to start something that will run for more than 15 minutes, ask yourself if it should run on your laptop or on your resident shell. If the answer is the latter, ssh into the box, start a tmux session, and run the command there. Detach, and let the remote machine do the work.

This habit saves you from babysitting a process, and it saves you from the frustration of waking up to a dead run. You stop caring about your laptop's battery, sleep timers, and Wi-Fi flakiness for dev tasks.

Setting up your own always-on loop

If you have a Linux host already, you just need tmux and mosh. On the remote machine:

apt install tmux mosh

Then, from your local terminal:

mosh user@remote tmux new -s build
# Inside the tmux session, run your long command

Detach with Ctrl-b d. Reattach later with mosh user@remote tmux attach -t build. If you're on a flaky connection, mosh keeps the session responsive even when you switch networks. The session stays alive on the remote host regardless of what happens to your local machine.

For AI coding agents, you can install the agent inside that remote shell and keep it running in a dedicated tmux window. You can even script the startup so that a single SSH command reconnects you to the agent's session.

Local still has its place

I'm not arguing you should throw away your local editor. Local development is snappy and works offline. You still want your IDE, your git, and your fast feedback loop on your laptop. But there's no reason to run long builds, large test suites, or AI agents that need to run for hours on the same hardware that you're carrying around in a coffee shop. Offload the heavy lifting to a remote shell that never sleeps, and treat your laptop as the thin client that orchestrates it.

This shift is small, but it eliminates an entire class of developer frustration. Your laptop becomes a portal, not a prison. The remote shell becomes the workhorse that keeps running while you're asleep, on a plane, or just not thinking about it.