You can just install Claude Code on the server and drive it from Claude Desktop via remote control. That way you can control Claude Code on mutiple servers straight from your Claude Desktop, Mobile or Web, and stay fully within Anthropic tools.

Everything works: you get the native view of subagents, you can upload files and images, fork threads, etc.

The massive upside is that the actual work happens on the server so you can close your laptop and it will continue plus it will not fry your thighs. The advantage over sessions (which I haven't tried but theoretically sound) is that you can configure Claude's environment on the server however you like. Give it any tools you need, ssh access to other machines, sudo, whatever.

The only downside is that every new project requires a setup step on the server (to add the systemd service) where you will develop it since Claude can only handle one server per directory. Claude will handle this step however if you give it ssh access to your server.

The machines show up nicely in Claude Desktop/Mobile/Web, and repos/projects are in a dropdown. Unless you work on very many projects at the same time, this setup is golden.

Like others here I created my own terminal multiplexer as well. Daemon that holds all sessions, seamless binary upgrades so those sessions never get lost, everything recorded so recovery is always possible, thin client mode so laptop has a native app that connects to daemon, and a wasm responsive webui with transcription so I can carry on with sessions from phone. Claude/codex sessions started with a uuid so they can be killed/resumed at will (mine autosleep after 12h inactivity to free resouces). CLI allows agent control of everything for a harness independent implementation of claude's channels. A few friends have forked and adopted it as their daily driver. Similar organization to herdr wrt spaces to organize sessions. Optimized for speed/bandwidth when running in thin client mode.

https://github.com/zackham/seance

This website is so hard to read on a 15" retina screen.

The text content occupies like 20% of the screen, the rest is empty. Resizing the window helps.

I created my own “terminal multiplexer for AI agents” after trying out herdr.

For me (like for many others) tmux didn’t suit the multi agent workflow. Herdr then was too buggy in my experience.

My own tool, Jai, connects to multiple machines, handles multiple agents and enables agent to agent communication.

For those interested: https://michael.sinax.be/jai/index.html

I really liked Tmux and Zellij for the time being, but Herdr does it all so much better out of the box when it comes to agentic coding. I haven't found something I can do with tmux/zellij but can't do with herdr.

I work on a GUI multi-agent harness & IDE (claude, codex, opencode,vibe). It has MCP for supervisor agents to delegate tasks and receive feedback.

A nice alternative for ppl who struggle with terminal based solutions. It's a free indie product. https://shikigami.dev <--- more info there

I used to use tmux & Claude on a Mac mini, but I gave it away when herdr came around - there were just too many tmux sessions to maintain and herdr does a better job at showing you what’s open. Admittedly, your tmux setup looks far more sophisticated than what I was doing. However, the new claude code projects is insane and a step above on having claude being a real project manager across sessions.

I've made a terminal that is essentially ghostty + herder, but all natively and has a session persistence. https://thurm.rs

there is an ios application in testflight and web client, nothing is on the servers, using tailscale through clients or you can use classic remote hosts.

I went down this path over 6 months ago and had a variety of custom setups using tmux, cmux, and more. But since using Orca IDE it feels like a leap in usability and robustness.

Been using tmux session to hand over to claude for a while. Paranoid me uses the macbooks secure enclave with fingerprint for the ssh key so claude can't ssh into my remote boxes by himself. I then open named tmux sessions, perform the ssh login via fingerprint, and then tell claude that he is free to take over that session with a given name.

If you are interested in this setup I would recommend https://github.com/asheshgoplani/agent-deck.

tmux is great, specially when you need persistence in a remote server where you don't want or can't install any other software, and when you are stuck with some 2010 terminal emulator.

But if you have control over your setup, I would use a capable terminal and ditch in-band multiplexers that sit in the middle of the process and your terminal eating up escape sequences and native features while adding latency. Then use a separate tool for session persistence (I like zmx but there are more for this).

It's great to manage subagents using the Claude team mode and tmux integration.

tmux and pi is already my preferred way to use LLMs, but the config in the article is sweet. I was wondering why the colors were off...

Sigh, painful AI slop that is wrong on so many things and just an ad for crystl.

I am doing tmux + Claude but I wanted a bit more.

Firstly, I want to sandbox my agents from each other and from my hard-drive, and partition (and encrypt) secrets, so I use (and wrote) byre[0], and run a devbox with long-running agents for certain tasks. TermRover[1] is a pretty good SSH client for tmux. For a more native integration I have started using Happier[2] which provides a web front-end and iOS app for my sessions too (unified with real Claude Code, so handover is seamless), and put together a byre skill[3] to make that easy.

[0]: https://github.com/pjlsergeant/byre-happier-claude

[1]: https://termrover.sh/

[2]: https://happier.dev/

[3]: https://github.com/pjlsergeant/byre-happier-claude

Isn't this the wrong architecture? Fundamentally, a coding agent should be running as a headless/detached process, a daemon. If it needs a CLI then that CLI can attach/connect to that daemon and interact with it. If you architect it that way then you can quit and resume the CLI anytime you want, from any machine you want and with whatever UI you want, the daemon doesn't care. Running the agent as an interactive CLI process which you need to stuff into something like tmux is just the wrong approach, and "connecting" to it by reading/scraping its screen is terrible.