Herdr and the Meta-harness

I see a lot of discussion around “TUI vs. GUI” for coding agents. This discussion is often of the form: “the more I use Claude Code/Codex/Pi, the more I’ve outgrown the TUI and want to use a GUI app”. The comment that nudged me to write this is in this recent HN discussion:

I used to use ChatGPT/Claude in the TUI up until like 3 months ago, but my usage of LLMs has exploded - many sessions across many projects. I feel like I outgrew the TUI and now I’m using ChatGPT/Claude desktop. VS Code has become a code review tool and place where I manage git if need be. […]

Usually a TUI would be open in VS Code and scoped to whatever repo I’m working with so 10 projects, 10 VS Code instances open, not super scalable. With the GUI desktop app it’s one app, and I can start sessions in an repo and switch between them easily, no need to open VS Code for each. I don’t see what could make me want to go back to using a TUI.

I can sympathize with the pull away from TUIs. Until I started using Herdr, I was manually managing sessions in iTerm or Ghostty tabs. It was a nightmare. This didn’t play well with e.g. losing connection to remote hosts if I was using an agent on a box over SSH, it was annoying to keep a mental picture of what each tab was for, and it felt like manual multiplexing instead of truly doing work in parallel.

Herdr describes itself as a “terminal workspace manager”. I think that’s a reasonable description. It’s, in my opinion, agent-native tmux. It keeps your terminal sessions running independent of your SSH, has window/tab/pane management features, and has some agent-native capabilities – like the status of agent sessions – that are what differentiate it from “just” being a terminal manager.

I think Herdr solves most of the friction I felt personally in manual session management.

It handles:

• Remote session resumption. The Herdr server runs persistently, so that if you disconnect from an SSH’d box, the sessions keep running, just like tmux.
• Workspace management. A workspace in Herdr is analogous to a desktop space: it’s a “top-level project container”, per the docs. A workspace can contain a set of tabs, which in turn contain panes.
  • In theory you should have a separate workspace for each repo you work on. However, my company uses a monorepo, and I find the agent list pane sufficient for my use cases such that I use a single workspace, with one pane per tab, and just have a bunch of tabs. My one exception is that I have a separate workspace for some long-running agents, but that’s mostly for tab management.
• Session management. Sessions can be given titles, and each session gets a status indicator (e.g. working, needs your input, complete).

One thing that Herdr does which I’m unaware of other first-party apps doing particularly well is giving you programmatic access to session management. I’ve found it really nice to be able to build tools that script over Herdr. For instance, I have a meta-harness UI that tracks all my work, including sessions, outbound PRs, and inbound PR reviews. I can easily launch sessions programmatically from this UI and they just show up alongside my manually launched sessions.

Herdr notably does not improve on any annoyances of the harnesses themselves, since it’s purely a wrapper for running the TUI harnesses more efficiently. For quirks around e.g. viewing subagents, clicking to open reasoning traces, and background commands,¹ Herdr offers no improvement.

On the TUI vs. GUI debate, I prefer the TUI, but I think the real thing I’m pointing towards is: you want flexibility to switch between harnesses (this is still an unsettled space), and you should also be using a meta-layer above the harness so that each session is treated as “cattle” instead of a “pet”.

The direction the LLM coding space appears to be moving in is one where each engineer is managing more agents, is doing more work, and is farther from the code. The affordances you need as a developer become better tools for managing and overseeing agents. Some of this could come in the form of “have one agent thread be your main point-of-contact, and have that agent manage other agents”. That’s a promising pattern, but we’re not quite at the point where that’s optimal for all agentic coding. I still find a bunch of value in having separate threads and viewing/managing them myself. So, I think the meta-harness pattern fits the niche of how my work is currently shaped.

A few more thoughts on coding agent UX:

1. Using a meta-harness makes it easier to switch between harnesses. I use Claude Code, Codex, and Pi, depending on my use case. Having a layer above each harness makes it way easier to manage all my work. Locking yourself into one of the first-party GUIs adds more switching cost.
2. The cost of hyper-personalized software is ~$0, so if you want an affordance that one of the first-party GUIs offers, you can easily build it yourself in your own UI and “yoink” features you like. 💁‍♂️

Cover: Arches National Park