> Arbiter / blog
· announcement

Introducing Arbiter: the orchestration layer your AI stack is missing

A provider-agnostic command center that dispatches and supervises your LLM clients, terminals, and long-running jobs. It routes each to the right model, schedules around throttling, and brings interrupted work back after a crash.

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.
  • Route to the right model. Every job lands on the model that fits it, and it refuses to overpay when a cheaper tier is just as capable.
  • Schedule around throttling. Defer runs to dodge peak-hour throttling and quota walls, and move work onto whichever account still has headroom.
  • Drive it from anywhere. Steer or stop any run from your phone over Signal, Telegram, or WhatsApp, from an HTTP control plane, your editor, or an MCP client.
  • Survive the crash. Power cut mid-run, reboot, and the interrupted jobs come back.

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    → opus            (sufficient for this job)
  run f3a1  deferred  → off-peak window  (acct-2 quota in 34m)
  run f3a1  running   worker 48211 · worktree wt/auth
  -- power cut · machine reboots --

$ arbiter hydrate
  run f3a1  recovered  resumed from checkpoint, worker re-attached
  [ok] 1 run resumed, 0 lost

The headline: it passes the power-cut test

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 it. Runs are checkpointed as they go, so after a restart a single arbiter hydrate brings interrupted jobs back, resumed where they left off or cleanly marked if they can’t be. Recovery isn’t a feature you remember to turn on. It’s the default posture of the whole system. Nothing silently fails, and every run ends in a known state.

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

We’re going to be honest about status, because that’s the culture this is built in: Arbiter is in active development. The architecture is laid down, the plan is public-facing, and the work is underway, but it is not shipping yet. What you read here is what Arbiter is being built to do, described as plainly as we can. It is not a claim that you can install it 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 survives a hard kill, how routing decides without overpaying, how the scheduler reads the throttling, and what it takes to keep all of it agnostic.

Early access is opening soon. Until then, watch this space.