My Terminal-First AI Agents Workflow: Herdr + Claude + Termux

I run AI coding agents on four computers and a phone from one terminal, and the whole thing survives closing the lid, rebooting servers and me going to bed. No GUI dashboard is involved. Below: the tools, some configs, what it costs me, the failure stories, and how I deal with quota limits. Setup as of November 2026, in daily use for real work.

TL;DR

• Herdr inside WezTerm is my agent cockpit: every pane reports whether its agent is working, blocked or done, and sessions live on a server, so closing the laptop changes nothing.
• Claude Code is my main CLI and the orchestrator: it delegates to Codex, Grok, OpenCode and Antigravity through a custom skill when a task fits them better.
• Provider aliases (ccz = Z.ai, cxaz = Azure) point one CLI at another provider's model. Instead of stopping when a subscription quota runs out, I route the work to another provider.
• Termux + Tailscale on my phone give me exactly the same capabilities as the desktop. Far better than the Claude or ChatGPT apps.
• Fresh, an editor that runs inside the terminal, is where I check changes; lazygit covers diffs.
• Restic snapshots every 2-3 hours on every machine are what let me hand agents real work without fear.
• Quota limits are handled: ChatGPT Pro has no 5-hour window, and when Claude's runs out, a monitor resumes the session after the reset.

The screenshot below is my actual desktop. Two Herdr workspaces side by side: on the left, Claude Code working on a website project with lazygit underneath; on the right, Codex doing a review pass on a pull request. The sidebar shows each named workspace and what its agent is doing right now - one of them is literally called "T3 Herdr Orca Paseo Zed", from the session where this stack got benchmarked against the GUI alternatives.

The fleet first, because everything else depends on it

Before the tools, the machines. My setup works because my main machines reach the others over SSH and three of the boxes never sleep:

• A Dell Vostro 7500 laptop, Ubuntu with KDE Plasma. My main machine and the only place with full access to my tools and CLIs (gh, az, gcloud and the like).
• A Windows 365 Cloud PC (8 vCPU EPYC, 32 GB) whose Linux/WSL side runs agents 24/7. Heavy jobs go here.
• An ageing HP Spectre x2 (a tablet-laptop hybrid) with an Intel m3, running Omarchy. It is slow by modern standards and still runs autonomous OpenClaw agents 24/7 without trouble.
• A Hetzner VPS hosting my own and client apps via Coolify.
• A Samsung Galaxy S24 Ultra running Termux, which is a full Linux userland, not a session viewer inside an app.

Plus the family fleet: my wife's HP ProBook and my daughter's machine are in the same SSH inventory. When something breaks there, I fix it from my terminal instead of taking the device away from them. How that works in practice: per-device SSH keys, a mesh over the LAN and Tailscale so nothing touches the public internet, and discipline. I wrote more about the backup side of this below.

SSH is deliberately not all-to-all. From my main machines, including the phone, I can reach every other one, but not the other way round. The Omarchy laptop runs autonomous agents, so SSH there switches off after an hour: agents running on it cannot get to my laptop without my permission. Agents run where I point them - the family machines get me over SSH, not my agent fleet.

Herdr: tmux that knows what an agent is

