Migrating from LiteLLM to BitRouter

LiteLLM is a Python SDK and self-hosted proxy for unifying access to a broad set of 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 with BYOK or as a hosted endpoint. 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 api.bitrouter.ai for production (or vice versa) without changing client code. The CLI, onboarding wizard, and Agent Skill support both modes. See the Quick Start for both flows.

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, and an admin UI all included. BitRouter inverts the emphasis: agent primitives are the product, and 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 adapters — interactive, headless, and stdio surfaces for Agent Client Protocol harnesses.
• Guardrails — regex rules on the proxy hop that redact or block matching content inline.
• Cloud Tracing — built-in spend and request tracing, no external collector required.
• Agent Skill — install BitRouter operating knowledge into the agent host; the host remains responsible for approval and execution.
• CLI — interactive onboarding plus structured commands for setup and operations.

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, 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: `bro start` (BYOK via env vars) — see /docs/overview/quickstart
# Cloud: base_url="https://api.bitrouter.ai/v1", api_key=$BITROUTER_API_KEY
client = openai.OpenAI(
    base_url="http://127.0.0.1:4356/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 virtual models and model fallback rules — declared once in bitrouter.yaml, not per call site.

From the LiteLLM Proxy

For a basic single-host route, the proxy migration can replace the Python service with one binary. Persistent BitRouter features use SQLite by default, or Postgres/MySQL when you configure them. 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 Quickstart)
curl --proto '=https' --tlsv1.2 -LsSf \
  https://github.com/bitrouter/bitrouter/releases/latest/download/bitrouter-installer.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 :4356
bro

To skip the local proxy entirely, point clients at https://api.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, two gaps are worth checking before you start.

Non-chat endpoints. LiteLLM covers embeddings, rerank, audio, and image endpoints across a broad provider set. BitRouter deliberately ships deep support for agentic chat models and extends by PR to the model and provider registry. If your workload leans on embeddings or rerank today, either implement and verify that endpoint first or keep those calls on LiteLLM.

Team administration. BitRouter does not ship a team-admin UI at parity with LiteLLM Enterprise. Cloud credentials are workspace-scoped, and a self-hosted daemon can enforce allowed models, budgets, and rate limits through DB-backed brvk_ virtual keys. If your migration depends on delegated key administration, SSO, audit workflows, or a mature spend dashboard, 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