Unified LLM API Providers and AI Gateway Comparison 2026: OpenRouter, LiteLLM, Portkey, Cloudflare, and TheRouter

The fastest answer: use OpenRouter when model marketplace breadth matters, LiteLLM when you want to self-host the proxy, Portkey when gateway policy and observability are the center of the project, Cloudflare AI Gateway when edge analytics and controls already sit in your stack, and TheRouter when you want an OpenAI-compatible endpoint with provider/model routing, fallback, and unified billing/accounting surfaces where implemented. The hard part in 2026 is not finding a gateway. It is choosing the control plane whose failure modes you actually want to operate.

OpenAI-compatible means a provider exposes a chat-completions endpoint whose request and response shape matches the OpenAI API contract closely enough that an unmodified OpenAI SDK call works against it after swapping three values: API key, base URL, and model name. The minimum surface in practice is POST /v1/chat/completions with messages, model, and an OpenAI-shaped streaming response.

Sources: OpenRouter Quickstart, retrieved 2026-07-25; OpenRouter Model Routing, retrieved 2026-07-25; LiteLLM Router docs, retrieved 2026-07-25; LiteLLM GitHub, retrieved 2026-07-25; Portkey Fallbacks, retrieved 2026-07-25; Portkey Gateway GitHub, retrieved 2026-07-25; Cloudflare AI Gateway, retrieved 2026-07-25; Cloudflare AI Gateway Features, retrieved 2026-07-25; TheRouter Quickstart, retrieved 2026-07-25; TheRouter Model Fallbacks, retrieved 2026-07-25.

TL;DR — Unified LLM API Gateways Compared

The table is deliberately operational rather than promotional. A gateway choice changes your incident response path, not just your SDK import.

What Counts as a Unified LLM API Provider?

A unified LLM API provider accepts one request shape, then routes it to one or more upstream model providers. Most teams standardize on the OpenAI Chat Completions shape because many SDKs and coding tools already expose a configurable base_url.

The minimum useful gateway does three things:

1. Normalizes the request path so clients do not need a separate SDK for each provider.
2. Routes across models or providers based on model name, fallback policy, cost, latency, health, or a manual rule.
3. Leaves an audit trail so operators can explain which upstream served a request, how much it cost, and why fallback did or did not happen.

If a product only proxies one provider and does not expose routing or fallback semantics, we would not treat it as a gateway for this comparison.

Integration: The Same OpenAI SDK Pattern

The integration pattern is similar across managed gateways: change the API key and base_url, then use provider/model-style model IDs.

import OpenAI from "openai";

const client = new OpenAI({
  baseURL: "https://api.therouter.ai/v1",
  apiKey: process.env.THEROUTER_API_KEY,
});

const completion = await client.chat.completions.create({
  model: "anthropic/claude-sonnet-4.5",
  messages: [{ role: "user", content: "Summarize this release note." }],
});

OpenRouter documents the same base-URL idea against https://openrouter.ai/api/v1; TheRouter documents https://api.therouter.ai/v1; LiteLLM and Portkey can expose OpenAI-compatible proxy endpoints; Cloudflare places gateway controls in front of supported providers. For a buyer, the question is no longer "can my SDK call it?" but "who owns the routing policy?"

Routing and Fallback: Where the Products Differ

OpenRouter separates model routing from provider routing. Its documentation describes explicit model fallback arrays, provider preferences, price ceilings, and default provider selection. That makes sense for teams that want a managed marketplace with many upstream routes.

LiteLLM exposes routing as infrastructure you can run yourself. Its router supports load balancing, retries, cooldowns, timeouts, fallbacks, and strategies such as rate-limit-aware, latency-based, least-busy, and lowest-cost routing. The trade-off is ownership: your team runs the proxy, Redis, secrets, and upgrade path if you self-host.

