AI agent interface

The layer between you and your coding agents—how you launch, monitor, and talk to Claude Code, OpenAI Codex, and others. The options range from each harness’s own TUI to terminal multiplexers to dedicated multi-agent apps. This page compares the ones I’ve tried; my current setup lives in an ever-evolving page How I Use Them.

Harness-native interfaces#

The default is whatever the harness ships. Claude Code is a terminal TUI, also available as a desktop app, a web app, and IDE extensions. OpenAI Codex has the codex TUI and a polished app.

To me, Claude Code is much more pleasant to use as a TUI and the app doesn’t quite work well enough to use. On the Codex side, both TUI and native app are pretty good, but native app has many convenient features so I generally stick to the native app.

In comparing Claude Code and Codex, the keyword that makes Codex pleasant to use is “seamless”. Codex’s interface makes it easy to forget about the remaining context, compaction, and other details. But Claude Code interface nudges you more about these details.

The Codex app makes it very easy to create scheduled tasks (regularly run prompts like /loop in Claude Code). It also has a very good integration with mobile app (although it’s annoying to navigate to the Codex thread from the default ChatGPT interface). Claude Code has remote control, but it is not as seamless as Codex.

One small feature that actually annoys me quite a lot: control over when a follow-up prompt is injected. The Codex app lets you choose—send it now, or queue it for the agent’s next turn. In the Claude Code TUI you can’t predict when a typed prompt will land.

The terminal itself#

If the interface is a TUI, the terminal emulator underneath matters more than it seems. I use Ghostty—Mitchell Hashimoto’s GPU-accelerated terminal, written in Zig with platform-native UI—almost entirely because of its speed. Speed is exactly why I gave up on Warp, which has grown into a full “agentic development environment” bundling a terminal with agent orchestration; it does a lot, but it felt slow. Before all this I was a long-time iTerm2 user.

Terminal multiplexers#

If you live in the terminal, the classic answer is tmux or your terminal’s native splits (Ghostty’s ⌘+D/⌘+⇧+D). The property that makes tmux and its descendants so valuable for agent work is detach and reattach: close the window—or lose the connection—and the session lives; the agents keep working, and you reattach whenever you want. Agent-specific tools add state awareness on top:

• Herdr: a terminal multiplexer built for agents: real PTY panes, persistent sessions that survive disconnects, and semantic state (blocked, working, done, idle) across the whole “herd” of agents. Runs local or over SSH, with a CLI and socket API.
• cmux: a native macOS terminal on libghostty with a vertical tab sidebar (one tab per project), agent notifications, and an embedded scriptable browser. Lightweight and similar in spirit to Ghostty + Herdr; I hit memory-leak issues with it. It is not as elegant as Herdr.

Multi-agent apps#

• Paseo: self-hosted and open source. A local daemon spawns the agent processes on your machine and streams them to desktop, web, mobile, or CLI clients; essentially a Codex-app-style interface that works across providers (Claude Code, Codex, OpenCode, Cursor, Pi, …). It has the explicit prompt-queueing control described above.
• Orca: an open-source (MIT) agentic IDE for running agents in parallel, each in an isolated Git worktree (“prompt to merged PR”). Powerful and well made, but the whole model is built around worktrees, which, to me, adds too much complexity that everyday tasks don’t need.

What I use#

My trajectory so far: iTerm2 + tmux → bare Ghostty splits → cmux → Orca → Ghostty + Herdr → Paseo (as of August 2026). Alongside these, I also use the OpenAI Codex app a lot, in combination with its iOS app.

The features that ended up mattering to me: prompt-injection control, notifications and per-agent state, sessions that survive closing the window (tmux-style detach/reattach, whether via Herdr’s persistent sessions or Paseo’s daemon), and staying lightweight—in-place sessions rather than worktree complexity.