OpenRouter vs Vercel AI Gateway vs Cloudflare vs Portkey vs LiteLLM, comparativa 2026

La pregunta aparece cada vez que meto IA en un proyecto nuevo. ¿Llamo directo al SDK del proveedor o meto un agregador por medio? Y si meto un agregador, ¿cuál? En los últimos meses he pasado por OpenRouter, Vercel AI Gateway y llamadas directas a los SDK oficiales, y he evaluado en serio Cloudflare AI Gateway, Portkey y LiteLLM para otras piezas. Este post es la comparativa transversal que me habría gustado tener antes de empezar, no en formato tabla (que caduca mañana) sino por ejes que realmente pesan en la decisión.

Hay un post hermano sobre cómo migré tres proyectos de OpenRouter a Vercel AI Gateway, que es un ejercicio cronológico. Este es lo contrario, un mapa del terreno tal y como se ve a día de hoy.

Qué es un AI Gateway y qué no

Un AI Gateway es una capa intermedia entre tu código y los proveedores de modelos. Expone una API unificada (casi siempre compatible con el dialecto OpenAI Chat Completions, que se ha convertido en estándar de facto) y se encarga de hablar con cada proveedor por detrás. Tú pides anthropic/claude-sonnet-4 u openai/gpt-5, el gateway traduce la petición al SDK del proveedor correspondiente y te devuelve la respuesta normalizada.

Esto resuelve tres problemas reales. Primero, desacoplas el código del proveedor concreto, cambias de modelo con una cadena de texto y no tocando lógica de negocio. Segundo, centralizas la observabilidad, logs, tokens gastados, latencias y errores pasan por el mismo sitio independientemente del modelo. Y tercero, te da un punto único donde aplicar fallbacks, reintentos, rate limits y cuotas.

Lo que un gateway no resuelve es elegir bien. Si tu prompt está mal diseñado, si tu contexto es un vertedero o si no cacheas cuando podrías, ningún gateway te va a salvar. Es una capa operativa, no una capa inteligente.

Los actores de 2026

El mapa se ha movido mucho en un año. Estos son los seis que importan hoy, con el modelo mental que les corresponde.

OpenRouter. El veterano. Gateway gestionado con el catálogo de modelos más amplio del mercado, API compatible OpenAI, pago por uso con un margen sobre el precio del proveedor que ronda un dígito bajo. Puedes pagar con créditos propios o traer tus claves de cada proveedor (BYOK). Es la opción por defecto cuando no tienes una razón específica para otra.

Vercel AI Gateway. El recién llegado con mejor integración. Gateway gestionado, catálogo amplio (no tan amplio como OpenRouter pero cubre lo importante), integración nativa con el AI SDK de Vercel y con el ecosistema Next.js. Si despliegas en Vercel, el gateway resuelve DNS interno y simplifica operativa. Pricing con créditos que consumes según tokens. BYOK disponible.

Llamadas directas al SDK de Anthropic, OpenAI o Google. No es un gateway, pero es la alternativa con la que se compara todo lo anterior. Latencia mínima, acceso a funciones propietarias (prompt caching de Anthropic, batch API, computer use, priority tiers) y precio oficial sin margen. A cambio, tu código sabe demasiado del proveedor y cambiar significa reescribir.

Cloudflare AI Gateway. Un animal distinto. No cobra margen por pasar peticiones, tú pagas al proveedor final con tus propias claves. Cobra por volumen de eventos y por servicios asociados (caché, rate limits, feedback). Se parece más a un observability layer que a un marketplace de modelos. Si ya vives en Cloudflare (Workers, R2, D1, Queues) encaja como un guante.

Portkey. El gateway pensado para equipos con requisitos enterprise. Observabilidad muy rica, guardrails, virtual keys para repartir cuota entre equipos, SSO, auditoría. Se puede usar gestionado o desplegar en tu infraestructura. El pricing es por volumen de requests, no por margen sobre el proveedor.

