OpenRouter Series B de 113M — el routing de modelos se consolida como infraestructura de 1.000M
Si leíste nuestro artículo sobre routing multi-modelo, ya sabes que usar un solo modelo para todo es un error de arquitectura. Lo que quizá no esperabas es que la capa de routing — el “cableado” que conecta tu app con decenas de proveedores — se convertiría en negocio de más de 1.000 millones de dólares.
El 26 de mayo de 2026, OpenRouter anunció su Series B: 113M de dólares liderada por CapitalG (el fondo de crecimiento independiente de Alphabet), con participación de NVentures (NVIDIA), ServiceNow Ventures, MongoDB Ventures, Snowflake Ventures, Databricks Ventures, AMP PBC y Pace Capital, junto a inversores existentes Andreessen Horowitz y Menlo Ventures.
La valoración: 1.300M de dólares. El doble de su Series A de 28M de abril 2025 (que la valoró en 500M).
Los números de uso son los que realmente importan:
| Métrica | Hace 6 meses | Hoy | Crecimiento |
|---|---|---|---|
| Tokens/semana | 5T | 25T | 5x |
| Developers | — | 8M+ | — |
| Modelos disponibles | — | 400+ | — |
| Ritmo anualizado | — | >1 cuatrillón de tokens | — |
Esto no es una ronda de hype. Es la validación de que la capa de routing es infraestructura crítica.
TL;DR
- OpenRouter levantó 113M en Series B (CapitalG-led) a 1.3B de valoración.
- Creció de 5T a 25T tokens/semana en 6 meses. 8M+ developers, 400+ modelos.
- Los inversores estratégicos (NVIDIA, Databricks, Snowflake, MongoDB) validan que el routing es capa esencial del stack.
- Para un dev, esto significa más features enterprise (workspaces, guardrails, zero-data-retention) pero también más dependencia de un intermediario.
- La pregunta ya no es “¿routing o no routing?” sino “¿quién controla mi routing?”.
Por qué un router de APIs vale 1.300M
La respuesta corta: porque el ecosistema de modelos se ha roto en demasiadas piezas.
En 2023, tenías OpenAI y poco más. En 2024, apareció Anthropic, Google, y los primeros open-weights competitivos. En 2025, DeepSeek, Qwen, Mistral, Gemma, Llama, GLM, Phi. En 2026, hay literalmente cientos de modelos con diferentes fortalezas, precios, latencias, rate limits, context windows y capacidades (function calling, structured output, multimodal).
Cada proveedor tiene su propia API, su propio formato de errores, su propio sistema de billing, su propia política de retención de datos. Integrar cinco proveedores directamente es manageable. Integrar quince es un quebradero de cabeza. Integrar cuarenta es un problema de ingeniería.
OpenRouter resolvió ese problema al estilo Stripe: una API, una key, todos los proveedores. Lo que Stripe hizo para pagos, OpenRouter lo está haciendo para inferencia. Y al igual que Stripe, el mercado está dispuesto a pagar por la abstracción.
Los inversores estratégicos lo entienden así. Cuando NVIDIA, Databricks, Snowflake y MongoDB participan en una ronda, no están apostando a que un proxy de APIs sea “cool”. Están apostando a que sus clientes enterprise van a necesitar una capa de routing para desplegar modelos de múltiples proveedores, y OpenRouter está bien posicionado para ser esa capa.
Lo que OpenRouter ha construido en el último año
Más allá de agregar proveedores, OpenRouter se ha movido hacia el territory enterprise:
Multimodal completo. Ya no es solo texto. OpenRouter soporta modelos de imagen, audio, speech, transcripción, embeddings y vídeo. Si tu stack necesita switching entre un modelo de texto y uno de speech (por ejemplo, un agente que habla), OpenRouter lo unifica.
Workspaces y spend management. Para equipos que necesitan controlar quién gasta qué. Lo que antes requería un dashboard propio ahora viene integrado.
Guardrails. Filtrado de contenido y políticas de uso a nivel de organización. Esto es lo que permite a las empresas usar OpenRouter sin que cada equipo tenga que implementar su propia capa de compliance.
Zero-data-retention. Política de no retención de datos para organizaciones que no quieren que su tráfico de inferencia se almacene. Básico para el enterprise.
Intelligent routing. No solo failover, sino routing consciente de coste, latencia y calidad. Esto es lo que diferencia a OpenRouter de un proxy tonto: puede enrutar tu request al proveedor más barato que cumpla tu umbral de calidad, o al más rápido si la latencia es tu prioridad.
OpenRouter vs LiteLLM vs routing custom: actualización 2026
En nuestro artículo de routing comparamos las tres opciones. Con los datos de esta ronda, vale la pena actualizar el análisis.
OpenRouter: cuando quieres que alguien más gestione el caos
| Aspecto | Estado actual |
|---|---|
| Modelos | 400+ (casi cualquier modelo relevante) |
| Multimodal | Sí (texto, imagen, audio, vídeo, embeddings) |
| Enterprise features | Workspaces, guardrails, spend management, ZDR |
| Fallback automático | Sí (provider-level failover) |
| Intelligent routing | Sí (coste, latencia, calidad) |
| Latencia extra | Un hop (variable, suele ser 50-200ms) |
| Vendor lock-in | Medio: migrar de OpenRouter requiere reescribir integraciones |
| Precio | Markup sobre el proveedor (variable) |
Cuándo usarlo ahora: Si eres un equipo de 2-10 personas que no quiere mantener infra propia de integración. Si necesitas acceso a muchos modelos sin negociar contratos enterprise con cada proveedor. Si estás en prototipado rápido o tu producción no optimiza latencia al milisegundo.
Lo nuevo: Si eres enterprise y necesitas guardrails, spend management y compliance integrados, OpenRouter se ha convertido en una opción seria que antes no lo era tanto.
LiteLLM: cuando necesitas control total
LiteLLM ha madurado significativamente. Es la opción open-source para quien no quiere depender de un servicio third-party.
| Aspecto | Estado actual |
|---|---|
| Modelos | 100+ proveedores |
| Open source | Sí (Apache 2.0) |
| Self-hosted | Sí (tu infra, tu control) |
| Routing rules | Altamente configurable (por tarea, usuario, coste, etc.) |
| Caching / rate limiting | Integrado |
| Budget tracking | Integrado |
| Vendor lock-in | Ninguno (es open-source) |
| Mantenimiento | Tú lo mantienes (solo, bugs, updates, escalado) |
Cuándo usarlo: Producción con requisitos regulatorios estrictos (datos sensibles, soberanía). Equipos con capacidad de DevOps para mantener un servicio más. Cuando necesitas reglas de routing que OpenRouter no soporta.
Trade-off real: LiteLLM te da control total, pero tú absorbes la complejidad operativa. Si tu equipo de infra ya está ocupado, añadir LiteLLM al stack es otra pieza que mantener.
Routing custom: cuando menos es más
Un switch case sigue siendo la opción correcta para muchos equipos. No necesitas una librería ni un servicio para decidir entre dos modelos.
Cuándo usarlo: Tienes 2-5 modelos, las reglas son estáticas, y prefieres debugging trivial sobre flexibilidad.
Lo que ha cambiado: Cero. Si tu routing cabe en 20 líneas de código, no lo compliques.
La tabla actualizada
| Escenario | Herramienta | Por qué (2026) |
|---|---|---|
| Prototipo / MVP | OpenRouter | Zero infra, 400+ modelos, enterprise features emerging |
| Startup en producción | OpenRouter o LiteLLM | OpenRouter si no quieres infra; LiteLLM si necesitas control fino |
| Enterprise con compliance | LiteLLM (self-hosted) | Datos sensibles, regulación, auditoría |
| Equipo pequeño, routing simple | Routing custom | Menos piezas, menos fallos |
| Agentes autónomos production | LiteLLM + custom rules | Necesitas control fino sobre coste, calidad y fallback |
| Multimodal (texto + audio + imagen) | OpenRouter | Unifica modalidades en una API |
Lo que esta ronda significa para devs
1. El routing ya no es opcional
Con 400+ modelos y precios que cambian mensualmente, no usar routing es dejar dinero en la mesa. No es una opinión: es matemática. Si el 80% de tus queries se pueden resolver con un modelo a $0.14/1M tokens y estás pagando $15/1M tokens, estás pagando 100x de más por esas queries.
2. La capa de routing se está consolidando
OpenRouter no es el único jugador (LiteLLM, Helicone, Portkey, etc.), pero es el que más tracción tiene entre devs individuales y startups. La Series B con inversores estratégicos de infra (NVIDIA, Databricks, Snowflake) sugiere que OpenRouter se está posicionando como la capa estándar — el “Stripe de la inferencia”.
Esto tiene implicaciones:
- Más features faster: Con 113M de capital, OpenRouter puede invertir agresivamente en intelligent routing, soporte enterprise y nuevas modalidades.
- Más modelos, más rápido: Los proveedores tienen incentivo para integrarse con OpenRouter porque ahí están los 8M+ de developers.
- Posible vendor lock-in: Si toda tu infraestructura depende de OpenRouter, migrar será costoso. Es el mismo patrón que con AWS, Stripe o Vercel.
3. La pregunta no es si usar routing, sino quién controla tu routing
Hay tres niveles de dependencia:
| Nivel | Enfoque | Control | Complejidad |
|---|---|---|---|
| Bajo | Routing custom (switch case) | Máximo | Mínima |
| Medio | LiteLLM self-hosted | Alto | Media |
| Alto | OpenRouter managed | Medio | Baja |
Ninguno es inherentemente mejor. Depende de tu equipo, tu traffic y tus requisitos. Lo que sí es claro: en 2026, elegir el nivel cero (no hacer routing y mandar todo a un solo proveedor) es la peor opción de las tres.
4. Los precios van a seguir bajando
OpenRouter ha obligado a los proveedores a competir en transparencia. Cuando puedes comparar el precio exacto de 400+ modelos en una interfaz, los proveedores no pueden ocultar sus tarifas detrás de calculadoras opacas. Esta Series B acelera esa dinámica: más users en OpenRouter = más presión competitiva sobre precios = mejores condiciones para todos.
El futuro: routing inteligente
Lo que OpenRouter está construyendo va más allá del failover y la selección manual de modelos. El “intelligent routing” que mencionan en su anuncio apunta a algo más interesante:
Routing por calidad estimada. En lugar de que tú decidas “esta query va a DeepSeek”, el router analiza la query y la envía al modelo que históricamente ha dado mejores resultados para ese tipo de tarea, con el coste más bajo. Es lo que muchos equipos implementan con un clasificador + ejecutor (que cubrimos en nuestro artículo de routing), pero gestionado como servicio.
A/B testing de modelos. Mandar la misma query a dos modelos y comparar outputs automáticamente. Útil para migraciones: “¿GPT-5.4 es realmente mejor que Claude Sonnet 4.6 para mis use cases concretos?”. Sin routing layer, esto requiere código custom. Con ella, es una configuración.
Optimización de coste en tiempo real. Si Claude está más barato hoy que ayer (descuentos, promociones, cache hits), el router lo sabe y prioriza. Si DeepSeek está saturado y la latencia sube, el router desvía tráfico a otro proveedor. Esto es lo que justifica pagar el markup de OpenRouter: la optimización supera el coste del intermediario.
Lo que falta: Transparencia en cómo se toman las decisiones de routing. Si OpenRouter me enruta al proveedor A en vez del B, quiero saber por qué. ¿Es por coste? ¿Por latencia? ¿Por un acuerdo comercial entre OpenRouter y el proveedor A? Esta transparencia será crítica conforme OpenRouter se convierta en infraestructura esencial.
Lo que yo haría
Si estuviera diseñando un sistema de inferencia hoy:
- Usaría OpenRouter como punto de entrada, con routing custom para las decisiones críticas (qué modelo para qué tipo de query).
- Implementaría un logger de costes que trackee cuánto gasto por modelo, por tipo de query y por resultado. Sin datos, no puedes optimizar.
- Mantendría un plan de migración. OpenRouter puede ser tu routing layer hoy, pero deberías poder moverte a LiteLLM o routing direct si las condiciones cambian (precios, términos, disponibilidad). No escribas código que dependa de funcionalidades específicas de OpenRouter.
- No pagaría frontier para todo. El 80% de las queries de la mayoría de apps no necesitan GPT-5.5 ni Claude Opus 4.7. Un buen routing te ahorra un 70-90% sin degradación perceptible. Nuestra guía de routing tiene la hoja de ruta.
El routing de modelos se ha consolidado. La única pregunta que queda es: ¿estás aprovechando esa consolidación, o seguís pagando a un solo proveedor por resolver queries que un modelo 100x más barato resolvería igual de bien?
Fuentes
- OpenRouter: Series B announcement
- StartupHub: OpenRouter Series B details
- Morningstar / Business Wire: press release
Lectura relacionada
- Routing multi-modelo 2026: cómo elegir el LLM correcto — la guía de referencia para implementar routing.
- Guía de costes LLM: tokens, caching, routing y proveedores — fundamentos de costes y cómo el routing reduce la factura.
- Recortar costes de coding agents un 50% sin perder calidad — aplicación práctica de routing a coding agents.