Migrating from LiteLLM to BitRouter

LiteLLM is a Python SDK and self-hosted proxy for unifying access to 100+ LLM providers. BitRouter solves the same problem from a different angle: an agent-native proxy with a single OpenAI-compatible surface — runnable as a local binary (BYOK, no infra) or as a hosted endpoint with autonomous agent payments. This guide is for teams whose workload has shifted from backend services to agent runtimes and want a leaner, agent-first surface.

Why migrate?

Two things worth highlighting

1. Cloud and local share the same surface

With LiteLLM, the proxy is something you operate. With BitRouter, the hosted cloud and local binary expose the same OpenAI-compatible endpoint — you can start local during development, then point at cloud.bitrouter.ai for production (or vice versa) without changing client code. The CLI, the wizard, and Agent Skills all work in either mode; toggle with one keypress in the setup TUI. See the Quick Start for both flows.

This matters when your agent should pay per request without you provisioning keys for it — Cloud mode supports x402 / MPP autonomous payments, which LiteLLM has no equivalent for.

2. Agent-native, not all-in-one

LiteLLM has shipped MCP, A2A, Skills, and a CLI alongside its horizontal LLM gateway — virtual keys, team budgets, spend dashboards, admin UI all included. BitRouter inverts that: agent primitives are the product, the team-admin stack is intentionally minimal. What you get on the BitRouter surface:

• MCP gateway — proxy MCP servers so agents discover tools across hosts.
• ACP gateway — first-class support for the Agent Client Protocol used by Claude Code, Codex, OpenCode, and others.
• Guardrails — agent firewall on the proxy hop: inspect, redact, or block inline.
• Observability — built-in spend and request tracing, no external collector required.
• Agent Skills gateway (coming soon) — install and route capabilities by skill, not by raw model name.
• Headless CLI — TUI wizard plus scriptable commands for setup and ops.
• Agentic auth & payment — x402 / MPP so an agent can pay per request without you provisioning a key for it. LiteLLM has no equivalent.

If you depend on LiteLLM's team-admin UI, virtual keys, and per-user budgets, LiteLLM is still the better fit. If you're building agents — especially agents that should transact autonomously — BitRouter is.

Migration paths

From the LiteLLM Python SDK

LiteLLM as a library becomes a BitRouter base URL swap on the standard OpenAI SDK:

from litellm import completion

response = completion(
    model="openai/gpt-4o",
    messages=[{"role": "user", "content": "Hello"}],
    api_key="sk-...",
)

import openai

# Local: `bitrouter` (BYOK via env vars) — see /docs/guides/overview/quickstart
# Cloud: base_url="https://cloud.bitrouter.ai/v1", api_key=$BITROUTER_API_KEY
client = openai.OpenAI(
    base_url="http://localhost:8787/v1",
    api_key="not-used-in-local-byok",
)

response = client.chat.completions.create(
    model="openai/gpt-4o",
    messages=[{"role": "user", "content": "Hello"}],
)

Fallbacks and provider selection that you'd configure with litellm.Router move into BitRouter's routing presets and model fallback rules — declared once, not per call site.

From the LiteLLM Proxy

The proxy migration replaces the Python process + Postgres + Redis with a single binary. Install and launch:

docker run -d -p 5432:5432 -e POSTGRES_PASSWORD=pass postgres
docker run -d -p 6379:6379 redis
pip install 'litellm[proxy]'
litellm --config config.yaml --port 8000

# Install (curl, npm, brew, or cargo — see Quick Start)
curl -fsSL https://bitrouter.ai/install.sh | sh

# Set provider keys; BitRouter auto-detects on start
export OPENAI_API_KEY=sk-...
export ANTHROPIC_API_KEY=sk-ant-...

# Interactive wizard (Cloud or local); default local serves on :8787
bitrouter

To skip the local proxy entirely, point clients at https://cloud.bitrouter.ai/v1 with a BitRouter API key — no binary, no infra. Same endpoint shape.

Feature mapping

What BitRouter intentionally doesn't ship

To set expectations honestly: BitRouter does not ship a built-in admin UI for team/user budgets, virtual-key generation by API, or a spend analytics dashboard at parity with LiteLLM Enterprise. Per-workspace key scoping in cloud mode and env-var-scoped keys in local mode cover the common cases, but if your migration depends on per-user virtual keys with quotas enforced inside the proxy, plan for that gap or stay on LiteLLM for those workloads.

Migration checklist

Next steps

Get help

• Discord: Join the community for migration support
• GitHub: Open an issue
• Email: contact@bitrouter.ai for enterprise migration assistance