LiteLLM. Proxy open source, autohospedado. Todo el valor del gateway (API unificada, fallbacks, logging) sin intermediario comercial. Lo operas tú, pagas al proveedor directo y mantienes el servicio en marcha. Ideal cuando no quieres depender de nadie y te sale a cuenta el trabajo operativo.

Eje 1, catálogo de modelos

La primera pregunta concreta es qué modelos puedes usar sin esfuerzo.

OpenRouter lidera con diferencia. Tiene desde los modelos frontera de Anthropic, OpenAI y Google hasta los open weights servidos por Together, Fireworks, DeepInfra y demás. Si un modelo existe y es mínimamente comercial, OpenRouter lo tiene. Para fases de exploración y prototipado, este catálogo ahorra mucho tiempo.

Vercel AI Gateway cubre lo importante (Anthropic, OpenAI, Google, Mistral, modelos populares abiertos) pero no es enciclopédico. Para producción seria con modelos establecidos sobra, para experimentar con modelos de nicho no.

Cloudflare AI Gateway es un pass-through. Cualquier proveedor al que puedas llamar con un token propio, puedes llamarlo a través de Cloudflare. No es un catálogo seleccionado sino una puerta para los que ya tienes contratados.

Portkey y LiteLLM se parecen en esto. No tienen catálogo propio, son agregadores de SDKs. Puedes apuntar a cualquier proveedor compatible, que son básicamente todos los relevantes de 2026.

Llamar directo es el extremo opuesto. Un solo proveedor, todo su catálogo nativo.

Eje 2, coste

Aquí hay tres modelos de cobro distintos mezclados.

Margen sobre el proveedor (OpenRouter, Vercel AI Gateway). Pagas algo más que el precio oficial del modelo. Ese margen es modesto pero existe y en proyectos con tráfico alto se nota al mes. A cambio, centralizan facturación y te abstraen de gestionar varias cuentas.

Sin margen, pagas volumen de eventos (Cloudflare AI Gateway). No cobran por pasar peticiones si las llamadas son con tus claves. Cobran por funciones añadidas (caché, rate limit, analytics) y por volumen sostenido. Para tráfico alto con modelos caros, este modelo sale mucho más barato.

Coste por volumen de requests (Portkey, LiteLLM gestionado). Precio por millones de requests procesados, independiente del precio del modelo. Si usas modelos caros, esto sale muy bien. Si usas modelos baratos pero con muchas llamadas, sale peor.

Sin gateway (llamadas directas). Pagas el precio oficial. Para un proyecto con un solo proveedor y volumen moderado, sigue siendo lo más barato en absoluto, aunque pierdes todo lo demás.

Para proyectos pequeños, el coste del gateway es ruido frente al coste del modelo. Para proyectos grandes, el modelo de cobro sí cambia el TCO. No hay respuesta universal, depende de cuánto y qué llamas.

Eje 3, latencia

Un gateway añade un salto. Ese salto se paga en milisegundos.

Vercel AI Gateway desplegado en la misma región que tu app suele añadir decenas bajas de milisegundos. Si despliegas en Vercel y usas el gateway, la resolución es prácticamente local. Es el gateway con menos penalización de latencia que he medido.

OpenRouter vive en su propio cloud, con buen routing pero sin la ventaja del mismo edge. La penalización es visible pero no preocupante para respuestas conversacionales.

Cloudflare AI Gateway corre en el edge de Cloudflare. Si ya sirves desde Workers o desde detrás de Cloudflare, el salto extra es mínimo. Si no, pierde parte de su ventaja.

Portkey y LiteLLM gestionado tienen latencias aceptables, pero si los despliegas tú, la latencia depende de dónde los pongas. LiteLLM autohospedado en la misma VPC que tu app puede ser casi gratis en latencia.

Llamadas directas son el baseline, sin salto extra. Para flujos donde cada milisegundo cuenta (completions en hot path, producto que muestra streaming), el salto sí pesa y conviene medir.

Eje 4, observabilidad

El punto en el que las diferencias son más grandes y más silenciosas.

Portkey es el más completo. Vista por request, por modelo, por equipo (virtual keys), cost tracking, guardrails, latency percentiles, exportación a herramientas externas. Si tienes un equipo mirando números cada semana, es el que menos construir encima.

