What is BitRouter?

BitRouter is a context-aware LLM router for agent workflows. In a self-hosted deployment, a configured bitrouter/auto router selects models using a policy you can inspect, review, and update from admitted evidence.

Model prices and capabilities change. BitRouter helps operators compare routes against their own workload and publish reviewed policy changes; evaluating a workload still requires an external evaluator or benchmark.

On a strict 80-task common-valid Terminal-Bench 2.1 comparison, an initial BitRouter configuration reached 81.25% task success versus 81.56% for a fixed strong-model baseline and 76.50% for same-pool random routing. Its frozen-price nominal API cost for accepted valid-path requests was 40.93% lower than the strong-model baseline. These are research results, not provider billing or an official leaderboard submission; review the data and protocol.

A self-hosted model id for policy routing

Two things change — the base URL, and the model you ask for:

curl http://127.0.0.1:4356/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model": "bitrouter/auto", "messages": [{"role": "user", "content": "..."}]}'

Explicit model ids select that model and can still use eligible provider fallback. Cloud accepts catalog model IDs and enabled workspace routing presets addressed as @<name>; its hosted endpoint does not use the local bitrouter/auto selector.

The local router can classify request context and resolve it against a versioned policy. Its configured tiers and explicit routes determine which model is selected; unmatched requests use the policy's default tier.

The local bitrouter/auto selector needs a bound policy before first use; an unbound install reports the missing binding. Follow the setup guide before sending the example.

Use traffic and evaluations as evidence

The self-hosted workflow combines routing with telemetry, evaluation, and explicit policy publication:

• Act — the router. Resolve eligible model routes and fall back on retryable failures.
• Observe — telemetry. Inspect available request, usage, cost, and outcome records.
• Evaluate — the objective. Submit results from an evaluator suited to the workload.
• Learn — the policy engine. Use admitted evidence to derive and review a candidate policy.

In alpha.33, the active lock controls request-time routes in both policy modes; legacy live adequacy learning is disabled. You can compile and review a candidate before publishing in adaptive mode. Running the optimizer is a separate authorization that can publish a controller transition.

It optimizes the workflow, not the request

Every other gateway's unit of optimization is the request: pick a model, return a response, done. BitRouter's unit is the workflow — the whole run, judged on whether it did the job you wanted.

For workflow-level evaluation, run a benchmark or evaluator appropriate to your task and admit its results into the evidence store. The evaluation guide explains the subject, result, and snapshot boundaries.

Use the compile and publish workflow to review a candidate before activating it. Policy rollback can restore an earlier lock by digest.

Scope isn't only models, either. A workflow's cost includes model calls, tool definitions, and the agent loops that generate them. The MCP gateway centralizes upstream tools; ACP adapters let the same router policy cover supported coding-agent sessions; and the BitRouter Skill gives shell-capable agents a maintained operational interface.

The Core is Apache 2.0 and free to self-host; Cloud adds managed providers and account-wide policies on top. Quickstart has the split.

Next steps