My Laptop Went to Sleep. It Cost Me an Afternoon of AI Coding.

The progress bar had been ticking for 43 minutes. My terminal-based coding agent was mid-refactor, applying a chain of 17 patches across a dozen files, running tests between each step. I got up to grab coffee and, without thinking, closed the MacBook lid. When I lifted it 15 minutes later, the Wi-Fi had dropped while asleep. SSH was dead. The agent process was gone. Half a day of context evaporated. That afternoon taught me a hard lesson: local machines are the weakest link in the AI developer loop.

The fragile local machine

Modern AI coding assistants (Claude Code, Copilot Workspace, Codex CLI, and xShellz's own Borg) are fundamentally different from traditional tooling. They do not just answer one-shot prompts. They run long-running chains: read a whole codebase, plan a refactor, apply edits in stages, run the test suite, iterate on failures, and produce a pull request. A session might span 10 minutes or 4 hours. Along the way, the agent holds a rich context window that is expensive to rebuild. If your connection breaks, the entire chain is lost. You do not just lose the last line of output. You lose the agent's state, its internal reasoning trace, and the compute you already paid for.

Local machines are built for human interaction cycles, not for background persistence. Laptops go to sleep when you close the lid or walk away. Wi-Fi reconnects after waking, killing SSH sessions. Battery saver modes can throttle CPU or suspend processes. Desktop workstations are slightly better but still reboot for OS updates, or lose power during a storm. If you run your agent directly on your local terminal, every one of those events is a landmine.

I did some napkin math after that ruined afternoon. Over a month, I was losing roughly 2 hours of agent work to sleep, network jitter, and an accidental sudo reboot on the wrong machine. That is not just annoying. It is wasted compute and a constant mental tax: Am I going to lose my context if I step away for lunch?

Persistent shells to the rescue

The fix is not a smarter laptop. It is moving the agent off your ephemeral local machine and onto something that stays on, no matter what your laptop does. A remote Linux host with a persistent shell session. The concept is old-school: tmux (or screen) inside an SSH session. But applied to AI agents, it flips the reliability model.

Instead of running the agent on your local laptop, you SSH into a remote box (a $5 VPS, a home server, or a managed shell service). You start a named tmux session, launch the agent inside it, and detach. Now your laptop can sleep, lose Wi-Fi, even die completely, and the agent keeps running on the remote host. You can reattach from any machine, any time, and pick up exactly where you left off. The agent's context remains alive.

I first tried this with a $5 VPS and tmux. I would ssh vps, tmux new -s refactor, start my agent, hit Ctrl-b d. The next morning I could tmux attach -t refactor from my iPad over cellular and see the agent had finished its chain and was waiting for me to review a PR. No progress was lost. My local machine became just a thin client.

A practical setup in 60 seconds

Here is exactly what I run today. You can replicate it with any Linux host and an SSH key.

# 1. SSH into your remote host
ssh user@remote

# 2. Start (or reattach) a tmux session with an explicit name
tmux new -s agent

# 3. Inside the tmux session, launch your agent
borg refine --path ~/code/project --scope "simplify error handling"

# 4. Detach without killing the process
#    Default prefix: Ctrl-b, then d

# 5. Reattach from anywhere, even if your local SSH died
tmux attach -t agent

If you need to survive a remote host reboot, you can go a step further: wrap the agent in a systemd user service, or use tmux-resurrect to restore panes and programs after a restart. For most day-to-day work, however, plain tmux is enough. The remote server stays up. Your agent stays up.

Why this changes the game for AI agents

Running agents remotely is not just about avoiding disasters. It changes how you interact with the tool. You can kick off a large code review at the end of the day, attach the next morning, and find a completed analysis waiting. You can start an agent on one device, commute, and resume on another. The agent's “working memory” survives your laptop's battery dying in a meeting.

It also lets you run multiple agents in parallel without fighting for local CPU or RAM. You could have one tmux session experimenting with a new library and another session running a full test suite against a candidate branch. Both keep running even if you close every local terminal window.

Some services bake this directly into the product. xShellz, for example, gives you an always-on remote shell that survives whatever your local machine does. Borg, their native AI terminal agent, runs inside that shell. No tmux required if you do not want it. You ssh in, start Borg, and disconnect. Borg keeps working. When you reconnect, the conversation and context are exactly where you left them. Even if you do not use their agent, the same principle applies to any terminal-based assistant you run remotely.

What about the downsides?

Latency: typing feels a tiny bit softer, but for text terminals, 30 ms of round-trip time is imperceptible during an edit-compile loop. Over a cellular connection you might notice it, yet it is still vastly better than redoing 3 hours of work.

Cost: a modest VPS costs less than the GPU time you waste reconstructing context after a crash. Even a small instance with 1 vCPU and 1 GB of RAM handles most terminal agents comfortably. For heavier work, you can scale up to a compute-optimized instance.

Security: your code and prompts live on a remote host. You already trust that host with your code if you push to it anyway. Use key-only SSH, fail2ban, and keep the system patched. The risk is not fundamentally different from running a CI runner or a staging server.

The always-on future

AI coding agents are moving from quick Q&A to sustained background work. That shift breaks the model where your primary development device also hosts the agent process. A MacBook that goes to sleep in your bag is a terrible home for an agent that needs to iterate for hours without interruption.

Moving the agent to a persistent remote shell is a small operational change that pays back immediately. You stop babysitting progress bars. You stop losing context. And you gain the freedom to let the agent work while you do something else, somewhere else.

If you have not tried it yet, spin up the cheapest Linux box you can find, install your favorite agent, wrap it in tmux, and walk away from your laptop. You will not go back.