Your AI should be working while you sleep

Where does the time go?

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 is not what eats it. Those 30 seconds are the shortest part. Everything after them is waiting: it reads the project, it edits a dozen files, the test suite runs. Then it stops to ask whether it should handle that migration while it is already in the code. You answer in one line, then wait another five or twenty minutes.

By the end of the day you have produced maybe ten minutes of typing and lost several hours. Those hours 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

That standby has a physical location. The agent runs in a terminal window on your laptop. The window is tied to a shell, and the shell to one machine that has to stay awake. You then have two options, and neither is cheap:

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 that approach. Come back later and you open a new window, explain the task from the beginning, and start again.

Either option costs the same, and the cause is where that machine sits. The work itself never needed you in the room.

What three tools undo the tie?

The tie has three layers, and each layer has a standard tool that has been around for decades. Any one of them looks ordinary. Stacked in the right order, they do the whole job:

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

Drop any one of the three and it falls apart. CLI without tmux: the agent dies when the connection drops. tmux without a secure way in: you can only use it at home.

Standby costs a phone and fifteen seconds

Once all three are in place, checking in means unlocking your phone for fifteen seconds instead of finding a desk, a seat, and an outlet.

Fifteen seconds changes what the activity is. You stop setting aside a block of 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. When you look again the agent is still working, and it has moved on without you.

Once standby stops requiring you, the work moves into the hours you were never going to spend at a desk anyway. Hand it a refactor and go to dinner. Start a test-fixing session before bed, and read the results over breakfast. The machine that used to sit idle every night is now the one doing the work.

What else reaches your agent when you're away?

You have more than one way to reach your own agent from outside. Line the options up against the same criteria and the differences are plain. The last column is the one that matters: it is where people find out they are stuck.

An agent in someone else's cloud sandbox edits a copy, always. Your .env is not in that sandbox. 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.