Omar: TUI Orchestration for 100-Agent Coding Swarms

Managing one coding agent is a chat interface. Managing 100 coding agents is an infrastructure problem. Omar is a terminal UI that treats agent swarms like organizational hierarchies, with task delegation, heterogeneous backends, and session persistence. The constraint is deliberate: when you cannot rely on rich browser UIs, you expose what actually matters for swarm control.

The Problem Space

Most agent frameworks assume you are orchestrating a handful of agents with distinct roles. When agent count exceeds human attention span, three problems surface:

State visibility: You need to know which agents are idle, working, blocked, or failed without polling 100 endpoints.
Task routing: Work must flow to agents with the right capabilities, rate limits, or context without manual assignment.
Failure isolation: One agent crashing or hallucinating cannot cascade through the entire swarm.

Omar’s answer is to model agents as a company org chart. Agents manage other agents. The executive assistant at the root delegates to department heads, who delegate to specialists. The TUI renders this hierarchy in real time.

Architecture

Omar sits on top of tmux, treating each agent as a persistent tmux pane. The orchestration layer is a Rust binary that manages:

Hierarchy state: A tree of agent nodes, each with a backend (Claude Code, Codex CLI, Opencode, Cursor CLI), task queue, and lifecycle.
Message bus: Agents communicate via a pub/sub channel. Parent agents subscribe to child events.
Session snapshots: The entire hierarchy serializes to disk. You can kill the TUI and resume later without losing context.

The TUI itself is a viewport into this tree. Arrow keys navigate the hierarchy. Popup windows let you attach to any agent’s terminal, inject prompts, or inspect logs.

Backend Heterogeneity

Omar does not enforce a single LLM. Each agent node specifies a backend:

Claude Code for reasoning-heavy tasks.
Codex CLI for fast autocomplete-style edits.
Opencode for open-source model experiments.
Cursor CLI for IDE-integrated workflows.

The parent agent decides which backend to spawn based on task type. You configure routing rules in a YAML file or let the executive assistant agent choose dynamically based on task characteristics.

State Representation in a TUI

A terminal interface has roughly 80x24 characters. Omar uses a split-pane layout:

Pane	Content	Update Frequency
Hierarchy	Tree view of all agents, color-coded status	Continuous
Task Queue	Pending work for selected agent	Event-driven
Agent Output	Streaming stdout/stderr from active agent	Continuous
Control Panel	Keybindings, session info, error summary	Static

The hierarchy pane is the critical piece. Each agent node shows:

Name and backend type.
Status icon (idle, working, blocked, failed).
Child count and depth.
Last activity timestamp.

Color coding is semantic: green for idle, yellow for working, red for failed, gray for blocked. This lets you scan 100 agents in under a second.

Task Routing Primitives

Omar provides three routing mechanisms:

Direct assignment: You select an agent and paste a prompt. That agent executes it.
Delegation: An agent can spawn child agents and assign subtasks. The parent monitors child status and aggregates results.
Broadcast: A parent sends the same task to all children. First success wins, or results merge.

Delegation is the default. The executive assistant agent receives your high-level goal, breaks it into subtasks, and spawns specialists. Each specialist can further delegate.

Example: Refactoring a Monorepo

You give the EA: “Refactor all API routes to use async/await.”

The EA spawns:

A scanner agent (Codex CLI) to list all route files.
A planner agent (Claude Code) to generate refactoring steps per file.
N executor agents (Cursor CLI) to apply changes in parallel.

The planner agent spawns one executor per file. Executors report success or failure back to the planner. The planner aggregates results and reports to the EA. The EA surfaces a summary to you.

The delegation logic lives in prompt templates or emerges from the EA’s reasoning about task decomposition.

Failure Modes and Isolation

When an agent fails, Omar does not retry automatically. The parent agent decides:

Retry with same backend: Useful for transient API errors.
Retry with different backend: If Claude Code times out, try Codex CLI.
Escalate to human: Surface the failure in the TUI and wait for input.
Abort subtree: Kill the failed agent and all its children.

Failures are isolated by hierarchy. If an executor agent halts, only its siblings and parent are affected. The rest of the swarm continues.

The TUI surfaces failures in two places:

The hierarchy pane marks the failed node in red.
The control panel shows a failure count and last error message.

You can attach to the failed agent’s pane to inspect logs or inject a corrective prompt.

Session Persistence

Omar persists the entire agent tree to disk periodically. The snapshot includes:

Agent hierarchy and backend assignments.
Task queues and completion status.
Tmux session IDs and pane mappings.

When you restart Omar, it rehydrates the tree and reattaches to existing tmux panes. Agents that were mid-task resume from their last checkpoint (if the backend supports it). This is critical for long-running refactors or multi-hour builds.

Spawning a Child Agent

The core pattern for agent delegation follows a registry model. When a parent agent spawns a child:

A new tmux pane is created within the parent’s session.
The child node is initialized with its backend, task queue, and status.
The child is registered globally so other agents can reference it.
The parent adds the child’s ID to its own children list.

This approach keeps the hierarchy navigable while allowing agents to operate independently. The tmux layer provides process isolation, while the registry maintains logical relationships.

Observability Hooks

Omar exposes three observability primitives:

Event stream: A JSON log of all agent state transitions (spawned, task_started, task_completed, failed). You can tail this with jq or ship it to a log aggregator.
Metrics endpoint: A local HTTP server (disabled by default) that exposes Prometheus metrics: agent count, task throughput, failure rate, backend distribution.
Integration hooks: Agents can trigger external notifications or webhooks when subtrees complete or require human input.

The event stream is the most useful. It gives you a complete audit trail of what every agent did, when, and why.

Deployment Shape

Omar runs on a single machine. It does not distribute agents across nodes. The limiting factor is tmux’s ability to manage hundreds of panes, which caps out around 200-300 depending on terminal emulator and shell overhead.

For larger swarms, you run multiple Omar instances and manually partition work. There is no built-in cluster mode. Typical deployments use a dedicated Linux or macOS machine with at least 16GB RAM and a modern multi-core CPU to handle concurrent agent processes. Tmux 3.0+ is required for the session management features Omar relies on.

When to Use Omar

You are orchestrating 20+ coding agents and need real-time visibility into their state.
You want to mix different LLM backends in a single workflow.
You need session persistence across restarts or crashes.
You are comfortable with terminal UIs and tmux keybindings.

When to Avoid Omar

You need web-based dashboards or team collaboration features.
You want automatic task decomposition without writing delegation logic.
You are orchestrating agents across multiple machines.
You need sub-second latency for agent spawning (tmux pane creation introduces measurable overhead).

Technical Verdict

Omar solves the observability problem for agent swarms by constraining the interface. A TUI forces you to decide what state actually matters, which surfaces the right primitives: hierarchy, status, task queues, and failure isolation. The tmux foundation is both a strength (proven session management) and a limit (single-machine, pane overhead). Use it when you need to manage dozens of agents from a terminal and are willing to write delegation logic. Avoid it if you need distributed orchestration or prefer graphical interfaces.