> Arbiter / blog
· announcement

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.