Migration

Migrating from LiteLLM to Busbar

If your app already talks to a LiteLLM proxy, it's already speaking OpenAI-shaped HTTP to a base_url. Busbar is OpenAI-compatible on the same routes (/v1/chat/completions, /v1/messages, and more), so for most teams migration is a single line: point your SDK's base_url at Busbar instead of the LiteLLM proxy. Nothing about your request bodies changes. The difference is what sits behind that URL: one static Rust binary you run in your own infrastructure, with a fault-attributed circuit breaker, in-flight failover, and lossless translation across six wire protocols. Every claim about LiteLLM below is cited to their own documentation; every claim about Busbar is ours.

The change

A LiteLLM proxy serves on http://0.0.0.0:4000 by default, and you point an OpenAI client at it [1]. Busbar serves on :8080. So the migration is usually this:

# Before — pointing at a LiteLLM proxy
client = openai.OpenAI(
    api_key="anything",
    base_url="http://0.0.0.0:4000",   # LiteLLM proxy
)

# After — pointing at Busbar
client = openai.OpenAI(
    api_key="unused",                 # or a Busbar virtual key, if governance is on
    base_url="http://localhost:8080", # Busbar
)

The model string in your request stays a name you control — you map it to a provider and model in Busbar's config.yaml, exactly as you mapped it in LiteLLM's model_list. No request body changes, no SDK swap.

Config mapping

What you gain by moving

• A real circuit breaker, not a cooldown timer. LiteLLM maps failures into an exception hierarchy that feeds retry counts and a cooldown_time; a deployment returns when the timer expires [4]. Busbar attributes fault: a provider outage trips the lane and honors Retry-After; an auth or billing failure benches the key with a sticky cooldown; a client's bad request is relayed verbatim and never penalizes a healthy lane; a context-length overflow fails over to a larger-context lane without recording a fault. The full state machine.
• In-flight, mid-stream failover. A failing request reroutes to the next lane before your client sees a single byte, even on a streaming request — not a retry after the failed call returns [4].
• Lossless six-protocol translation. All six wire protocols (OpenAI, Anthropic, Gemini, Bedrock, Cohere, Responses) are first-class in both directions through one superset intermediate representation, so an OpenAI SDK can reach an Anthropic backend and a signed Bedrock SDK can reach a non-Bedrock one, each getting its own native response.
• One static binary. No Python interpreter, no PostgreSQL, no Redis. LiteLLM's production guide runs Uvicorn workers with PostgreSQL [5], and shares cooldown state across instances via Redis [4]. Busbar is a single Rust binary and a YAML file; governance state, when you turn it on, is embedded SQLite.

Honest gotchas / what to check

• No bundled admin UI. LiteLLM ships a dashboard; Busbar exposes Prometheus, OTLP, and an admin API and expects you to point your existing dashboards at it. If the LiteLLM UI is load-bearing for your team, budget for wiring up Grafana.
• The in-process Python library is a different tool. If you import litellm inside your code rather than running the proxy, that's LiteLLM's home turf and there's no drop-in Busbar equivalent — Busbar is a network service. The proxy is what maps cleanly.
• Provider entries may need typing. LiteLLM ships 100+ preconfigured providers. Busbar ships a curated verified catalog plus anything speaking one of the six protocols, which you add in a few lines of providers.yaml [6]. A provider whose wire format is none of the six needs new translator code — the one case where you'd wait on us.
• Callbacks / custom hooks don't port 1:1. LiteLLM's Python callbacks and custom guardrail plugins have no line-for-line Busbar analog; map them to Busbar's governance, auth chain, and telemetry, or keep them app-side.
• Model names are yours to re-declare. The model strings your clients send must exist in Busbar's models section. Copy them over from your model_list so the request bodies keep working unchanged.

Convert your config.yaml

Paste your whole LiteLLM config.yaml — model_list, router_settings (including fallbacks), and general_settings — and get a Busbar config.yaml starting point: providers, models, failover pools, and a breaker. It runs entirely in your browser; nothing is sent anywhere. Review the result against the config docs (a custom base_url for a known provider lives in providers.yaml; the shipped catalog already carries protocol + base URL).

Next steps

Build a config to generate your config.yaml from your provider list, read Busbar vs LiteLLM for the full architectural comparison, or get started in five minutes.

References

Facts about LiteLLM checked against docs.litellm.ai on July 18, 2026. If something here is out of date, tell us and we'll fix it.

1. LiteLLM proxy client usage: default http://0.0.0.0:4000 base URL and OpenAI SDK example.
2. LiteLLM proxy config: model_list, litellm_params, callbacks, and the admin UI.
3. LiteLLM virtual keys: budgets, budget duration, TPM/RPM and parallel-request limits, and the PostgreSQL requirement via DATABASE_URL.
4. LiteLLM routing and fallbacks: retry-based fallbacks, allowed_fails, cooldown_time, and Redis for cross-instance cooldown state.
5. LiteLLM production guide: Uvicorn workers and PostgreSQL.
6. Busbar getting started: config.yaml, providers.yaml catalog, virtual keys via the admin API, and observability endpoints.
7. Busbar circuit breaker: fault attribution, per-lane state, and in-flight failover.