Portkey treats fallback as a gateway config. You define prioritized targets, optionally trigger fallback only on status codes such as 429 or 503, and trace fallback chains by config ID or trace ID. That is attractive when incident review and policy explanation matter as much as the request itself.

Cloudflare AI Gateway adds routing to the edge-control plane: analytics, caching, rate limits, spend limits, guardrails, DLP, dynamic routing, request retry, and model fallback. It is strongest when the application already uses Cloudflare controls and wants AI traffic governed beside the rest of the app.

TheRouter exposes an OpenAI-compatible API and documents model fallback through a models array plus provider-level controls such as allow_fallbacks. Our truthful claim is narrow: TheRouter routes OpenAI-compatible requests through configured providers and supports provider/model routing and fallback when the live product path supports it. We do not claim support for every model, guaranteed cheapest routing, or zero downtime.

Pricing and Billing: Do Not Compare Only Token Rates

Token rates matter, but gateway cost is a three-layer calculation:

OpenRouter emphasizes one account with access to many models and optional BYOK paths. LiteLLM can reduce vendor lock-in but shifts more runtime cost to your infrastructure. Portkey and Cloudflare add value through policy, logs, and controls. TheRouter's value is the combination of OpenAI-compatible routing and unified billing/accounting surfaces where implemented — useful when teams want fewer provider accounts and clearer cross-provider ledgers.

When comparing API pricing across providers, always normalize to USD per million tokens and split input from output. Most providers price output tokens 2–5× higher than input tokens, so a workload heavy on completion length looks very different from a retrieval-heavy workload at the same nominal "price per million."

• Use one currency (USD) — convert at publish date and cite the rate.
• Split input/output — never quote a single blended number.
• Cite each row to the provider's own pricing page with retrieval date.
• Note context-window tiers — long-context pricing often steps higher.

Observability and Control Plane Fit

This is where a head-to-head checklist helps:

A common mistake is choosing by model count alone. Model count is useful, but day-two operations depend on whether the gateway can answer: who called which model, which provider actually served it, what fallback happened, and where the spend landed.

Decision Matrix: Pick the Gateway for the Job

Pick OpenRouter if you mainly need fast access to many models, provider fallback, and a managed endpoint your app can call quickly.

Pick LiteLLM if you need self-hosting, want routing code close to your infrastructure, or must integrate custom provider adapters that a managed gateway does not yet expose.

Pick Portkey if policy, guardrails, request logs, and traceable fallback chains are first-class requirements for your team.

Pick Cloudflare AI Gateway if AI traffic should live inside an existing Cloudflare security, analytics, caching, DLP, and rate-limit control plane.

Pick TheRouter if your team wants to keep OpenAI-compatible clients, route across configured providers, use fallback chains, and consolidate billing/accounting surfaces without maintaining your own proxy. Start with the OpenAI-compatible router page, then verify fallback behavior in the model fallback guide and browse available providers.

Production Checklist Before You Switch

• Confirm the exact endpoints you need: chat, responses, embeddings, images, audio, or provider-native paths.
• Test streaming shape and provider-specific response fields before assuming full compatibility.
• Decide whether fallback should trigger on all errors, only rate limits, or only upstream outages.
• Log the final served model/provider for every production request.
• Compare total cost across token rates, gateway fees, and operational ownership.
• Keep a direct-provider rollback path for at least the first deployment window.

Bottom Line

Unified LLM gateways are converging on the same developer entry point: one OpenAI-compatible client and a configurable routing layer behind it. The differences are now about operating model. OpenRouter optimizes breadth, LiteLLM optimizes ownership, Portkey optimizes policy and traceability, Cloudflare optimizes edge control, and TheRouter optimizes a managed routing-and-billing path for teams already standardizing on OpenAI-compatible requests.

The safest choice is the one whose control plane matches your operating style. If your team does not want to run proxy infrastructure, a managed gateway is usually the better starting point. If your team needs every routing decision in your own code and network, self-hosting LiteLLM may be worth the extra work.