Let's get the status bar right.#

February 2026 byopenclaw Inspired to start using tmux, follow YouTube ontmux use and basic configuration from the introduction to overtime a video all set! All the way through knocking instructions to familiarize yourself with the feel of the hand.

At that point I was already using a bunch of AI agent CLIs at the same time - fixed shifts with occasional swaps - and opening a few more terminal windows made a mess. tmux was the tool to clean up the mess.

I'm not a "figure out the whole architecture and then start" type of guy, I'm a step-by-step stacker. The first step is to look at the status of each CLI - starting with Claude Code's statusline.

~/.claude/settings.json set upstatusLine.command Point to what you've written.statusline.sh::

statusline.sh It's a lot of work - grab session ID, cwd, git branch + changed files, model display name, session cost, context percentage, all in one jq (to avoid 15 fork per second). overhead):

I want to see more after writing it - Claude / Codex / Gemini 5 hours, 7 days quota, CPU, MEM, DISK, NET, but the Claude Code statusline is only for the current session, not the cumulative quota across sessions. However, Claude Code statusline can only see the current session, not the cumulative amount across sessions. I pulled this layer out and put it into the tmux statusline.

~/.tmux.conf Wrote a longstatus-format[1]I'm going to call for one of my own.tmux_status.sh Pulls information, matches catppuccin color scheme:

status-interval 5 Fork every 5 seconds. At first I used Python to write this script, every 5 seconds I forked one interpreter, 13 processes in 13 columns. tmux server crashed once, then I changed it to shell + jq to save the startup overhead of the interpreter.

Three repetitive pane layouts#

After learning the basic commands, we have converged on three repetitive layouts.

1. Vertical four-column equalized width#

Most commonly used - 4 AI agent CLIs are really running at the same time. Each column has an independent dialog, dispatching a task, and scanning through the four columns, you will know who has finished running, who is still thinking, and who wants to reply. The width is equally divided, and it takes one second to scan from left to right, so you don't need to remember which one is where.

2. Center-cross tetrad#

For larger screens - one fixed character in each of the four quadrants. My current arrangement is main dialog top left, code or file tree preview top right, comparison info bottom left (CLI capability table, provider/model specs), and secondary CLI (qwen or other) bottom right.

Compared to the vertical four columns, there is more "vertical" information density - some pane are good for long strips (logs) and some are good for squares (tables, codes). A cross layout can accommodate both.

3. main + subagent layout#

Main+Sub scheduling layout - a big pane on the left runs the main agent (mostly Claude Code), and 4 small panes on the right cut horizontally to run a sub-agent or sub-task. main sends out the task, and the panes on the right run in parallel to see the status, and report back to the left after running. The pane on the right will run in parallel and see the status in parallel.

This layout is the prototype of the later relay system - just replace "I manually dispatch" with "skill auto dispatch".

It's stupid to start over when the connection drops.#

The first time I stepped into tmux the second value was ssh into the developer to run a long build.

When I didn't install tmux, ssh would break and build from scratch. After changing to this process, it has not been interrupted again:

At that moment I realized: tmux is not a split-screen tool, it's a container for process.

After that, all the remote sessions will go to tmux: one default session per host, ssh first.tmux a || tmux new -s defaultNever run things directly from the bare shell.

on top of thattmux-resurrect + tmux-continuum Two plugins that automatically snapshot the entire layout every 15 minutes, and tmux up after reboot to restore it automatically.~/.tmux.conf There's only two lines in there:

I restarted my mac mini at home, and it came back with the session still in the same place.

Mac mini at home, MacBook on the go, iPhone on the road.#

After this process was stabilized, the mac mini at home became the main developer.

24/7 on, always have tmux running my default session. the need to sync files to the cloud is reduced - the source code is on there anyway. Took MacBook out → ssh home →tmux a → Continue the prompt that was not finished in the morning.

I think of an idea on my commute, and I don't need to take notes, I just type it into the session.

I'm used to looking at 4 agents in a vertical 4-column layout. ssh on my phone used to be too wide for me to look at any of the columns.prefix + z Zoom in to fill it up, then zoom out to cut to the next one. Every time I interact with an agent, there are two more procedures, and I get tired just doing something.

Made a tmux-webui#

This idea predates Claude Code's own remote mode. Later, when remote came out, I still used tmux mostly - I've already stacked this path to the point where it's very natural, so let me start from the beginning.

That's why I turned to tmux-webui - to move the tmux pane directly into the browser and skip all the ssh client / mosh tossing.

