Herdr, Hermes and a VPS: My Agents Keep Working Without My Mac

▶️ Watch the full video

I often work on several products in parallel. Each project accumulates terminals, branches, tests, and multiple Claude Code or Codex sessions. Two tabs are manageable. Once the number of agents grows, I waste time finding the one waiting for an answer, the one that finished, and the one still running.

I separated two problems I had been treating as one: organizing sessions and running the work on a machine that stays available. Herdr handles the first problem. A VPS handles the second. Hermes gives me a remote way to request status, make a decision, and step back in when needed.

Why terminal splits stop being enough

Ghostty, tmux, and pane-based terminals are still useful. I still use them. The problem starts when the screen becomes a stack of contexts that are hard to read.

With several active projects, I need quick answers to four questions:

which agent is working in which repository and branch;
which session is waiting for a human decision;
which tests actually passed;
where the conversation and diff are, without rebuilding the context.

One more pane displays one more process. It does not automatically turn a fleet of terminals into a readable system.

Herdr organizes sessions without replacing the agents

Herdr is a terminal runtime built for multi-agent work. It organizes sessions at three levels: workspace, tab, and pane. In my setup, a workspace maps to a project or objective, a tab groups one part of the work, and each pane contains a real terminal.

Claude Code, Codex, and shells still execute the tasks. Herdr does not replace them. It provides the cockpit for seeing sessions, moving between them, and spotting the ones that appear to be working, waiting, or finished.

Element	Role	Example
Workspace	Isolate a project or objective	API, frontend, or bounded fix
Tab	Group a phase of work	Implementation, tests, review
Pane	Host a real terminal	Claude Code, Codex, test shell
Visible state	Direct attention	Blocked agent or idle session

A done state is not proof of quality. I still inspect the diff, tests, and functional result. The cockpit reduces search time; it does not replace review.

The execution machine changes the outcome

An agent launched on my Mac runs on my Mac, even when it calls a remote model. If the machine sleeps, local work is suspended. If it shuts down, the process stops. A persistent session such as tmux can survive the client closing, but it cannot make a sleeping computer continue working.

Moving the setup to a VPS places the repositories, agents, tests, and session server on a remote machine that stays available. My Mac becomes a client. I can disconnect and later return to the same sessions from another authorized machine.

Setup	Where do processes run?	What happens when the laptop disconnects?
Local terminal	On the laptop	The result depends on the laptop state
Local tmux	On the laptop	The session survives the client, not machine sleep
Herdr on a VPS	On the VPS	Remote sessions remain on the server

This move also creates obligations: dependencies must be installed on the VPS, secrets must be limited to what the task needs, and local files do not synchronize by themselves.

My Herdr, Hermes, and VPS workflow

I keep the sequence straightforward:

I define two independent tasks and their acceptance criteria.
I create separate branches or worktrees when agents write in parallel.
I launch Claude Code and Codex in identifiable panes.
Before leaving, I record the session, branch, current output, and expected tests.
From my phone, I ask Hermes for session status and the latest useful output.
If an agent raises a product question, the loop stops and I decide.
When I return, I reopen the same cockpit, inspect the diffs, and rerun the tests.

The phone does not become an IDE. Telegram and Hermes are useful for status checks and short decisions. I return to the terminal to read code, resume a conversation, or correct an implementation.

What this setup proves, and what it does not

The demonstration shows that a remote process can continue after the laptop disconnects and that I can return to its sessions. It does not prove that an agent will remain productive all night.

An agent may stop because:

the task is complete;
a question requires human judgment;
a quota or budget has been reached;
a test fails without a safe correction;
the VPS runs short of RAM, CPU, or disk space;
a dependency or external service becomes unavailable.

Machine availability is only one condition. Useful autonomy also depends on bounded tasks, acceptance criteria, tests, minimum permissions, and a clear rule for requesting help.

The controls I keep

I do not give a remote agent unlimited access merely because it must run while I am away. I separate worktrees, limit credentials, prevent automatic merges for sensitive changes, and keep deployment under human approval.

Before leaving a task running, I check:

the exact repository and branch scope;
the expected test commands;
forbidden actions, especially merge and deployment;
how the agent must report a blocker;
the rollback path if the result is wrong.

The main benefit is continuity. I return to the agents, their conversations, and the evidence I need to check without asking a new session to reconstruct the work.

▶️ Watch the Herdr + Hermes + VPS setup

For more practical AI and agentic development workflows, join The Agentic Dev.