# Fairvisor vs. LiteLLM

URL: https://fairvisor.com/compare/litellm/

---


 Fairvisor vs. LiteLLM See Fairvisor + LiteLLM architecture The Situation LiteLLM is an LLM proxy: model routing, unified API compatibility, and provider abstraction.
Fairvisor is a drop-in LLM endpoint: change your base URL and API key format — no SDK code changes — and your traffic gets enforcement applied transparently. Rate limits, cost budgets, loop controls, and policy actions before requests reach upstream models.
Comparison Capability Fairvisor LiteLLM Primary function Drop-in LLM endpoint with enforcement (rate limits, budgets, protection) LLM proxy (unified API, model routing) Drop-in deployment Yes — change base URL + API key format, no SDK changes Proxy/routing focus, not enforcement-first Runtime Lua/OpenResty-based edge runtime Python runtime Rate limiting Token bucket + cost-based + TPM/TPD Basic rate limiting Loop detection Yes No Circuit breaker Yes No Streaming enforcement Mid-stream termination Pass-through Multi-model routing No (not a proxy) Yes (100+ models) Cost tracking Enforcement + attribution Tracking only When to Use Fairvisor You want enforcement without touching application code — drop-in endpoint, change base URL only. You need cost budgets, staged actions, and loop prevention at the edge. You need policy decisions at edge speed before provider calls. When to Use LiteLLM You need multi-model routing and unified LLM API abstraction. You need provider fallback and routing strategy features. You mainly need proxy functionality, not advanced enforcement. Use Them Together Put Fairvisor in front as enforcement decision layer. Keep LiteLLM for model routing and provider abstraction. Combined flow: App -> Fairvisor -> LiteLLM -> model providers. Your App -> [Fairvisor Edge] -> [LiteLLM Proxy] -> OpenAI / Claude / Gemini Routing and enforcement are different jobs See Fairvisor + LiteLLM architecture