Rysh vs Claude Code: many agents behind one input box vs many agents in coordinated panes

Claude Code already runs many agents. The ceiling isn't capability — it's coordination. Here's the workspace I built on top of it.

Your coding agent already runs many agents.

Claude Code spawns subagents. So the tired line "it's just one agent" is wrong, and if you've used it past a toy task, you know it.

But watch where all that agent activity actually happens: it funnels through one terminal and one input box. Subagents report back to a single conversation. You type in one place, you read in one place. That's not a capability ceiling — the agents are real and they're good. It's a coordination ceiling. You can't watch two agents at once, can't give each its own view, can't hand the running session to a teammate, can't point one agent at the exact output another just produced without copy-pasting it yourself.

I've been building rysh around exactly that gap. Quick honesty up front, because it's the whole frame: rysh runs on Claude. I'm not claiming a smarter model. Same model, your own Anthropic key. What I'm building is the workspace around the agent — many of them, in their own panes, coordinated, and governed.

The one idea: a pane is a conversation, not a shell

tmux gives you panes that are dumb shells. Rysh gives you panes where each one is a conversation that can be a shell, an autonomous agent, a chat, or a live external channel — and they can talk to each other. Everything below falls out of that one decision.

Under the hood, every pane is an actor with its own mailbox, and panes coordinate by publishing to NATS subjects (embedded, in-process, one broker per session). "Agent A reads agent B's output" isn't a bolted-on feature — it's two actors and a subject.

Fan one task out to a team, each agent in its own pane

Write your agents as markdown skill files, then spawn the whole team at once:

##agent spawn-all ./team     # one .md per agent: reviewer.md, tests.md, docs.md

Address any of them by name, and point them at each other's work:

@reviewer look at the diff @tests just produced and check the error paths
##pane listen reviewer       # this pane now streams the reviewer's output live

With a single input box, that workflow is you, being the message bus. Here it's ##pane listen and a NATS subject.

Headless works too, which is where it earns its keep on a server:

rysh send mysession "run the smoke suite and summarize failures" --pane 3 --mode shell

Hand the live session to a teammate

This is the one a single-input CLI structurally can't do. Share a running pane — read-only or full control:

##share pane control         # or: ##share pane view

On the other side: ##upstream subscribe <shareID>. Real people and real agents pair in the same workspace, live. Shared sessions can be restricted to a command allowlist, enforced at the messaging-proxy layer — not in the UI where it'd be trivial to bypass.

The quick table

A footprint note, because people ask: in my own day-to-day use, rysh averaged ~49 MB per session (5 instances, 12 days) vs ~345 MB for Claude Code sessions (27 sessions, 7 days) — about 7× lighter. That's my real usage, not a benchmark. Footprint decides how many agents fit on one box, and on a server that matters.

Secrets, loops, and other surfaces — the short version

Three more things that come from being the workspace layer, not the agent:

• ##snat (SecretNAT): real secrets are swapped for format-preserving tokens before the request leaves your machine. The model reasons about sk_live_SNAT000001 and never sees the value. It's a translation layer, not a vault — bounded claim, precisely stated: the provider never receives the value.
• Loops on a leash: autonomous loops run against a hard token budget (a page is 1k tokens; a book is 200 pages), with a takeover leg at 90% and an LLM judge deciding whether the goal is actually met.
• Same agent, more surfaces: the markdown file that defines your terminal agent can answer on Slack, email, and website chat as a "humanoid." Draft-and-confirm governance is live on email and website chat today. WhatsApp and phone are roadmap, not shipped.

When to pick Claude Code

Genuinely, often. If you're one developer working one repo in one terminal, Claude Code is excellent and you don't need a coordination layer — extra structure would just be ceremony. Anthropic iterates on it fast, the subagent model is strong, and the ecosystem around it (hooks, MCP, skills) is the best in class. Rysh doesn't replace any of that; it's the layer above, and honestly — the two compose. I wrote up running Claude Code inside a rysh pane separately.

Pick rysh when the one-input-box wall is the thing you keep hitting: a second agent you can watch, a session you can hand off, secrets that never touch the vendor's wire, an agent your support team can reach on a real channel.

What's not done (don't believe me if I imply otherwise)

• Not open source. Private beta; self-hostable on your own infra + your own Anthropic key.
• Slack draft-and-confirm isn't shipped — the gate is live on email and website chat; Slack posts autonomously for now.
• WhatsApp / phone channels aren't live (roadmap).
• ##snat is a translation layer, not a secrets manager.
• Forge is OpenAPI-only — no GraphQL/gRPC runtime yet.
• Hosted billing is gated on dev, not live.

Rysh is in private beta. Access is through the design-partner program: free access, a direct line to me, and your feedback sets the roadmap → apply here.

More in this series: Better together: running Claude Code inside a rysh pane · Every pane is a conversation