Your AI should be working while you sleep

First, see where the time actually goes

A round of work with a CLI agent almost always has the same rhythm:

You talk for 30 seconds → it runs for 5–20 minutes → it needs you to decide something → repeat

Lay a whole day out in those proportions and typing turns out not to be what eats the time. Those 30 seconds are the shortest part of the whole thing. Everything after is waiting — while it reads the project, while it edits a dozen files, while the tests run. Then it stops to ask whether it should handle this migration while it is here. You answer in one line. Another five minutes, another twenty.

By the end of the day you might have produced ten minutes of input and lost several hours. Those hours were not work. They were standby. You did nothing, and you could not leave, because at any moment it needed one sentence from you.

The usual setup nails standby to one laptop

In the default arrangement that standby has a physical location. The agent runs in a terminal window on your laptop. The window is tied to the shell, the shell to that one machine staying awake. Two options follow:

Sit and wait. Stay in the chair, watching a screen where nothing happens, so that you can answer within thirty seconds when it asks. An hour of your time buys three replies.

Or close the laptop. The process suspends or dies, the session goes, and everything the agent had built up goes with it — which files it read, how far it got, why it chose this approach. Come back later and you open a new one, explain it all again, start from the top.

Both options pay the same bill. The work is not what ties you down. The location of that machine is.

Three pieces, each undoing one tie

The tie is not one solid thing. It is three layers, and each has a standard tool, decades old, that takes it apart. On their own all three are unremarkable. Stacked, they are the whole trick:

The order matters. The CLI comes first: only then can the agent leave your laptop for the Mac mini at home that never gets switched off. tmux next, so the session is pinned to that machine and keeps running when your connection drops. SSH and Tailscale last, so you can reattach to that same session from the train, the office, someone else's Wi-Fi — without opening one outward port on your router.

Drop any one and it falls apart. CLI without tmux: the agent dies on disconnect. tmux without a secure way in: you can only use it at home.

The result: standby costs almost nothing

With all three layers gone, standby costs a phone and fifteen seconds instead of a laptop and a fixed location.

Fifteen seconds changes what the activity is. You stop setting aside time to babysit it. You glance at it in a queue, at a crossing, before bed, reply "use the second approach", and put the phone away. The agent keeps going. You get on with your day.

And once standby stops requiring you, the work moves into the hours you were never going to be there anyway. Hand it a refactor and go to dinner. Start a test-fixing session before bed, read the results over breakfast. That machine sat idle every night until now.

What about the other approaches?

There is more than one road to reaching your own agent remotely. Line them up against the same criteria and the differences show — particularly the last column, which is where people find out they are stuck, usually too late.

That last column is the watershed. An agent in someone else's cloud sandbox edits a copy, always. Your .env is not there. Neither is the internal package you installed this morning, or the database that only runs locally. Take the SSH and tmux road and the agent sits on your machine, in your environment, editing your files. The only thing that changed is that your phone is watching it.