I want to offload the task to another CLI, but there's nowhere to offload it to

The result of this stop is tmux-relay: Send commands to available tmux panes, retaining the task, role, completion signal, and result reading path. The tmux pane goes from being "a window I switch to and look at with a mouse" to "a worker that can be called by a program" — that's the unnamed dispatcher from the previous article.

I ended up writing my own because my usage limits were constantly running out—my primary tool was Claude Code, and even though I had subscriptions to several model providers and API access to a few others, it still wasn't enough. The first thought that popped into my head wasn't to switch to a more powerful model, but rather: "Why should all these chores take up the main agent's context?" Back then, the context window was only 200k tokens—the 1M limit came out later—and making the main agent read through a bunch of grep results word by word was just too wasteful.

Around the time Claude Code launched sub-agents, "offloading work" became tangible for the first time, but sub-agents were internal workers within Claude and couldn't be sent to Codex or other CLI tools. After searching around without finding a ready-to-use solution: to dispatch tasks across CLIs, there first needs to be a way to send a task to a genuinely running terminal, and also know when it's done and where the results are.

The workers are up and running, but they can't communicate with each other.

At this stop, we restocked session-channel (covered in the previous article): this lets panes communicate directly with each other, so there's no need to keep feeding every message back into the same conversation.

Once tmux-relay could dispatch tasks, the next problem popped up immediately—once one agent finishes its work, there is no place for it to notify another agent. Claude's Team Agent only passes messages within the same model family, and the work done by Codex cannot be received on Claude's end.

This computer is busy, but the other two are idle.

At this stop, we restocked fleet, assigning tasks based on machine capabilities: Windows with a graphics card handles training or inference workloads like TTS and ASR, the old Intel MacBook only takes on lightweight tasks, and the daily heavy lifting is left to the Mac mini M4.

Once task dispatching and cross-pane communication were both working, the bottleneck wasn't the model anymore, but the hardware—while my local machine was running the agent until it was overheating, those two machines were mostly sitting idle, whereas most multi-agent tools I looked at back then defaulted to running on a single machine.

The definition of "worker" wasn't complete until fleet filled it in—at first I thought of it as just another pane in tmux, but later I realized it can also be another model, another session, or even another computer. The "worker" here is used in a much broader sense than "the layer running cheap models" in the previous post.

Even for the same task, each CLI has a different way of executing it.

At this stop, we restocked cli-rosetta: Consolidate the differences among various CLIs into a single declarative registry, registering ten by August 2026—Claude Code, Codex, Copilot, Antigravity, Qwen Code, Kimi Code, OpenCode, Hermes, Pi, and Grok.

Once the types of workers were complete, the trouble shifted to a new direction: they could be sent out, but when handing the exact same task to Codex versus Copilot, how to launch headless mode, how to specify the model, and what tools were available were all completely different. Every time we switched to a different provider, we had to comb through the documentation all over again.

This cli-rosetta registry was later packaged into a plugin, following the plugin specification of the Codex CLI. The metadata it requires is much more complete than what I originally came up with myself—display name, category, list of capabilities, and default prompts for the user all have to be written out, which effectively forces you to spell out clearly "what on earth this thing can do." Once filled out, the exact same skills and commands could also be installed in Claude Code and Antigravity. This is the first time in these few stops that, instead of inventing my own format, I followed a specification set by someone else, and the effort saved was much greater than expected.

I keep redoing the same task over and over, and I have to do it manually every time.

At this stop, we restocked agentctl: Separate one-off goals from repeatable processes, and add checkpoints, budget caps, permission gates, and an independent judge—this independent judge is there so that "it says it's done" isn't the sole basis for acceptance.

As the number of tasks I assigned increased, the same type of task kept coming up repeatedly, and having to manually go through the process each time started to become inefficient. When I was working on this part, the concept of "workflow" was just beginning to be discussed, but I couldn't find anything that could be applied directly.

I got stuck on this recently, but I found a ready-made solution first.

I didn’t do any work on this one—when I checked in August 2026, there were more ready-made tools available than in the previous four instances, and their solutions were more complete than the version I’d patched together myself, so I decided to borrow some ideas to supplement what I already had.

Claude Squad uses a tmux session combined with a Git worktree to isolate multiple tasks, and uses a TUI to centrally manage and switch between them. Herdr puts multiple coding agents into real terminal panes, determining whether they are blocked, working, done, or idle based on multiple signals such as foreground processes and screen content. Orca puts worktree, agent terminal, diff, and browser all into the scope of a single task to create a complete Agent Development Environment. Anthropic also launched a cloud-based remote mode in 2026, running workloads directly on their machines.

Tasks need isolation, state needs to be visible, and you need to be able to reconnect when stepping away from the computer—Claude Squad, Herdr, and Orca have all solved these issues. There are only a few ways to use agents, and the bottlenecks naturally happen in the same few places; it's just that this time, we got lucky, and by the time we hit a bottleneck, someone had already finished building a solution. Therefore, once you find ready-made tools, the only remaining question is "which ones can be used directly." For general terminal isolation, pane state detection, and remote reconnection, it's more cost-effective to use what others have built rather than rewriting it yourself. As for the remaining rules tailored to your own work habits—how tasks are assigned to different models, how semantics between CLIs are aligned, and how long-running tasks are validated and resumed—since there are no perfect matches yet, I'll keep them to myself for now.

