La comparación está planteada de forma incorrecta casi en todas partes, y el cuarto resultado de esta búsqueda lo revela: es la propia página de documentación de LiteLLM sobre OpenRouter. LiteLLM incluye una integración con OpenRouter porque estos dos productos no son sustitutos: pertenecen a capas diferentes. LiteLLM es un proxy que despliegas sobre las cuentas de proveedores que posees; OpenRouter es un servicio alojado que conserva las cuentas de proveedores por ti y revende el acceso a los modelos. Un proxy necesita una fuente; OpenRouter es una. Muchos equipos ejecutan ambos de forma deliberada.
Sesgo declarado: Kunavo es nuestro producto, y pertenece al lado de OpenRouter de esta página: una fuente alojada de modelos, no un proxy. No es una alternativa a lo que hace LiteLLM, y la página no sostiene que lo sea.
La diferencia entre capas, en una tabla
| LiteLLM | OpenRouter | |
|---|---|---|
| Qué es | Software que despliegas | Un servicio alojado |
| Quién conserva las credenciales de los proveedores | Tú | OpenRouter |
| ¿Es una fuente de modelos? | No; necesita una detrás | Sí |
| Quién lo opera | Tú: despliegas, corriges, escalas y recibes alertas | Nadie de tu lado |
| Coste de inferencia | Tus propias tarifas de proveedor | Tarifas de los proveedores más su comisión sobre las compras de crédito |
| ¿Puede el texto de los prompts permanecer en tu infraestructura? | Sí | No |
Lee la fila «¿es una fuente de modelos?» de arriba abajo y el planteamiento se desmorona. Todas las demás diferencias se derivan de esa única cuestión.
Usarlos juntos, que es lo habitual
LiteLLM delante, OpenRouter detrás: tus aplicaciones hablan con un único endpoint interno, LiteLLM aplica presupuestos por clave y el enrutamiento por equipos, y OpenRouter proporciona el catálogo sin que tengas que abrir una cuenta con cada proveedor. Cualquier endpoint compatible con OpenAI encaja de la misma manera, así que añadir una segunda fuente para la conmutación por error requiere unas pocas líneas:
# LiteLLM and OpenRouter are layers, not rivals. This is a
# LiteLLM config with two model sources behind one proxy.
model_list:
- model_name: claude-sonnet
litellm_params:
model: openrouter/anthropic/claude-sonnet-4.6
api_key: os.environ/OPENROUTER_API_KEY
# A second source behind the same proxy — any OpenAI-compatible
# endpoint works the same way.
- model_name: claude-sonnet-backup
litellm_params:
model: openai/claude-sonnet-5
api_base: https://api.kunavo.com/v1
api_key: os.environ/KUNAVO_API_KEYEsa es la configuración que normalmente debería plantear la pregunta «vs»: no cuál de los dos, sino si necesitas realmente la capa de proxy sobre una fuente alojada.
Cuándo solo necesitas uno de verdad
- Solo OpenRouter: no tienes cuentas de proveedores, no quieres tenerlas y tus necesidades de enrutamiento quedan cubiertas por lo que ya hace un gateway alojado. Añadir LiteLLM en este caso te da un servicio que operar y poco más. Alternativas de esta categoría: la recopilación sobre OpenRouter.
- Solo LiteLLM: ya tienes cuentas de proveedores, posiblemente con tarifas negociadas, y lo que te falta es control: un endpoint, presupuestos por clave, una política de enrutamiento y que el texto de los prompts nunca salga de tu infraestructura. Un revendedor no puede ofrecerte esto último a ningún precio.
- Ninguno: quieres el enrutamiento y la gobernanza, pero no un servicio que operar. Eso es un plano de control BYO-key alojado, una tercera categoría fuera de la que quedan ambos: las cuatro categorías de gateways para LLM.
Las dos cosas que debes comprobar antes de comprometerte con cualquiera de los dos
En el lado de LiteLLM: la superficie operativa. Un proxy autoalojado es un paquete dentro de tu compilación, lo que coloca tu CI/CD y tu clúster dentro de su radio de impacto; no es algo hipotético en este proyecto, como demostró el incidente de la cadena de suministro de marzo de 2026. La respuesta de LiteLLM fue sustancial y el incidente está cerrado para cualquiera que utilice v1.83.0 o posterior, pero el punto estructural se mantiene para todo proxy autoalojado.
En el lado de OpenRouter: el precio mínimo. Un revendedor que repercute los precios de lista aplicando una comisión a las compras a crédito no es automáticamente más barato que tu propia cuenta — ni automáticamente más caro, si tu cuenta está al precio de lista público. La comparación que merece la pena hacer es tu tarifa real frente a la tarifa real de la pasarela, por modelo, para los modelos que utilizas. Kunavo ofrece la mayoría de los modelos por debajo de las tarifas oficiales de los proveedores, lo que representa la misma comparación desde la otra dirección: Kunavo frente a OpenRouter.
Compatibilidad de protocolo, para que cambiar siga siendo barato
Ambos hablan el protocolo de red de OpenAI, al igual que todas las alternativas alojadas a cualquiera de ellos (la documentación de OpenRouter · la de LiteLLM). Elijas lo que elijas, el coste de equivocarse es un base_url y un cambio de clave, que es el dato más útil de esta página: esta decisión no merece las semanas que algunos equipos le dedican. Consulta los detalles en la guía de la API compatible con OpenAI.
Preguntas frecuentes
¿Cuál es la diferencia entre OpenRouter y LiteLLM?
Se encuentran en capas diferentes. LiteLLM es software que despliegas: un proxy que se sitúa delante de los proveedores de modelos utilizando las claves de API que tú posees, y no es por sí mismo una fuente de modelos. OpenRouter es un servicio alojado que conserva las credenciales de los proveedores y revende el acceso a los modelos desde una sola cartera; por tanto, es una fuente de modelos, pero no algo que ejecutes tú. La consecuencia práctica es que LiteLLM necesita al menos una cuenta de proveedor detrás, y OpenRouter puede ser esa cuenta.
¿Se pueden usar LiteLLM y OpenRouter juntos?
Sí, y es una configuración documentada, no un apaño: LiteLLM incluye una integración con el proveedor OpenRouter. La estructura habitual es LiteLLM como proxy con el que hablan tus aplicaciones y OpenRouter como una de las fuentes situadas detrás, de modo que obtienes los presupuestos por clave y el enrutamiento por equipos de LiteLLM sobre el catálogo de OpenRouter sin tener cuentas con cada proveedor.
¿LiteLLM es más barato que OpenRouter?
LiteLLM no añade costes de inferencia porque no revende nada: pagas lo que cuesten tus propias cuentas de proveedor, además de la infraestructura en la que lo ejecutes y el tiempo de ingeniería necesario para operarlo. OpenRouter cobra las tarifas de los proveedores más una comisión sobre las compras de crédito. Por eso, en precio unitario, LiteLLM gana cuando ya tienes cuentas de proveedores con buenas tarifas; la comparación cambia cuando no las tienes: una cuenta que tuviste que crear al precio de lista no es más barata que la tarifa de un revendedor solo porque ningún gateway haya aplicado una comisión.
¿Debería elegir OpenRouter o LiteLLM?
Pregunta qué te falta, en lugar de cuál es mejor. Si tienes cuentas de proveedores y necesitas enrutamiento, presupuestos y gobernanza sobre ellas, esa es la función de LiteLLM. Si no tienes cuentas de proveedores y no quieres gestionar ninguna, esa es la función de OpenRouter. Si ninguno de los dos problemas está resuelto, quizá quieras ambos; y si quieres el enrutamiento sin operar un servicio, ninguno de los dos es la respuesta: necesitas un plano de control BYO-key alojado.
¿Es seguro usar LiteLLM después del ataque a la cadena de suministro de 2026?
LiteLLM publicó v1.83.0 mediante una canalización de CI/CD reconstruida después del incidente del 24 de marzo de 2026, con credenciales de mantenedores rotadas, análisis forense de Mandiant e imágenes de Docker firmadas. Si utilizas la versión 1.83.0 o posterior, el incidente está cerrado para ti. Vale la pena leer el relato completo y lo que implica estructuralmente —un proxy autoalojado es un paquete dentro de tu compilación— antes de elegir el lado autoalojado de esta comparación.
¿Qué lugar ocupa Kunavo en esta comparación?
En el lado de OpenRouter, no en el de LiteLLM: Kunavo es un gateway alojado que conserva las credenciales de los proveedores ascendentes, por lo que es una fuente alternativa de modelos, no un proxy que despliegas. Una implementación de LiteLLM puede apuntar a Kunavo del mismo modo que apunta a OpenRouter, mediante el proveedor compatible con OpenAI de LiteLLM y configurando la URL base. No sustituye lo que hace LiteLLM.