You already have an AI fleet. You just don't have a commander.
Arbiter is a local-first orchestration layer for configured agents, providers, and jobs. It can apply routing policy, preserve durable run state, and use a local GPU model for orchestration assistance.
If you build with AI for a living, your setup has quietly become a fleet: two or three coding clients, a stack of provider accounts, a SAST tool, a memory layer, background jobs that run for an hour and die at minute fifty-nine. Every piece is useful, but nothing actually runs the operation. You are the orchestration layer, babysitting tabs, copy-pasting between tools, and restarting dead runs.
Arbiter is the layer above the pile: an OS-level command center that dispatches, routes, schedules, and records the state of supervised work. It’s standalone-first and provider-agnostic, and it can use a brain that runs on your hardware.
On its own, it ends the chaos
Most “agent platforms” assume you’ve already surrendered to one vendor. Arbiter assumes the opposite:
- Agnostic to the core. It coordinates configured clients and supported provider APIs, and it also runs with none of them. No vendor owns your workflow.
- Its brain is local. Routing and triage run on a small model on your own GPU, not a metered cloud call, so the decision layer itself has no vendor and no per-token bill.
- It works with configured accounts. Routing and scheduling policy can weigh the accounts you connect, and the selected route is recorded for inspection.
- It survives. After a reboot, a crash, or a power cut, a durable, encrypted run transcript means in-flight work is re-accounted and preserved instead of vanishing or running forever.
- Safety policy can constrain routes. Configure sensitive work so price is not the only decision factor, and use approval where your operating policy requires it.
A pile of tabs can’t do any of that. One commander over the fleet is the difference between an operation and a hobby.
Over the full stack, it runs the whole operation
Arbiter is the conductor, and the rest of the stack are the instruments: each strong alone, each sharper under the baton.
- Warden is the agent it dispatches across every provider you hold.
- TheAuditor is the ground truth it routes your code-questions against.
- Curator is the evolving memory it feeds into the right job at the right time.
- BenchProctor is the proof layer its analysis runs answer to.
From one place, you can coordinate configured agents and optional tools. The working alpha targets Windows and modern Linux, with control surfaces that depend on the clients, adapters, and policies you configure.
Read the same point from each of their seats: TheAuditor, Warden, Curator, and BenchProctor.
The old way is already over
Manually shepherding a fleet of AI tools is the unglamorous tax nobody put on the invoice: the dropped runs, the throttled accounts, the context you re-typed for the fifth time. The teams scaling AI work aren’t grinding harder. They put a commander over the fleet and stopped paying the tax.
Follow release preparation
Arbiter is a working proprietary alpha in public binary release preparation. Provider-agnostic, local-first, and designed for deliberate recovery: that design is the part we will not compromise. The source stays private; follow the public release channel or RSS feed, and start with Introducing Arbiter.
The whole stack, in its own words: TheAuditor · Warden · Arbiter (you’re here) · Curator · BenchProctor