I went through this work assignment thread one more time. Searching GitHub in August 2026 for names containing agentmux turns up more than fifty repositories, and names containing amux turn up about eighty, all unrelated to one another. Among them, the README for thevibeworks/amux explains the motivation: claude -p switched to extra billing, so I switched to driving the interactive TUI with a real tmux session to keep the usage within the original subscription quota—the exact same issue I was stuck on at the beginning of this post. Among the few I actually clicked into that had all four functions complete—dispatching, task logging, completion detection, and result reading back—were all under a few dozen stars, with several inactive for over half a year. The ones in this field with truly high star counts are actually doing something else: some are agents generated by prompts that type on the keyboard themselves, while others go in the reverse direction, where the AI looks at your screen and gives you commands.

So this time, I'm borrowing the idea—I'm not rewriting the whole thing from scratch.

I added two features to tmux-webui, sourced from Herdr and Orca respectively: borrowed the tree-pane state from Herdr to list the hierarchy of workspaces, tabs, and panes, allowing for a quick glance at who is busy, who is waiting for confirmation, and who has finished, without needing to click into each one individually; borrowed the dash window from Orca to place the agent deck and session log on the same screen, eliminating the need to switch tabs. tmux-webui originally did just one thing: bring tmux panes into the browser so users could view the original terminal screen even when away from their host machine.

Unlike Orca, the choice is this: Orca has built a complete development environment, and using it is equivalent to replacing your work interface; tmux-webui creates no separate interface—"deck" and "log" are additional overview layers, and clicking through them still shows what’s actually running in the original pane. Both approaches work; the difference lies in whether you’re willing to give up control of the terminal.

None of these tmux tools under operonlab were planned; each was added only after running into a specific piece of friction: running out of quota forced tmux-llm-usage into existence, an agent's unpredictable state forced out tmux-agent-status, getting disconnected from the chat after a restart forced out tmux-agent-resume, one project needing a pile of open windows forced out tmux-workdesk, and not being able to see the pane unless you're at the host computer forced out tmux-webui. Under operonlab, the public projects starting with tmux- numbered thirteen as of August 2026, when I’m writing this, plus session-channel makes fourteen.

Let's change the scenario—the same debate is raging over Nginx.

So I’ve added another criterion: the item has to be genuinely better, not just newer. This one comes from a song called “I Replaced Nginx With Caddy… And I'm Never Going Back” — a comment posted under that video.

That comment—which said, “Twenty years of existence is a strength, not a weakness”—addresses the exact same issue I’m facing with tmux. tmux has also been around for nearly twenty years; its interface is outdated and its configuration is hard to read, but send-keys and capture-pane—these primitives haven't changed in years—and precisely because they haven't, the things built on top of them don't constantly need to be rewritten. The new ADE brings worktrees, terminals, diffs, and browsers into a single view, offering a much better experience at the cost of tying your entire workspace to its lifecycle.

Years are neutral in themselves. The same twenty years can become a burden—configuration files no one dares to touch, workarounds piled on top of workarounds, and newcomers who can’t figure out why things were done that way. Or they can become an asset—every pitfall has already been stepped into, and the codebase has been reviewed countless times. The difference lies in whether those years were spent accumulating value or piling up debt.

Changing to a different harness isn't just about switching models

It's not just the model itself that determines the quality of the output. That article by Wisely Chen quantifies this difference: with the exact same Kimi K3 model, the official KCode harness only achieves 59.6%, while switching to the open-source Maka reaches 69.7%. A harness isn't just an outer shell for a model; it is the variable that determines the model's actual performance.

Pi and Claude Code take the exact opposite approach—Claude Code bundles the model with the harness for an out-of-the-box experience, whereas Pi lets you swap providers and models, offering flexibility at the cost of assembling it yourself.

What was supplemented in the previous few stations pushes the statement "the harness is a variable" one step further: when there is a single model, the harness determines how it operates; as models multiply, something else is needed to determine how work is divided, handed off, and verified. Different models are naturally good at different things, and mechanical batch modifications are enough to be run by cheaper models—in the previous post, breaking the work down into three layers—planning, worker, and acceptance—and running them on different models was the first version of this approach.

For the few stops I added on my own, the bill arrived a little later.

Let’s talk about the trade-offs first, otherwise this post might come across as encouraging people to do it themselves: the maintenance bills for these stations tend to arrive a bit later. Every time a flag is changed in the upstream CLI, I have to adjust the cli-rosetta registry accordingly; every time Claude Code switches to a new version of its TUI, tmux-webui's rules for determining whether an agent is busy or waiting for someone can misfire. Since these tools lack a community to monitor their compatibility, you’re on your own when they break. The longer they run, the more the effort required to maintain them exceeds the initial cost of writing them.

So in a different scenario, the conclusion might be completely different. When using only one or two agents and tasks don't need to be distributed across machines, directly picking a mature tool like Claude Squad or Orca will be much more cost-effective than piecing together a system yourself—those tools have people maintaining them, whereas the few stations you patch together yourself do not.

I end up doing it myself because getting stuck at that step was so frustrating, and I just couldn't find a workable solution at the time. Now that there are more answers in the community, I'll skip a step whenever I can.

Assess yourself first, then decide whether to take action.

You'll need to fill in the two conditions below yourself; you won't get a result until you've done so. First, use the symptoms to determine which stage you're at. Second, use a publicly available test with two anchor points to estimate whether it's worth sending out this task. Both calculations are done within the browser; no data is sent out.

Further Reading