Own the terminal. Don't live inside it.
Most AI coding work happens inside one terminal window at a time. Arbiter treats the terminal as a system layer it owns and drives from above, which is what lets one operator run a fleet instead of babysitting tabs.
The terminal is where AI coding work happens, and for most people it is also a cage. You sit inside one window, watching one agent, typing into one prompt. Open a second agent and you open a second window: a second thing to watch, a second place to lose the thread. The window becomes the unit of work, and the window does not scale. Every serious operator hits the same wall eventually. You can only be inside so many terminals at once.
Arbiter starts on the other side of that wall. It does not ask you to live inside a terminal. It treats the terminal itself as a layer of the system, something to own and drive from above, the way an operating system owns its processes instead of being one of them.
The window is not the unit of work
When a terminal window is your only handle on an agent, the whole operation is manual by default. Starting work means opening a window. Checking work means finding the right window. Losing work means a reboot closing all of them at once. Nothing coordinates, nothing recovers, and nothing remembers what was running where. The clients inside the window are excellent at one session. None of them was built to run many.
Owning the layer, not renting a seat in it
Arbiter runs as a local daemon that sits above your terminals and the clients inside them. From there it can open sessions, name them, track them, drive them, and account for them as real work rather than as windows you happen to have open. The client still does the coding. Arbiter owns everything around it: which sessions exist, what state each is in, and what to do when one finishes, wedges, or the machine restarts underneath it.
That inversion is the whole point. When the terminal is something you own instead of somewhere you sit, the number of agents you can run stops being the number of windows you can personally stare at.
What ownership buys you
- Many at once. Bring up a set of named sessions and treat them as a fleet, not a pile of tabs.
- Nothing invisible. Every session Arbiter opens is a tracked, accounted run with a state you can read, not a window that might have died ten minutes ago.
- Survives the machine. A reboot or a power cut does not erase the operation. Interrupted work is re-accounted and preserved for deliberate recovery instead of vanishing.
Above the clients, beside the tools
Owning the terminal layer is what makes the rest of the stack composable. Arbiter dispatches Warden as an agent, routes code questions to TheAuditor for ground truth, leans on Curator for memory, and answers to BenchProctor for proof. Each is strong on its own. The point of a layer that owns the terminal is that you can run all of them, at once, without becoming the coordinator yourself.
The old way, one operator inside one window, was never going to scale to a fleet. Owning the terminal instead of living in it is how you get out of the cage.
Arbiter is a proprietary working alpha in public binary release preparation. Follow the public release channel or RSS feed for updates.