bitrouter

BitRouter

An open-source, context-aware model router that learns and adapts to your agent workflows.

You're tokenmaxxing in production. Every step of every loop bills at frontier prices — file reads, tool calls, sub-agent hops, retries. Most don't need it. BitRouter routes each call, tool, and agent to the cheapest path that still reaches the goal, and tightens that routing as the loop runs.

Works with any harness, any model, any loop. Cost is live today — latency and accuracy are next.

One gateway for everything the loop consumes

BitRouter routes model calls. But which model a call should get depends on where the loop is — and the loop step is the last tool, skill, or sub-agent it touched. So the same gateway that governs those is what gives the router its context. Other routers see only the first of these three:

• Models — route LLM calls across providers, accounts, and wire protocols: OpenAI Chat Completions, OpenAI Responses, Anthropic Messages, and Google Gemini. (the classic router, cross-protocol — any request format to any upstream, and back)
• Capabilities — an MCP gateway that carries both tools and skills: skills ride the MCP skills extension (SEP-2640) over MCP Resources, so tools and skills are one governed, routable namespace instead of hardcoded endpoints. (Skills transport is unstable while SEP-2640 is in review.)
• Agents — an ACP gateway: sub-agents become first-class routable primitives, so a task can go to the sub-agent that best fits the loop's objective — just as a call routes to the best-fit model. (Local sub-agents over stdio today; remote gateways arrive with ACP v2.)

Optimizing a loop isn't just model selection — it's choosing the model, the tool, and the sub-agent that best serve the loop's objective at every step that gets it to its goal.

The self-improving loop

BitRouter wraps your agentic loop in a second loop. bitrouter.yaml declares providers, presets, and whether the process may publish; policy-lock.yaml is the only live route authority. The routing key is context-aware and lives as code: it is the step in the loop, not just the model name.

policy:
  path: ./policy-lock.yaml
  mode: adaptive                 # authorizes explicit publication only
presets:
  auto:
    model: openai-codex:gpt-5.6-sol
    policy: auto

The v3 lock behind bitrouter/auto contains the tier targets, canonical agent_trace routes, capability guardrails, and a decision certificate for every explicit route. A target may be a scalar model or an exact (model, effort) pair; bitrouter/auto:cost selects the cost variant when one is defined, while explicit physical model IDs remain passthrough.

Against that spec BitRouter provides the control plane for an act → observe → evaluate → improve cycle:

• Act — the router reads the lock and rewrites each @preset[:variant] call to its tier's model: policy routing, cross-protocol translation, multi-account failover.
• Observe — telemetry attributes every hop with cost, tokens, latency, and outcome, exported as OpenTelemetry traces and metrics to any OTLP backend.
• Evaluate — the generic eval exchange lets task-native tests, humans, enterprise systems, or an external agentic judge submit the same versioned outcome contract. BitRouter admits, disputes, and snapshots evidence; it does not pretend one bundled judge is universal.
• Improve — the policy compiler turns a frozen admitted-evidence snapshot into a deterministic, certificate-backed policy-lock.yaml candidate (an npm-style manifest/lock split, git-owned). Review and publication are explicit; the evidence database never changes a live route.

You choose what the external evaluator measures — cost, latency, quality, or a private objective — while the active lock remains the only authority for live policy routing. BitRouter adapts by proposing a new lock, never by mutating the one in force: the live route never changes implicitly between publications, and every change is a diff you can read and revert.

Benchmarks

Today cost is the validated objective: on Terminal-Bench 2.1, gpt-5.5 with BitRouter cut cost 32.8% at near-parity accuracy (−1.1 pp), by offloading routine steps to a cheaper model. Latency and accuracy objectives — and more base models — are landing next.

Base model	Cost vs baseline	Latency vs baseline	Accuracy vs baseline
gpt-5.5	**−32.8%**¹	coming soon	coming soon
gpt-5.6	coming soon	coming soon	coming soon
claude-opus-5	coming soon	coming soon	coming soon
claude-sonnet-5	coming soon	coming soon	coming soon
claude-fable-5	coming soon	coming soon	coming soon

¹ Cost-optimization run on Terminal-Bench 2.1: −32.8% zero-cache imputed cost (audited range 28.6–32.8% by cache share) at near-parity accuracy, −1.1 pp (76.1% vs 77.3%, within single-attempt noise).

