FAIRVISORFairvisor vs. LiteLLM
The Situation
LiteLLM is an LLM proxy: model routing, unified API compatibility, and provider abstraction.
Fairvisor is an enforcement layer: rate limits, budgets, loop controls, and policy actions before requests hit upstream models.
Comparison
| Capability | Fairvisor | LiteLLM |
|---|---|---|
| Primary function | Edge enforcement (rate limiting, budgets, protection) | LLM proxy (unified API, model routing) |
| 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 need strict enforcement controls, not only request routing.
- You need cost budgets, staged actions, and loop prevention.
- 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