herdr vs Orca: Your Terminal Workflow Decides Your ADE

Why I'm Sticking with herdr Over Orca

Every developer is facing the same new question: how do you connect, optimize, and orchestrate a pile of local coding agents? We used to solve dev environment setup with VS Code extensions, LSP, and dotfiles. Now the question has become "how do I manage a fleet of AI coding agents". As a Vim/Neovim user, I picked herdr a few weeks ago as my ADE (Agent Development Environment). Then a new competitor, Orca, showed up, and I gave it a fair try. The conclusion: I'm sticking with herdr.

ADE (Agent Development Environment) is the core concept of this article. With coding agents like Claude Code, Codex, and Gemini CLI proliferating, developers are no longer facing a single-tool configuration problem — they're facing a runtime environment question of how to launch, monitor, and coordinate multiple agents at once. Traditional IDEs (Integrated Development Environments) are designed around humans writing code; ADEs are designed around agents writing code, emphasizing pane management, state visibility, inter-agent messaging, and lifecycle control. herdr and Orca both belong to this category: the former is a terminal-native ADE, the latter a GUI-first ADE. Understanding this makes it clear why the author keeps emphasizing "can an agent orchestrate other agents" rather than simply comparing keybindings or interface polish.

Orca Is Genuinely Good, But It's Not My Terminal

Let me give credit where it's due. Orca's GUI is beautifully polished. At a glance you can see Claude and Codex usage, rate limit reset times, worktree features are front and center, and you can fan a single prompt out to multiple agents with per-line annotations on AI-generated diffs. These are all great features.

But I live in the terminal — Neovim, tmux, CLI are my home. Even if Orca's GUI tries hard to mimic the terminal feel, it ultimately isn't my terminal, and switching to a standalone app always feels off.

How herdr Fits My Workflow

It runs in the terminal I already have. herdr is a single Rust binary, no Electron. It runs alongside Neovim in my terminal, using my fonts, theme, and keybindings.

Zero learning curve migrating from tmux. Prefix key, splits, ctrl+b q to detach — muscle memory works on day one. You can click with the mouse too if you want.

Agents can drive it, not just me. This is the key. herdr exposes a CLI that agents can use to spawn panes, prompt each other, wait for another agent to finish, or block. My main Claude Code session automatically routes mechanical work to Codex based on routing rules in CLAUDE.md:

| long-running or needs supervision | gpt-5.5 | herdr pane — see "herdr delegation" |

### herdr delegation
- Prompt with `herdr agent prompt <name> "…" --wait`. Never sleep/poll.
- `blocked` = approval/question UI → show me what it's asking; don't approve it yourself.

Claude opens a Codex pane, waits on its state (no polling, no wasted tokens), and when Codex hits an approval prompt, it stops and asks me. In the screenshot below, the Codex pane was opened by Claude.

I always know which agent is stuck. Every pane is labeled working, blocked, or idle. herdr notifies me when it needs me (I even set a custom sound for Codex).

Closing the window doesn't kill the work. Sessions run on a background server, so I can detach, close the laptop, or drop SSH and everything keeps running. Just reconnect with herdr.

My entire config is one TOML file. It lives in my dotfiles, and migrating from Mac to Linux or SSHing into a remote machine is seamless. Same keybindings, same popups, same everything.

It doesn't care which agent I use. Claude Code, Codex, Gemini, Cursor, OpenCode, and more — herdr doesn't wrap them, it just owns their terminal.

worktree is a Git feature that allows the same repository to have multiple working directories checked out simultaneously, each on an independent branch, sharing the underlying .git object store. In the ADE context, worktrees let multiple agents modify different copies of the same project in parallel without overwriting each other's files or hitting lock conflicts. Orca puts worktrees front and center; herdr's fan-out skill uses scripts to automatically create a worktree per agent and reclaim it on completion. Without worktrees, multi-agent parallelism degenerates into fighting over files in the same directory, and conflicts and overwrites are nearly unavoidable. So any ADE claiming to support multi-agent parallel development has to seriously handle worktree creation, naming, and cleanup.

Borrowing Orca's Best Ideas

Trying Orca wasn't a waste of time. I ported its good ideas over to herdr.

Fan-out. One prompt, multiple agents, each running in its own git worktree, then compare and merge the winner. In herdr this is a Claude Code skill: create worktrees, start agents with herdr agent start, prompt them in parallel, run tests on each, and finally give me a comparison table. Nothing gets merged without my approval.

/fanout "add retry with backoff to the S3 uploader" --agents codex,codex,opus

Diff review. Orca's annotated diff feature is superb. My version is a small script bound to a herdr popup. It opens the diff in Neovim, I add #! comments under the lines I care about, and on save they get sent to the agent of my choice with file and line references.

[[keys.command]]
key = "prefix+alt+r"
type = "popup"
command = "herdr-review"
width = "90%"
height = "90%"

I use the same popup trick for gh dash and lazygit, so PRs and diffs are one keybinding away without leaving the terminal.

Mobile notifications. Doable via hooks and a push service, but honestly I don't want it. When I leave my desk, I want to be gone and disconnected. Checking agents from my phone isn't a feature I miss.

Design Mode. Clicking a UI element to send its HTML and CSS to an agent is clever. I don't do frontend work these days, but I'll definitely use it in the future — and browser MCP can fill the gap if needed.

MCP (Model Context Protocol) is a protocol that lets AI models access external tools and data sources through standardized interfaces. In the browser context, browser MCP lets an agent read the current page's DOM, take screenshots, or perform clicks, enabling tasks like frontend debugging and UI review. When the author says "browser MCP can fill the gap if needed," the point is that although herdr doesn't have Orca's built-in Design Mode "click a UI element to send HTML/CSS to an agent," the MCP ecosystem can supply similar capabilities. This reflects herdr's philosophy: don't bake every feature into the core — keep a thin terminal layer and let agents extend themselves through generic interfaces like CLI and MCP. For developers who want to customize their workflows, this composability often has more long-term value than built-in features.

Which One Should You Pick?

If you like GUIs, want everything built in, and prefer to guide agents manually, Orca is a great choice.

If you live in the terminal, want agents to be able to orchestrate other agents, and like owning your environment through config files, herdr is hard to beat. Anything it doesn't ship with, you can build in an afternoon.

For me, the deciding question was simple: do I want a new app, or a better terminal? I chose a better terminal.

What's your ADE setup? I'd love to hear what works for you.