This is a mechanism study under a modified protocol, not a Terminal-Bench leaderboard submission — read the experiment limitations before citing the numbers. Full reports live in benchmarks/; complete traces, tool calls, usage, policy decisions, configs, and checksums are in the BitRouterAI/benchmarks dataset.

Comparison

Automatic model selection is no longer the differentiator — every router below picks a model for you. What separates them is what the decision reads and whose data makes it better. Almost all of them classify the prompt. BitRouter routes on the loop step — where the agent is in its trajectory, keyed by the last tool it called — and improves from evaluations you admit, into a lock file you own.

	BitRouter	OpenRouter Auto	Not Diamond Code	vLLM Semantic Router	LiteLLM Auto
Routing signal	The loop step — last tool called, over the agent trace	Prompt classified into ~30 task types	Session state, token counts, task complexity, KV-cache state	Prompt signals: classifiers, embeddings, keyword and metadata rules	Prompt embedding similarity to labeled example routes
Improves from	Your admitted evaluation outcomes, per loop	The community's last-7-days spend across all of OpenRouter	Your implicit accept/reject feedback, in a hosted model	Router models you train offline and redeploy	Labeled examples plus one fitted score threshold
Optimizes	Any objective you submit (cost validated today)	Cost tier vs. capability	Cost and quality jointly	Quality, cost, latency, privacy, safety	Cost vs. quality at a chosen threshold
Policy you own	Git-owned policy-lock.yaml — readable, diffable, explicit publish	Vendor-side, tunable by knobs	Vendor-side	Config recipes plus trained artifacts	Proxy config plus fitted threshold

OpenRouter Auto and Not Diamond are hosted services. BitRouter, vLLM Semantic Router, and LiteLLM are open-source and self-hostable; BitRouter is Rust.

Install

# macOS / Linux
curl --proto '=https' --tlsv1.2 -LsSf https://github.com/bitrouter/bitrouter/releases/latest/download/bitrouter-installer.sh | sh

# Homebrew
brew install bitrouter/tap/bitrouter

# npm
npm install -g bitrouter

cargo install bitrouter

Quick Start

BitRouter is a local proxy between your agent and every LLM provider. One env-var swap — no harness changes required:

- OPENAI_BASE_URL=https://api.openai.com/v1   # hardwired to one provider, no fallback
+ OPENAI_BASE_URL=http://localhost:4356/v1    # all providers, automatic failover

CLI

BitRouter runs as a local daemon — start it with your own keys or a Cloud sign-in.

Bring your own keys (BYOK) — auto-detected from the environment, no config file needed:

export OPENAI_API_KEY=sk-...    # ANTHROPIC_API_KEY / GEMINI_API_KEY also work
bro start                 # proxy running at http://localhost:4356

Or sign in to BitRouter Cloud — use browser OAuth interactively or store an existing API key in CI:

bro cloud login           # RFC 8628 device flow against api.bitrouter.ai
bro cloud login --api-key "$BITROUTER_API_KEY"  # non-interactive CI login
bro start                 # `bitrouter` provider auto-enables once signed in

The same credential also drives a gh api-style raw client—no daemon required:

bro cloud api /v1/models
bro cloud api /v1/chat/completions --input request.json

Point your agent runtime at http://localhost:4356 and any available provider is live. For advanced routing rules, guardrails, or multi-account failover, scaffold a config with bro init (writes ./bitrouter.yaml).

bro start / stop / restart        # daemon lifecycle
bro requests                      # settled requests + spend
bro route <model>                 # trace how a model name resolves
bro key sign --user <id>          # mint a scoped brvk_ API key
bro cloud keys list               # manage API keys
bro cloud usage                   # inspect spend and tokens
bro cloud billing balance         # check credits
bro cloud api /v1/models          # call Cloud APIs directly

See docs/CLI.md for the full command reference, flags, and config resolution.

Agent Skill

BitRouter ships an Agent Skill — /bitrouter — so AI coding agents can install, configure, migrate to, and troubleshoot BitRouter on their own. It lives in this repo at skills/bitrouter/, kept in sync with the code.

npx skills add bitrouter/bitrouter    # via the generic skills CLI
# ...or add this repo as a plugin marketplace in Claude Code / Codex

MCP

BitRouter OSS is an MCP client and gateway: it proxies configured upstream MCP servers, aggregates their capabilities at /mcp, and can execute selected upstream tools inside an LLM request loop. Local agents operate BitRouter itself through the shipped Agent Skill and structured bro commands.

bro mcp check                    # check configured upstream MCP servers

API