Try Turborg Free → Open App →
← All posts

I killed three long-running ML runs this week. My laptop wasn't the problem. It was my habit.

July 12, 2026 · 6 min read · The xShellz Team

I killed three long-running ML runs this week. My laptop wasn't the problem. It was my habit.

Last Tuesday, I lost a 6-hour ffmpeg transcode when my laptop decided 35% battery meant the next 10 seconds were a great time to hard-power-off. Wednesday, a kernel update forced a reboot and took down a half-finished pg_restore. Thursday, I closed the lid to walk across the office and a long-running model evaluation simply vanished because the machine went to sleep. None of this was the laptop's fault. It was the quiet assumption that my local terminal could be trusted to stay alive.

Local development environments are, by default, brittle. The process you leave running in a terminal tab has no persistence, no resilience, and no survival instinct. It dies when you close the lid, when your WiFi hiccups, when the OS decides it's patch Tuesday, or when Docker decides 14 GB of memory is too much to ask. We accept this fragility because it's the default, but once you've had a persistent remote shell, it's hard to go back.

The problem is not your tools, it's the lifetime

tmux and screen exist. They let you detach sessions and reconnect later. That's great for SSH sessions to a remote box that stays on, but if the remote box is your laptop, the session is still tied to the hardware. The laptop goes to sleep, the kernel panics, the battery gives up, and the tmux server is gone. Detach doesn't help when the machine itself detaches from existence.

The core issue: local development ties process lifetime to a single user session on a single piece of consumer hardware. Long builds, training runs, large file operations, and any task that takes more than a few hours becomes a bet on the stability of an environment never designed for continuous uptime.

What an always-on shell actually changes

A managed remote shell (not just a VPS you configured on a Tuesday and forgot) flips the model. The shell is always alive. When you close your laptop at the end of the day, processes keep running. When you open it the next morning, you reattach and everything is exactly where you left it. The machine hosting your shell is monitored, has redundant power, and gets updated without rebooting into your face at 2 AM.

Concretely, you can start a large import before dinner, disconnect, and check on it from your phone later. You can kick off a model training run, go to sleep, and wake up to results rather than a dead terminal. That's not a luxury. It's the difference between babysitting a command and trusting infrastructure.

AI agents make this more than a comfort feature

If an always-on shell is a convenience for manual work, it becomes a necessity when you're running an AI coding agent. Agents like xShellz's borg, or terminal-based coding assistants, can process multi-step tasks, iterate on code, and execute commands over long windows. They do not care about your sleep schedule. If your agent is running inside a local terminal that dies when your laptop goes to sleep, you've capped its value at however long you're willing to keep the screen awake.

With a persistent remote environment, the agent can run overnight, work through a queue of tasks, and deliver finished results by the time you pour your first coffee. You come back to a green test suite and a PR description, not a kernel panic message. That shift changes the agent from a real-time pair programmer into a background worker that respects your time.

The single point of failure you stop thinking about

Once you've worked this way for a few weeks, a local terminal starts to feel dangerous. Your brain begins to associate the closing of a laptop lid with the destruction of state. You notice how often you were mentally managing process lifetimes: "I can't reboot now, that import is 80% done," or "I have to keep this window in the foreground or the OS will suspend it." That cognitive load disappears when you just don't care what your local machine does.

A remote shell also removes the WiFi dependency from inside the process. You can issue a command from a spotty coffee shop connection, and if the SSH session drops, the command keeps running on the remote host. You reconnect and pick up where you left off, no damage done.

How to start, without over-engineering

You don't need a Kubernetes cluster. A single persistent shell goes a long way.

  1. Provision a reliable remote Linux host. Something that stays on. A managed shell service handles this for you (yes, xShellz does exactly that, but any always-on Linux box you trust works).
  2. Work inside tmux or screen on that host. Even if the host never reboots, it protects you from accidental SSH disconnects. tmux new -s work becomes your default entry point.
  3. Keep your development tools there. Clone repos, install runtimes, set up your dotfiles. The environment is no longer tied to a device.
  4. Run your AI agent in that session. If you're using a terminal agent like borg, keep it alive. If it's an LSP or background process, let it run without you.

Example: start a long-running task and deliberately disconnect to test survival.

# On the remote host inside tmux
pg_restore -d mydb massive_backup.dump
# Detach: Ctrl+b d
# Close terminal, go for a walk, come back
ssh user@host
tmux attach -t work
# pg_restore still humming, no data lost

The same pattern works for model fine-tuning, video encoding, large test suites, and anything that doesn't fit in a coffee break.

The quiet win: reproducibility and state

A persistent environment also means you stop rebuilding context. Every developer has a "works on my machine" story. An always-on remote shell becomes the machine. Whether you connect from a desktop, a laptop, or a tablet, you get the same filesystem, the same running processes, the same shell history. Your AI agent sees the same state at 3 PM and 3 AM. That consistency eliminates a class of environment drift bugs that are hard to diagnose and even harder to reproduce.

When your local machine dies, nothing of value dies with it. That's a stronger promise than any backup script can make for your active work.

The end of the "don't close your laptop" era

For developers who still think of their terminal as something that lives on their own hardware, losing a few hours of work to a dead battery or a forced reboot is just a part of the job. It doesn't have to be. Persistent remote shells are not just about saving time. They remove a silent, grinding tax on focus that you don't fully appreciate until it's gone. The next time you start a command that will take longer than your next coffee, ask yourself if you trust your laptop lid. If the answer is no, there is a simple fix.