# 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](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:

- 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](https://herdr.dev/tui/docs/concepts/). 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,[^bg] 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_

[^bg]:
    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.