Herdr is tmux that knows what an agent is: install it with one line (curl -fsSL https://herdr.dev/install.sh | sh; brew and nix also work) and you get a terminal multiplexer that recognizes coding agents running inside panes. The project calls itself an agent runtime rather than a multiplexer, and that is the honest description - the sessions live in a background server, not in your terminal window. Once you run more than two agents, that matters:

• Every recognized agent pane reports a lifecycle state: working, blocked, done, idle (plus unknown for the ones Herdr cannot classify). The sidebar shows it per agent and rolled up per workspace. When you run six agents, you stop alt-tabbing through identical prompts to figure out which one needs you.
• Sessions live on a server, not in the terminal window. Close WezTerm, shut the laptop, go home - the panes keep running. Open a new client anywhere and you are back in the same session.
• When the Herdr server itself restarts, the processes die but the work does not: panes with a session integration are relaunched and their conversations resumed - Claude Code with --resume, Codex with its session id. Plain shell panes reopen as fresh shells. I have restarted servers and had Claude and Codex continue their threads right where the transcript ended.
• A workspace holds agents, plain SSH shells and other TUIs (lazygit, htop) side by side. I keep one workspace per device, and a tab bar per workspace. One view, one whole machine.

Two quality-of-life configs I would not skip. First, give things names: agents started through Herdr get a unique name they keep across panes (herdr agent start reviewer --kind codex --pane <pane-id>, from an available shell pane), and workspaces can be renamed so tabs stop being anonymous - the right-click context menu does it, and a Claude Code hook can rename the workspace from the task automatically:

1herdr workspace rename <workspace-id> my-task-name
Bash / Shell
Copy

Second, make the sidebar show what each agent is actually doing. Agents set their terminal title constantly (Claude Code writes the current task there), so add the title as a sidebar row in ~/.config/herdr/config.toml:

1[ui.sidebar.agents]
2rows = [["state_icon", "machine", "workspace"], ["terminal_title_stripped"]]
TOML
Copy

Now row two of each sidebar entry is live task text like "Review PR #210 and verify data migration across repos". That single line replaced most of what I expected to need a GUI dashboard for.

I almost never use tmux myself; Herdr covers it. Long-running work never runs inside a plain SSH pipe - a dropped connection kills it. When an agent delegates a job to another CLI, it opens a named Herdr workspace and runs the job there with a log file:

1herdr workspace create --label "codex: nightly review" --cwd ~/DEV/Projects/app --no-focus
2herdr pane run <pane-id> "codex exec --sandbox workspace-write 'do the thing' 2>&1 | tee ~/logs/nightly-review.log"
Bash / Shell
Copy

Every delegated session shows up in my Herdr sidebar, so I can watch what each agent is doing, and the agents close their workspaces once the result is recorded, so I only see what still matters. Agents occasionally reach for tmux on their own for a specific task, but that is the exception.

Claude Code as my main CLI (and the manager of the others)

Claude Code is my favourite CLI and the one I use for about 80% of my everyday work. It is not the only one: Codex and OpenCode get regular use, and sometimes Antigravity or Grok, mostly to save quota when Claude runs out. Claude Code is also the orchestrator. Opus is my daily driver: it plans and delegates, almost all execution goes to other agents and models - mostly GPT models through Codex, sometimes Azure deployments, and small, cheap models like Haiku for simple tasks. A custom skill teaches it when and how to delegate to the other CLI agents. The routing below is what survived months of tuning - early versions had Antigravity reviewing screenshots, until the day it reported three CSS defects that did not exist, and the rule became screenshots go to Codex, research goes to Antigravity:

• Claude Code (Opus) plans, decides, reviews and verifies. It writes briefs, hands out work, reads diffs, checks the results. The manager, not the typist.
• Codex (gpt-5.6 Sol via codex exec) is the main developer: implementation, refactors, bulk mechanical work, and the only lane I trust with screenshot review.
• Grok (grok-4.6 via the xAI CLI) is the fast workhorse - mechanical batches, bulk edits, overflow when Codex quota runs dry mid-sprint.
• OpenCode (GLM via opencode) gets taste-sensitive work: UI, CSS, marketing copy. GLM-5.3 turned out good enough at code that it is now a legitimate first choice for implementation too. Text-only, never images.
• Antigravity (agy, Gemini) does research - its web search is Google-grounded, the only local CLI with real Google access. It lost screenshot duty the day it reported three CSS defects that were never in the file.
• And when a problem is genuinely hard, there is a strongest-model lane on demand. Never the default; it burns quota visibly faster.

The part that makes this cheap is provider aliases. Each alias is just a couple of environment variables (base URL + key) or a CLI profile that points the same tool at a different provider:

1# the shape of it - same binary, different backend
2alias ccz='...env vars... claude'      # Claude Code on the Z.ai GLM coding plan
3alias cxaz='codex --profile azure'     # Codex on Azure-hosted models
Bash / Shell
Copy

So "which model runs this task" is a shell alias, not a procurement decision. The same aliases are also the privacy mechanism: when a task touches client data, it moves to a lane pointed at EU-hosted Azure deployments, and that rule is written into the skills the agents read. The full pattern has its own article: AI Agent Data Privacy: How We Let Coding Agents Touch Client Work Safely. A practical note from the screenshot above: my status line shows the Claude weekly quota at 80% while typing this article, and that is fine - more on how I handle limits below.

What it costs me

Because everyone asks: subscriptions run me about $160/month - ChatGPT Pro at $100, Claude Pro and Google AI Pro at roughly $20 each, Grok through X Premium at around $10, GitHub Copilot at $10, and the Z.ai GLM coding plan Lite tier, which I bought for $25/year on a sale and which has lasted me months while handing out more tokens than some $20/month plans. On top of that I run roughly $100/month of API usage (Azure-hosted models, automations, my autonomous agent), covered by Microsoft partner-program credits - a subsidy, not a zero. Hardware, the Cloud PC licence and storage sit on top of all this; this list is the tooling bill, not the total cost of ownership.

Skills: teach your agents once, everywhere

The delegation skill above is one of about twenty custom skills in a private git repo, installed on every device with skills.sh:

1npx --yes skills@latest add <owner>/<repo> --skill <name> -g
Bash / Shell
Copy

One command installs the skill into a shared user-level store and symlinks it for every CLI agent that reads skills - Claude Code, Codex, OpenCode, and the rest. Update after merge, and every agent on every machine has the new knowledge. A skill is just a Markdown file with instructions (plus optional scripts), which makes it the cheapest way to encode "how we do things here" once instead of re-explaining it to each agent per session.

Examples from my repo: how to safely touch the Cloud PC, how to route work between models, how to write blog posts for Edukey (this article was drafted through that skill), how to audit the phone without breaking it. If an agent on the VPS and an agent on the laptop both need the same rule, it lives in the repo, not in anyone's prompt history. The kind of thing that lands in one, straight from my delegation skill:

Invite the delegate to argue. Briefing an agent to "argue against this decision if you disagree" surfaces the real trade-off instead of burying it.

Beads and Obsidian: the task board and the memory

Multi-agent work collapses without shared state, so agents get real project management:

• Beads is the task tracker - think Jira for agents. One shared database over Tailscale, CLI-first (bd create, bd update <id> --claim, bd note, bd close), and every agent on every device works the same issues. Priorities, dependencies, progress notes, "verify this before closing" questions - all in the tracker, not in chat scrollback. My rule is one issue per deliverable, and an agent that finishes without validating does not get to close it.
• Obsidian is the knowledge base for humans and agents: goals, plans, briefs, post-mortems, how-tos. Clients' personal data never goes there - that is a hard rule and it lives in SharePoint behind Microsoft-hosted models instead.

Sync is deliberately boring and multi-layered: Syncthing carries note content between devices continuously, git snapshots the vault nightly from exactly one device (Dell - everywhere else is read-only for git, because letting two devices commit into a Syncthing-synced repo is how you corrupt it), rclone pushes an hourly copy to Google Drive, and OneDrive covers the Windows side. Each layer has failed me once. That is why there are layers.

The phone is a first-class citizen

Termux plus Tailscale on the S24 Ultra gives me the same Herdr sessions as the desktop. Herdr itself runs on the always-on machines; the phone runs its client, pointed at the same session servers over SSH - same tabs, same agents, same states, full CLI. Not a companion app, not a read-only dashboard. The phone reaches every machine, and my main machines can get into its Termux over Tailscale. When a GUI tool advertises "steer your agents from mobile", I shrug - I can fix a VPS at a bus stop with the same commands I would type at the desk.

Typing is the obvious objection, and dictation is the answer on both ends:

• On the phone, the FUTO keyboard with its local speech models dictates prompts. On-device, no cloud round trip, and it handles technical vocabulary better than I expected.
• On the desktop, handy.computer does local dictation with Whisper models for most prompts.

For long, precise prompts there is a third lane that dictation does not cover: ctrl+g inside a Claude Code prompt hands it to your $EDITOR in the terminal - micro in my case - and you write the prompt like a file. Compose, edit, rewrite a paragraph, then submit. Once you are used to it, one-line prompting feels like texting with mittens on.

One honest warning: Termux is hand-maintained on my phone. I do not let package managers update agent CLIs there automatically, because an npm update once replaced a hand-installed binary with an incompatible build and broke my setup mid-trip. On the phone I update deliberately, not automatically.

When I still use a GUI (and why so rarely)

I do use a graphical app now and then - mostly the Codex app in ChatGPT. It is slow, so it is not where I work day to day, but it earns its place for three things: voice in live mode, its built-in browser when an agent needs to operate a real website (computer use), and some UI and UX fixes. Most of the other apps I tried, Zed and Orca included, I rarely open anymore. To check changes I use Fresh, an editor that runs inside the terminal, and lazygit for diffs.

The reasons are practical. Graphical apps use far more resources, they are more limiting, and in my experience they are buggier. Some things are simply not possible in a GUI, and most things are easier to find and do in a CLI tool.

I did give the GUI tools a real chance - the workspace named "T3 Herdr Orca Paseo Zed" in the screenshot was weeks of evaluation, not an afternoon:

• T3 Code is the most polished agent control surface I tried, and the mobile pairing is genuinely nice. I ran its self-hosted server since July. When I did, it only showed threads it had started itself - my terminal sessions were invisible to it (t3code issue #5346, since closed, so possibly fixed - worth retesting if you are GUI-first). I did not measure it rigorously, but my weekly quota drained visibly faster on GUI-driven tasks than on the same work straight in the CLI. It is also alpha, and I hit two rough edges on day one of the current version.
• Orca is the most feature-dense of the bunch (fan-out to many agents, pick the winner, built-in terminals, SSH worktrees). My problem: I already do the same thing manually in three Herdr tabs with three git worktrees, spending the same tokens with no tool overhead. The GUI mostly automates a step that costs me nothing.
• Zed stays installed for the occasional job: its remote sessions are the fastest I have used over SSH, and its agent panel speaks ACP (the Agent Client Protocol), so external agents work inside the editor. These days I open it rarely; Fresh and lazygit cover what I used it for.
• Screenshots with annotations: Flameshot with arrows and text beats every "click the element to add context" feature I have seen, because I already know how to draw an arrow.

The pattern in what I rejected: each GUI wants to own the session. My terminal workflow owns the session, and the CLIs are swappable underneath. That is also why the T3 limitation mattered so much to me and would not matter to someone who starts every session inside the GUI.

The safety net that makes agents usable

Letting autonomous agents touch real machines requires assuming they will break something eventually. Mine have: deleted a wrong file, clobbered a config, filled a disk. The countermeasure is Restic snapshots every 2-3 hours on every machine, pushed encrypted off-site. When an agent damages something, the recovery is mechanical: find the snapshot, restore to a temp directory, diff, put the file back. Never restore straight over the live path, and never treat a local Timeshift-style system snapshot as protection for your home directory.

The rule that took longest to internalize: check that a backup covers a path before you let an agent rewrite it, not after. Restoring from a snapshot that is four hours old beats reconstructing a file from memory - but restoring from the snapshot you forgot to configure beats neither.

How I handle quota limits

Running out of quota mid-task used to kill night runs. Today it is mostly a solved problem. ChatGPT Pro, which I pay $100 for, has no 5-hour limits, so Codex keeps working when Claude stops. For Claude, I set a monitor for the exact time the 5-hour window resets, and the session resumes on its own after that - no need to wake up at 3am to type "continue".

A LiteLLM gateway with an ordered fallback list per task could route a 429 to the next provider transparently, and every CLI here already speaks to arbitrary providers through aliases, so it would be configuration, not surgery. It may be useful later if I want to switch providers automatically; right now it is not urgent.

If you want to build this

The honest starting checklist, in order:

1. Get SSH and Tailscale working between your machines first. Everything else is downstream of that.
2. Install Herdr, create one workspace per device, and live in it for a week before adding anything else.
3. Pick one CLI as your orchestrator and learn it properly - for me that was Claude Code. Add other CLIs only when you can name the task the first one does badly.
4. Set up Restic snapshots before you let any agent run unsupervised. Not after the first incident.
5. Add a task tracker your agents share (Beads or similar), then a skills repo with skills.sh once you find yourself repeating instructions to agents.
6. Only then evaluate GUI dashboards - with your own workflow as the benchmark.

FAQ

Do you need paid subscriptions to run this workflow?

No. The structure - multiplexer, one orchestrator CLI, SSH fleet, backups - works with free tiers and local models. Subscriptions buy you throughput and headroom, not the pattern. The $25/year GLM coding plan I found on sale is proof that provider pricing moves fast enough that whatever I write here will be stale before your next invoice.

Why not just use a GUI like Orca or T3 Code?

Try one - they are good at what they do. My rejections were specific: T3 Code could not see sessions I started in the terminal when I ran it, and Orca automated a fan-out step that already costs me nothing by hand. On top of that, GUIs cost more resources and break more often than the CLIs underneath them. If you live inside a GUI and never touch a shell, the math may land the other way for you.

Is it safe to let agents run unsupervised on your machines?

Not inherently safe - that is what the guardrails are for: sandboxed CLI modes, Restic snapshots every 2-3 hours, a rule that agents never commit or push without explicit instruction, SSH that only goes outward from my main machines, and client personal data restricted to specific providers and regions. How those privacy controls are built - region routing, rule files, hooks that block credential access - is the subject of the data-privacy article. Guardrails shrink the blast radius, they do not make it zero, and the backups are not a formality - they have paid for themselves more than once.

How do you type all this on a phone?

Mostly, I do not. FUTO keyboard dictation with local models handles prompts on the phone, handy.computer does the same on the desktop, and ctrl+g opens a real editor for the prompts that need careful wording. The S24 Ultra screen size helps, but dictation carries the workflow.

What single change improved this setup the most?

Server-side sessions. The moment agents stopped living inside a terminal window - when closing the laptop, switching devices and even restarting the multiplexer stopped killing work - parallel agents went from stressful to boring. Boring is the goal.

---

A note on who is writing this, since the screenshot shows it anyway: the panes above are my actual Tuesday - client work, training materials, and a 3D game called Stack Underflow that came out of a hackathon and lives in the same repos as everything else. Building automations like these is the family business: Edukey trains teams on practical AI and data skills, and DevPowers is where our own agent-built projects ship. Everything in this article is reproducible without us - but if you want your team moved from browser-tab ChatGPT to something like this, that is genuinely the job I do.