Cloudflare AI Gateway se ha puesto serio en 2026. Métricas, logs, caching hit rate, rate limit analytics, todo integrado con el resto del stack de Cloudflare.

OpenRouter da lo básico, consumo por clave, lista de requests, algún gráfico. Vercel AI Gateway ha mejorado con un panel razonable, integrado en el dashboard de Vercel.

LiteLLM autohospedado te da lo que tú conectes. Si lo enganchas a tu propio Grafana o Langfuse, puede ser el más potente. Si no lo configuras, es el que menos te da.

Llamadas directas dependen del SDK. Los SDK oficiales han mejorado mucho en instrumentación, pero correlacionar llamadas a tres proveedores distintos con tres telemetrías distintas es trabajo manual.

Eje 5, failover y reintentos

Un gateway sin failover pierde la mitad de su gracia.

Portkey brilla aquí. Puedes definir fallback chains, retries con backoff, conditional routing según tipo de error. Si un modelo devuelve 429 o 5xx, el siguiente candidato de la cadena recibe la petición sin que tu código se entere.

LiteLLM tiene esto nativo también, con una configuración YAML que cubre la mayoría de casos.

OpenRouter permite definir fallback models por petición, lo suficiente para lo común. Si un modelo está caído o rate-limitado, puedes decir prueba con este otro.

Vercel AI Gateway tiene retries automáticos y ha añadido model fallback en 2026, aunque con menos granularidad que Portkey.

Cloudflare AI Gateway tiene reintentos y failover por configuración, integrado con sus rules. Funciona bien si tu lógica de error no es muy sofisticada.

Llamadas directas, todo lo que quieras orquestar lo montas tú. No hay nada automático.

Eje 6, privacidad y residencia de datos

El eje menos mirado y el más importante si trabajas con datos sensibles.

Llamar directo es lo más simple. Firmas el acuerdo del proveedor, conoces sus garantías (zero data retention en Anthropic y OpenAI para clientes de pago, residencia europea vía Google Vertex, etc.), y ya. Cada proveedor tiene sus opciones y las aplicas a tu contrato con ellos.

Un gateway gestionado añade una parte: los datos pasan por su infraestructura antes de llegar al proveedor. Tienes que añadir su acuerdo de procesamiento de datos al tuyo, revisar su política, mirar si tienen zero data retention ellos también y saber en qué región corren. Esto no es un problema pero sí un paso más de papeles.

Cloudflare AI Gateway es interesante aquí porque no retiene el cuerpo de las peticiones por defecto, solo metadatos, a menos que actives el logging explícito. Es un modelo de privacidad distinto al de OpenRouter o Vercel.

LiteLLM autohospedado y llamadas directas dan el control total. No hay terceros en el camino aparte del proveedor del modelo. Para proyectos con datos personales serios, es el camino más corto.

Eje 7, operativa y mantenimiento

¿Quién te pone en pie el servicio si algo se rompe un domingo?

OpenRouter, Vercel AI Gateway, Cloudflare AI Gateway y Portkey gestionado son managed. Se rompen en sus guardias, no en las tuyas. Con SLA declarado o no, sueles notar incidentes cuando ya están arreglando.

LiteLLM autohospedado y Portkey self-hosted son responsabilidad tuya. Si tu app depende del gateway y el gateway cae, cae tu app. Merece la pena si ya operas infraestructura, no tanto si eres un equipo sin on-call.

Llamar directo te ata solo a la disponibilidad del proveedor, que en 2026 es más fiable que hace un año. La desventaja es que si ese proveedor tiene un incidente, no tienes fallback natural salvo que lo hayas montado tú.

Eje 8, lock-in

Cambiar de gateway no debería ser una decisión dramática, pero algunos cierran más puertas que otros.

OpenRouter y Vercel AI Gateway hablan OpenAI Chat Completions, igual que LiteLLM y Portkey. Cambiar entre ellos es sobre todo cambiar baseURL y claves. El lock-in real es bajo.

