Provider-agnostic orchestration: why we don't lock you in
Why an orchestration layer should stay neutral about the models, clients, and accounts you bring to it.
Most “agent platforms” make a quiet assumption: that you’ve picked a vendor. One model family, one client, one account, and everything is built around it. It’s convenient right up until that vendor throttles you, raises prices, or has an outage, and you discover the platform has no idea what to do without them.
Arbiter is built on the opposite guarantee. It runs with zero providers, zero clients, and zero sibling tools, and gets sharper as you add any of them. That neutrality isn’t a feature bolted on. It’s the whole point.
What “provider-agnostic” actually buys you
Bring any LLM clients and any provider accounts you already have. Arbiter pools them and rotates around exhaustion and throttling, so a rate-limited account reroutes instead of killing your run. It schedules work to dodge peak-hour walls, and when something is interrupted it recovers rather than starting over. Every routing decision is auditable, and you can set hard rules the optimizer is never allowed to cross.
Swap a client or a provider out tomorrow and Arbiter still runs. Add all of them and it coordinates the lot. Integrations are additive, never load-bearing.
It pairs with the rest of the stack
Neutrality runs through the whole ecosystem. Warden executes across providers the same way, and TheAuditor gives every model the same deterministic ground truth no matter who’s serving the tokens. You’re never betting the workflow on a single vendor.
Where it stands
Arbiter is in active development, not shipping yet. The agnostic-by-construction design is the part we won’t compromise on. The full scope is in Introducing Arbiter, or follow the RSS feed.