What is BitRouter?

BitRouter is a context-aware LLM router that continuously improves your agent workflows. It takes model selection off your plate without taking it out of your hands: send bitrouter/auto, and every call in the loop is matched to a model against the objective you set — from a routing policy that lives in your repo, that you read, review, and can override line by line.

A frontier release lands every few weeks, and each one moves the cost, latency, and accuracy frontier somewhere different. Nobody re-benchmarks a whole agent that often, so the choice has been to pin one frontier model and overpay on every trivial step, or hand-tune a table that's stale a month later. BitRouter is the third option: a router that keeps re-testing the frontier for you, scored against your workload instead of a public leaderboard.

On Terminal-Bench 2.1, routing an agent through BitRouter cuts total run cost by roughly 30%.

One model id replaces every model decision

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

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

Explicit model ids stay passthrough — openai/gpt-5 still means openai/gpt-5, so you can always pin a call the router shouldn't touch. The vendor/auto shape is deliberately the one other gateways already use: a config pointing at some other .../auto only needs its vendor segment changed.

What differs is what happens after the request lands. A classifier-based router makes an opaque per-prompt guess you can't inspect. BitRouter projects each request onto where it sits in the agent's trajectory and how much risk it carries, then resolves that projection through a signed policy file you own — ordinary edit and test work to economy, read-only review and long-context execution to balanced, anything guarded or unrecognized to strong. Risk is scored apart from the work itself: eight prior assistant action turns raises expected redo risk, and an observed execution failure stays guarded through the next two execution observations, so a model-induced loop can't quietly keep buying cheap tokens.

Because bitrouter/auto resolves against a policy, it needs one bound before first use — an unbound install reports the missing binding rather than guessing a route.

Your production traffic is the training signal

Other routers are tuned once, offline, on somebody else's benchmark. Observability tools show you your own numbers, then leave you the homework of re-tuning the config. BitRouter closes the loop: it trials cheaper routes on live traffic, scores what came back, and updates the policy from the result — act → observe → evaluate → learn:

• Act — the router. Each model, tool, and agent call is rewritten to a chosen route: policy-table routing, cross-protocol translation, multi-account failover.
• Observe — telemetry. Every hop is attributed with cost, tokens, latency, and outcome.
• Evaluate — the reward. Each served request is classified by outcome against the route that served it, deterministically and with no LLM judge in the path.
• Learn — the policy engine. Downgrades that keep succeeding qualify for the cheap tier; ones that fail pin back up.

The evidence rule is asymmetric on purpose: one hard failure escalates immediately, while a cheaper route has to succeed repeatedly before it earns the traffic. It optimizes for cost today; latency and accuracy are next. What it learns lands in a lock file next to your config, and the router never publishes it without you — you read the diff and commit it, so the improved policy ends up in Git where a policy belongs.

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.

Out of the box bitrouter/auto routes on general evidence. Optimizing replaces that with evidence from your workflow: you name the command that exercises your agent and write a success contract describing a good run, and BitRouter runs that command twice — once as-is, once with exactly one routing change — then compares cost and quality. One variable, measured on your code, against your definition of good. It is not "swap in a cheaper model."

Nothing moves until you say so: review reports the deltas, publishing is a separate explicit action, and a bad call rolls back by digest. The intent, the resolved identities, and the success contract are three files you own and commit — and the result serves under the same bitrouter/auto, so nothing in your application changes.

Scope isn't only models, either. A workflow's cost is its model calls plus its tool definitions plus its sub-agents, so all three are routable and governed: an MCP gateway and an AgentSkills gateway turn tools and skills into routable resources instead of hardcoded endpoints, and an ACP gateway makes sub-agents first-class routable primitives.

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