Agents from every major vendor.
One client, each sandboxed.

Both give you a shell; neither gives you a session that survives. Quit your terminal mid-exec and the process dies with the connection. Here the session lives in the container, so closing the app closes a WebSocket and nothing else — the next launch re-attaches from the byte where output stopped and restores the same split layout. The deployment model differs too: no kubeconfig on the client, no port-forward, and a credential that authorises one session rather than your whole cluster.

Herdr is an agent multiplexer — tmux for coding agents. It gives each agent a real PTY, keeps them alive across disconnects, classifies every pane as working, blocked or idle, and exposes a CLI and a socket API. The persistence and the fleet view overlap with this app almost exactly. What differs is where the agents run:

• Herdr runs them on the machine you invoke it on, sharing your user, your filesystem and your credentials — so the blast radius is that machine and everything your account can reach. Its persistence is across disconnects, not across the host powering off, so on a laptop, closing the lid ends everything. (Its SSH remote mode avoids that, at the cost of moving the blast radius to the remote host.)
• OpenAB Connect gives each session its own container in your cluster — uid 1000, no sudo, no host credentials, read-only root, ephemeral workspace — reached over a WireGuard tailnet with no port exposed. The blast radius is that container, not your machine, and it keeps running whether your laptop is closed, asleep, or a different laptop.

The difference is sandboxing, not multiplexing. Herdr also does things OpenAB Connect does not: pane state classification, a scriptable local API, and running with no infrastructure at all. If you want nothing to deploy, Herdr is the better answer.

An agent on your Mac runs as you. It can reach your SSH keys, your cloud credentials, your npm and GitHub tokens, and every repository on the disk — so a wrong command is a wrong command on your machine. Here the shell has none of that, the workspace is discarded with the session, and several agents can work at once without competing for the same working tree or the same ports. Your laptop can sleep or close without stopping anything. The cost is real: the agent cannot see your local files, so work arrives by git; the first pull of an image takes a few minutes; and you need a cluster or an AWS account. For a quick edit in a repo you already have open, running locally is simpler and this adds nothing.

They are complementary by design. The split is what you care about:

• OpenAB brokers ACP — you send instructions from a chat client and care about the outcome the agent delivers, not how it got there. You are the instructor, and the session is turn-based request and response.
• openab-pty is the PTY mode — full observability with a native terminal. You care about what is happening right now, watching, inspecting and acting in real time. You are the operator at the keyboard, and the session is an unbounded byte stream.

The complement is structural, not an analogy: the PTY images are FROM ghcr.io/openabdev/openab, so the shell opens inside the same image the agent runs in, with the same CLI and the same workspace. When an agent leaves something half-finished you attach and look at it in situ. Neither requires the other, and the session models share nothing on purpose — a byte stream's liveness is defined by bytes and sockets, not turns.

The full account is in openab-pty's design document. OpenAB Connect is the first client implementation of the openab-pty client contract — the contract is published, so anything that can hold a credential and speak WebSocket can be the next one.

Deliberately little. It opens as uid 1000 with no sudo, no service-account token and no host credentials, on a read-only root filesystem with an ephemeral workspace. A session shell can reach the runtime over loopback, which is why the admin credential is never inside the container: an attach token authorises exactly one session and expires.

No. The runtime binds 127.0.0.1 and holds no TLS key. A Tailscale sidecar in the same pod is the only thing with a network identity, and the two talk over loopback inside the pod's network namespace. Traffic reaches you over the WireGuard tailnet, which is what carries the encryption.

Nothing. There is no service here — every server the app talks to is one you deployed, in your own cluster or your own AWS account. No account, no sign-up, no analytics, no telemetry. Credentials you supply stay in the macOS Keychain and go nowhere except your own runtime.

Yes. The runtime is MIT licensed at openabdev/openab-pty, and the client contract is published, so you can write your own client instead of using this one. This app is one implementation of that contract and is not open source.

Yes. Demo Mode in the app menu runs two sample connections and a recorded terminal with no network connection of any kind. It exists so the app can be evaluated before you deploy anything.

Three clicks, then eight steps: a credential is minted into your Keychain, the namespace is ensured, the secret and volume are created, the pod is applied, and the app waits for it to run, waits for it to join your tailnet, and verifies the admin plane. No manifests to write. The first deploy of an image can take a couple of minutes because the cluster is pulling it.

The workspace is discarded. That part is certain: it exists only for that session, and deleting the session deletes it.

What is not certain is processes. Deleting a session terminates that session's process group, but a process that deliberately leaves that group — a background job started with nohup or setsid — can outlive it until the pod or task is replaced. It is still confined to the same sandbox and gains no new reach, but it keeps consuming that pod's CPU and memory.

So this is labelled best-effort in the app rather than claimed as a clean kill. To be certain nothing remains, delete the pod or task.

Not yet — this is being built. Today each session is independent: you instruct each agent, and they do not delegate work to one another.

The design is public. It follows OpenAB's Agent Control Plane ADR — a hub-and-spoke registration and routing service that lets agents delegate directly over ACP on WebSocket instead of round-tripping through a chat platform, which costs rate limits, latency, and orchestration noise in channels meant for people. Three parts: a registry of who is alive and how they are labelled, a router that dispatches by name, label or namespace, and policy covering delegation depth, cycles, namespaces and allowlists.

One decision there matches this app's model: agents dial out to the control plane, so working across networks needs no inbound port at either end.

The ADR is merged; the implementation is not shipped. Contributions welcome — that document is where the discussion starts.