The reasons for choosing the web over native iOS apps are realistic: no Xcode, no TestFlight, no $99 a year. You can use it on any device with a browser. The tradeoff is that you have to handle auth and traffic encryption yourself, which is left to Cloudflare Tunnel.

It does a few things: lists all sessions/windows/panes, clicks on a pane to see which pane's output is live, swipes left/right with a touch gesture, zooms in/out with two fingers, and installs the main screen as an app in PWA. The touch control part is learned from Blink Shell - I've used it for a month or so, so I know which gestures I'll use every day, and which ones I'll use in the demo. On the typing side, there is a skill palette, so I can scan it and know what I can call.

Back to multi-agent, this time using a tmux pane as a cell.#

Think before you start: why multi-agent, rather than leaving everything to a single CLI?

Once the rationale is clear, the limitations of the existing program are then summarized in three categories, from shallow to deep.

There are three levels#

At the bottom is a working window, the pane is not resident - the main agent sees which CLI is suitable for the task (the strong point is the community comments and my own preference from using it), and then opens the pane to activate that CLI. When it's done, it's kept for later use, and recycled if it's been idle for too long.

The judgment of picking idle is based on the current state of the pane - agent is waiting for input or running, recognized from the output content. No locks are maintained, no history is kept, and the screen is revisited every time.

Instead of polling, tmux uses its own hook mechanism - it wakes up the block's dispatcher at the end of the pane.

This set still lacks the last piece of team agent: there is no way for pane and pane to call each other directly. I've built a small publish/subscribe service.session-channel To supplement this layer, the pane interconnections rely on channels, so there is no need to go through an intermediary.

tmux becomes a bridge across CLI agents.#

The trade-off must be clear.#

• send-keys It's plain text, no typed schema - patch it with stdout JSON Lines.
• The pane buffer has a history-limit (I set it to 10000 rows) - output is truncated in the middle of a long task.
• tmux is not a natural message bus - message reliability has to be handled by itself (signal file + retry).
• Fully loaded mode eats up more resources than headless - several pane's each running a fully loaded CLI, and the memory is quickly eaten up.

And here's a trick: handoff when the context is almost full.#

This can only be done in a "multiple pane running at the same time" environment: a session context is used up to 70-80%, and if you keep writing compact, the quality will drop. At this point, open a new tmux pane, start the same CLI, and go back to the session that was almost full and tell it:

Let the new pane read it when it's done.handoff.md The original session is naturally compacted or terminated when the work is continued. When a single CLI session compacts itself, there is no place to catch the lost nuance; in a multi-pane environment, there is someone who can catch it.

Resident QA agent, subscriptions not APIs.#

The multi-agent approach is to "assign work when the task comes". However, there is another daily usage scenario, QA - it's not for the agent to do the work, it's for it to help me check, help me think, and organize the current state. If this layer goes through API (Anthropic / OpenAI / Google API), it will be charged by token, and the more you ask, the more you spend.

So I have a pane in tmux running a subscription version of the CLI (Claude Code, Codex, Gemini all have monthly plans), and I type in questions on my phone through a dashboard widget I made myself. Behind the scenes is the samesend-keys Go to that pane, but run "subscription quota" instead of "charge by token".

The standup drawing in the picture is made by Live2D - the view will follow the mouse movement, and the mouth of the agent will open and close when answering the streaming. It's purely a visual detail, but it does provide a sense of companionship after a long chat.

API paid vs subscription + tmux pane#

• Go API: Each question is billed by token, so if you ask too many questions, your bill will fly up. Advantage: No time slot quota, unlimited parallelism.
• Go tmux pane + CLI subscriptionFixed monthly fee, 5 hours / 7 days quota runs out, no surprise bills. Charge is a hard limit of quota and cannot be stacked in parallel indefinitely.

Now the stack looks like this.#

The mac mini at home runs a default session 24/7: ssh attach in the morning, detach on the way out, PWA on the cell phone on the way to work, change the MacBook on the way out - all the way to the same session without interruption. The status bar lays out the cross CLI quota and the system status, and the multi-agent task is sent to the relay system for scheduling, and I just look at the results and make a decision myself.

Looking back at the past 3 months, from status bar, split screen, remote to multi-agent scheduling, each layer is not planned out - the pain point of the moment to be solved, and then do it to see what the next pain point is. tmux has always been at the bottom of the never changed, because it is just enough to use every time.

This set is for my own use only. It will be organized and open-sourced later--tmux-webui,tmux-relay,session-channel⋯ Cut each tool cleanly, write down the documents clearly, and rely on cutting until it can be installed separately. There is no specific timetable, so I'll put one after the other.

Extended Reading#

Resources that were actually referenced and influenced design decisions during these three months.