If you're building with LLMs, you've probably dealt with managing multiple API keys, handling provider outages, and normalizing different API formats. AI gateways solve this by providing a unified layer between your app and model providers.
Here's a practical comparison of the main options.
What Does an AI Gateway Do?
An AI gateway sits between your application and LLM providers. It handles:
- API normalization — One format for all providers
- Key management — One key instead of many
- Failover — Auto-switch when a provider goes down
- Cost tracking — Unified billing and analytics
- Load balancing — Route across providers or regions
The Contenders
OpenRouter
The largest AI model aggregator. 400+ models, established ecosystem.
Strengths:
- Widest model selection (400+)
- Strong ecosystem — many tools integrate natively
- OAuth support for end-user auth
- Model rankings and community ratings
Weaknesses:
- 5–15% markup on provider pricing
- Shared infrastructure can bottleneck during peak
- No built-in failover between providers
- Rate limits on free tier
Best for: Developers who want maximum model variety and don't mind paying a premium.
LiteLLM
Open-source gateway with 44K+ stars. Self-hosted or cloud.
Strengths:
- Free and open-source (MIT)
- 100+ providers supported
- Full infrastructure control
- Budget management, RBAC (enterprise)
- Used by NASA, Netflix
Weaknesses:
- Self-hosting requires DevOps effort
- No SLA unless you build your own
- Configuration can be complex
- Enterprise features require paid tier
Best for: Teams with DevOps capacity who want full control.
Portkey
Enterprise-focused gateway with observability.
Strengths:
- Best monitoring and tracing
- Guardrails and prompt management
- Multi-team governance
- 200+ model support
- a16z backed
Weaknesses:
- Complexity overhead for simple use cases
- Higher cost at scale
- Steeper learning curve
Best for: Enterprise teams prioritizing observability and governance.
FuturMix
Lightweight gateway focused on cost and reliability.
Strengths:
- 20–30% cheaper than OpenRouter
- 99.99% SLA with automatic failover
- Dual-format support (OpenAI + Anthropic native)
- Zero data retention
- Works with Claude Desktop Developer Mode
Weaknesses:
- Smaller model catalog (22+ vs 400+)
- Newer service, smaller ecosystem
- No self-hosting option
Best for: Developers who want cost savings and reliability with major models.
Side-by-Side Comparison
| Feature | OpenRouter | LiteLLM | Portkey | FuturMix |
|---|---|---|---|---|
| Models | 400+ | 100+ | 200+ | 22+ |
| Pricing | Provider + 5-15% | Free OSS | Free tier + usage | Provider - 20-30% |
| SLA | None published | Self-managed | 99.99% | 99.99% |
| Failover | Manual | Config-based | Built-in | Automatic |
| Self-host | No | Yes (MIT) | No | No |
| Observability | Basic | Prometheus/Grafana | Advanced | Basic |
| Data retention | Yes (optional) | Your control | Configurable | None |
| OpenAI compatible | Yes | Yes | Yes | Yes |
| Anthropic compatible | No | Yes | No | Yes |
Code Comparison
All four support the OpenAI SDK. Switching between them is a one-line change:
from openai import OpenAI
# OpenRouter
client = OpenAI(
base_url="https://openrouter.ai/api/v1",
api_key="sk-or-..."
)
# LiteLLM (self-hosted)
client = OpenAI(
base_url="http://localhost:4000/v1",
api_key="sk-litellm-..."
)
# Portkey
client = OpenAI(
base_url="https://api.portkey.ai/v1",
api_key="pk-..."
)
# FuturMix
client = OpenAI(
base_url="https://futurmix.ai/v1",
api_key="sk-fm-..."
)
# Same call works with all of them
response = client.chat.completions.create(
model="claude-sonnet-4-5-20250929",
messages=[{"role": "user", "content": "Hello"}]
)
Decision Framework
Choose OpenRouter if you need access to niche or open-source models and don't mind the markup.
Choose LiteLLM if you have DevOps capacity and want full control over your gateway infrastructure.
Choose Portkey if you're an enterprise team that needs detailed observability, guardrails, and governance.
Choose FuturMix if you primarily use Claude/GPT/Gemini and want the lowest cost with high reliability.
The Hybrid Approach
Some teams use multiple solutions:
- LiteLLM as the primary self-hosted gateway for development
- A managed gateway (FuturMix/Portkey) as production fallback
- OpenRouter for experimentation with new models
This gives you cost control, reliability, and flexibility.
What gateway setup are you using? I'm curious about real-world architectures. Share in the comments.
Top comments (0)