Herdr and the Meta-harness

Herdr, an open-source "terminal workspace manager" from herdrdev, gives developers programmatic access to coding-agent session management, letting tools script over sessions that persist independently of SSH connections. The author, who built a "meta-harness" UI on top of Herdr to track sessions, outbound pull requests and inbound PR reviews, argues developers should treat each agent session as "cattle" rather than a "pet" and keep flexibility to switch between harnesses such as Claude Code, Codex and Pi. Herdr wraps existing TUI harnesses more efficiently but does not improve on their quirks, including viewing subagents, opening reasoning traces and background commands.

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 https://news.ycombinator.com/item?id=50410853 : 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 https://github.com/herdrdev/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 https://herdr.dev/tui/docs/concepts/ ”. 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: 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,<sup 1 fn:1 </sup 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: Cover: Arches National Park Most of the harnesses allow you to have it run commands in the background for you, and the TUI view of this is a little bit clunky – from what I’ve seen, and from what I’ve heard people complaining about. ↩︎ fnref:1