Cloudflare AI Gateway te pide pensar como un pass-through: configuras por gateway y cada uno es un endpoint distinto. Migrar fuera es reescribir las URLs y quitar su caché.

Llamar directo al SDK propietario sí introduce lock-in, especialmente si usas funciones que solo existen en un proveedor (prompt caching de Anthropic, structured outputs de OpenAI, grounding de Google, tool use con matices distintos). Cambiar de proveedor implica rehacer esas partes.

Cuándo elegir cada uno

Después de atravesar los ocho ejes, esta es la guía corta que uso.

Si estás explorando modelos y prototipando, OpenRouter. El catálogo enorme y el coste por uso sin mínimos te permite probar diez modelos en una tarde sin abrir diez cuentas.

Si ya despliegas en Vercel y usas el AI SDK, Vercel AI Gateway. La integración con el SDK y con tu stack compensa el resto.

Si tu aplicación vive en Cloudflare, Cloudflare AI Gateway. Sin margen por petición, caché en el edge, observabilidad integrada. Encaja como un guante si ya estás dentro.

Si eres un equipo con requisitos formales (auditoría, SSO, guardrails, cuotas por equipo), Portkey. Es lo que más construir encima te ahorra.

Si priorizas cero dependencias comerciales y tienes savvy operativo, LiteLLM autohospedado. El valor del open source es real cuando puedes mantenerlo.

Si tu producto vive pegado a un solo proveedor y usas sus funciones propietarias de forma intensiva, llamada directa. Un gateway te cortaría funciones que necesitas y añadiría latencia.

No son excluyentes

La decisión no es binaria. En los tres proyectos en los que meto IA uso combinaciones, no una sola capa.

Para el research y los prototipos, OpenRouter como primary. En cuanto un proyecto se estabiliza en uno o dos modelos, evalúo si compensa pasar a Vercel AI Gateway (si despliego en Vercel) o a llamadas directas (si uso funciones propietarias intensivamente). Cuando el proyecto tiene tráfico alto, meto Cloudflare AI Gateway por delante para caché y observability, con las claves apuntando al proveedor directo.

Ese layering suena complicado pero es la forma honesta de aprovechar lo mejor de cada uno. El gateway para catálogo, el edge para caché, el proveedor directo para funciones propietarias.

Lo que no cambia aunque cambien los actores

Si el mapa ha cambiado tanto en un año, volverá a cambiar. Estas cuatro preguntas son las que uso para no quedarme enganchado a la decisión de ayer.

¿Cuánto cuesta cambiar? Si migrar de un gateway a otro es un día de trabajo, la decisión es barata y puedes equivocarte. Si es un sprint, piénsalo dos veces.

¿Qué parte del valor es del gateway y qué parte es del proveedor? Si el 90% de tu valor viene de un modelo concreto con funciones propietarias, un gateway te quita más que te da. Si el 90% viene de hablar con varios modelos y comparar, un gateway es media batalla ganada.

¿Qué datos pasan por ahí? Si son logs internos, da igual. Si son mensajes de usuarios, documentos, datos personales, el eje de privacidad deja de ser secundario.

¿Cuánto aguantas operar? El self-hosted es tentador hasta el primer incidente a las tres de la mañana. Si no tienes on-call, no es para ti.

Mi elección hoy

Si me obligan a quedarme con una sola capa para un proyecto nuevo de 2026, elijo OpenRouter. El catálogo, el coste predecible y el tiempo que ahorra experimentando son difíciles de batir cuando arrancas. Cuando el proyecto se estabiliza, reevalúo.

Si el proyecto despliega en Vercel, paso a Vercel AI Gateway. Si vive en Cloudflare, paso a Cloudflare AI Gateway. Si usa prompt caching de Anthropic en serio, paso a llamar directo. Ninguna de esas migraciones es dolorosa si empezaste hablando Chat Completions.

La idea que me llevo de haber usado varios es que el gateway no es una religión. Es una decisión operativa con vida útil corta, que conviene revisar cada pocos meses y que debería ser fácil de rebobinar. Si al elegir uno cierras puertas, probablemente has elegido mal.