Introducing Arbiter: the orchestration layer your AI stack is missing
A provider-agnostic command center for configured LLM clients, terminals, and long-running jobs. It applies routing policy and preserves interrupted run state for deliberate recovery.
Modern AI work is a sprawl. You have many clients, each good at running one session: Claude Code, Codex, Gemini, Cursor, Windsurf. You have many providers, each with its own accounts, quotas, and peak-hour throttling. And you have long jobs spread across terminals, branches, and machines. Today that sprawl is managed by hand, across a dozen terminal windows, with no crash recovery, no scheduling around the throttling, and no single place to see or steer the work. The moment the power blinks, the day is gone.
No layer owns this. LLM clients run one session well, but they don’t orchestrate many across processes, machines, accounts, and time. Memory tools remember and code tools verify, but neither dispatches. The orchestration layer is simply missing.
Arbiter is that layer. It is the OS-level orchestration brain that sits above your clients and beside your tools, and depends on none of them.
What it is
Arbiter is the muscle and the dispatcher. It is not an LLM client: it doesn’t run coding turns or assemble prompts. It dispatches the clients that do, and owns everything around them:
- Dispatch and supervise. Terminals, processes, git worktrees, work-groups, and sub-jobs, across Windows and modern Linux, from one command center.
- Apply routing policy. Configure capability, cost, and safety rules for the work you dispatch. Learned optimization remains under release hardening.
- Schedule around constraints. Schedule configured work around availability windows and account constraints.
- Use configured control surfaces. Supported messaging adapters, an HTTP control plane, editors, and MCP clients are available according to your setup.
- Account for interruptions. Power cut mid-run or reboot, and interrupted work is recorded for deliberate recovery.
One instruction in; the dispatching, the accounts, the timing, and the recovery handled underneath it:
$ arbiter run "refactor the auth module" --client claude-code --worktree
run f3a1 routed → configured tier (policy selected)
run f3a1 deferred → off-peak window (acct-2 quota in 34m)
run f3a1 running worker 48211 · managed worktree
# power cut, machine reboots
$ arbiter hydrate
run f3a1 suspended state preserved, operator action required
[ok] 1 interrupted run accounted for, 0 lost
The headline: an outage does not become a mystery
The thing that ends most long AI sessions is not a bug. It’s an outage: a reboot, a dropped connection, a blink in the power, and a day of in-flight work evaporates because nothing was holding it.
Arbiter holds the durable record. After a restart, arbiter hydrate accounts
for interrupted jobs, preserves their state, and marks them suspended for
deliberate operator recovery. Nothing disappears or pretends to still be
running.
Agnostic by construction
The promise we hold ourselves to: Arbiter builds and runs with zero providers and zero sibling tools, and gets sharper as you add them. Swap any client or provider out and it still runs. Bring all of them and it coordinates the lot. If Arbiter only had value when you ran the whole stack, it would have failed its own test. So standalone value comes first, and every integration is additive, never load-bearing.
That agnosticism is the whole point. You shouldn’t have to marry a vendor to get orchestration. You bring the clients and accounts you already use; Arbiter is the dispatcher above them.
Where this stands
Arbiter is a proprietary working alpha in IP hardening, licensing, and public binary packaging preparation. What you read here describes a running product, not a claim that a generally available binary can be installed today.
We’re also not collecting emails until there’s something real to hand you. No waitlist theater. The honest way to follow along is this blog and its RSS feed, where the build gets written up as it happens: how recovery handles a hard kill, how routing policy is made visible, how the scheduler reads constraints, and what it takes to keep all of it agnostic.
Follow the public release channel and this journal for availability.