> Arbiter / blog
· local-llm, orchestration, performance

Arbiter's local brain just got more room to think

The on-device model that runs Arbiter's orchestration was upgraded. It now holds more of your operation at once and returns results in a shape you can rely on, all without a cloud call in the decision path.

Arbiter has always kept its own reasoning local. The model that decides how to route a task, triages incoming work, and runs the operations chat lives on your GPU, not in someone’s cloud. We wrote about why that matters in Arbiter’s brain runs on your GPU. The principle has not changed. The brain behind it just got a meaningful upgrade.

More of your operation, held at once

The most useful thing a bigger working context buys an orchestrator is memory of the situation. The local brain can now hold more of your operation in view at one time: more projects, more recent runs, more of the conversation you have been having with it about what to do next. That means fewer moments where it loses the thread and has to be reminded what you were doing. An orchestrator that forgets the state of the operation halfway through a decision is not much of an orchestrator. This one has more room before it runs out.

No cloud hop, on the same card

Every route, every triage, every reply to an ops question waits on this model, so where it runs matters. It runs on your own hardware, in the decision path, with no cloud round-trip between a question and an answer. And with the larger working context, it now has far more room before a long turn overflows and has to be retried, which is where the old stalls came from. We are keeping card-specific numbers off this page on purpose, but the direction is plain: the reasoning layer stays out of your way, and it did not need a bigger GPU to get there.

Answers in a shape you can rely on

An orchestrator does not just need good answers. It needs answers in a form the rest of the system can act on without guessing. The upgraded brain returns its structured results in a dependable shape, so a routing decision or a status summary comes back as something the daemon can use directly rather than something it has to parse hopefully and recover from when the format drifts. Fewer malformed answers means fewer silent stalls, which is exactly the kind of reliability an always-on coordination layer lives or dies on.

Still yours, still local

None of this moved the reasoning off your machine. The decision path still makes no cloud call, the model still installs onto your own GPU, and the same resident brain is there for the rest of the ecosystem to borrow. Curator already reroutes its own inference through Arbiter, so one model on the card can serve every app that needs it instead of each one loading its own. A better brain, in the same place, on the same terms.

Where it stands

The upgraded local brain runs in Arbiter’s working proprietary alpha, alongside the routing, supervision, and recovery it powers. It is the layer that dispatches Warden, orchestrates TheAuditor, and answers to BenchProctor for proof.

Arbiter is a proprietary working alpha in public binary release preparation. Follow the public release channel or RSS feed for updates.