Arbiter's brain runs on your GPU
Provider-agnostic shouldn't stop at the providers. Arbiter's routing decisions are made by a local model on your own hardware, with no cloud call in the decision layer and no vendor to depend on.
It is easy to call yourself provider-agnostic when you pool a few API keys. It is harder once you notice that the thing choosing which provider to use is itself a call to one of them. An orchestrator whose own brain lives in someone’s cloud is not neutral. It just moved the lock-in one layer down.
Arbiter’s brain runs on your machine. The model that decides how to route a task is a small local model on your own GPU, installed with a single setup command. After that, the decision layer makes no network call at all.
What the local brain does
Two jobs, both on-device:
- Routing triage. When a task arrives without an explicit class, the local model reads it and classifies it, and that classification picks the route: which capability tier, which provider, which model.
- Direct inference. Work that does not need a frontier cloud model can run against the local brain directly.
That is the scope, stated plainly. The brain triages and answers. It does not grade another model’s output or sign off on risky actions. Those are settled by explicit rules rather than an LLM’s opinion, and every routing decision Arbiter makes is recorded with the reasons behind it, so the path a task took is auditable after the fact instead of a black box.
A risk floor the optimizer cannot cross
Cost optimization is good right up until it routes something destructive to the cheapest, weakest model. Arbiter draws a hard line. Irreversible and destructive operations are never sent to the cheapest tier, and they are flagged for approval. The cost optimizer is not allowed to override that floor, so “spend less” and “never route a destructive action carelessly” hold at the same time, by construction.
Bring your accounts; it routes around the walls
Arbiter pools the LLM accounts you already have, across Anthropic, OpenAI, and Gemini, and when one hits a rate limit or exhausts its quota, work reroutes to another with headroom instead of failing. It runs with zero providers too. The local brain and shell work need none, and every provider, client, or sibling tool you add only makes it sharper, with nothing load-bearing. A background daemon and a native desktop GUI talk over local IPC, with no inbound network port opened.
Where it stands
Arbiter is in active development and not shipping yet, with no semver promises before v1.0. The design that stays agnostic all the way down to a local decision brain is the part we will not compromise.
It is the layer that dispatches Warden across providers and orchestrates TheAuditor’s analysis, alongside Curator and BenchProctor. The full scope is in Introducing Arbiter, or follow the RSS feed.