Router propio en Python vs OpenRouter: cuándo cada uno tiene sentido de verdad
Llevo años montando mis propios routers en Python. OpenRouter acaba de cerrar una Serie B de 113M$ y procesa 100 billones de tokens al mes. ¿Sigo teniendo razón o soy un cabezota?
En este artículo
La pregunta incómoda que tardé en hacerme
Llevo años montando routers en Python. Integro directamente con las APIs de los proveedores, gestiono el fallback a mano, escribo la lógica de selección de modelo adaptada a cada proyecto. Y durante mucho tiempo asumí que eso era simplemente lo correcto.
Hace unos meses me paré a preguntarme si era pragmatismo o cabezonería. La respuesta honesta es que son las dos cosas a la vez, y esa incomodidad merece un análisis más limpio que el típico "depende".
Porque hay datos nuevos encima de la mesa. En mayo de 2026, OpenRouter cerró una Serie B de 113M$ liderada por CapitalG, el brazo de inversión de Alphabet/Google, con NVentures de NVIDIA también dentro. Según TechCrunch, la valoración alcanzó los 1.300M$, más del doble que hace un año, cuando rondaba los 547M$. La plataforma procesa 25 billones de tokens por semana, lo que equivale a unos 100 billones al mes, cinco veces más que seis meses antes.
Eso no es la tracción de un juguete para experimentar en fin de semana. Es una señal de mercado con mucho dinero detrás diciéndote que muchos equipos han decidido que no quieren seguir gestionando veinte proveedores por su cuenta.
Y aun así, yo sigo montando mis propios routers para ciertos casos. Aquí explico por qué, y cuándo esa postura deja de tener sentido.
Lo que OpenRouter resuelve de verdad
OpenRouter es, en esencia, un gateway unificado: una sola API para acceder a más de 400 modelos de más de 60 proveedores, Anthropic, Google, OpenAI, xAI, DeepSeek, Meta y un largo etcétera, . Enrutamiento inteligente, conmutación automática ante fallos, facturación unificada y reporting de uso. Todo bajo un mismo endpoint.
La propuesta de valor es sencilla de entender cuando has pasado una tarde gestionando rate limits distintos para cuatro proveedores a la vez: en lugar de mantener veinte configuraciones de API con sus respectivos clientes, sus headers, sus lógicas de reintento y sus formatos de error ligeramente distintos entre sí, configuras una sola vez y listo.
El CEO de OpenRouter, Alex Atallah, lo compara con Stripe en el mundo de los pagos: una capa de abstracción que resuelve la complejidad de conectar con múltiples proveedores del mismo tipo de recurso. La analogía no es perfecta, los modelos de lenguaje tienen matices que los métodos de pago no tienen, pero captura bien el problema que resuelve.
"Mientras otros ven caos, él ve la posibilidad de orden y elegancia." , Memo de inversión de a16z sobre Alex Atallah
Atallah, por cierto, es cofundador de OpenSea, la plataforma de NFTs que llegó a valer 13.300M$. Su experiencia en exchanges de activos digitales se traslada directamente a la idea de crear un marketplace donde la oferta son tokens de IA y la demanda son los desarrolladores y empresas que los consumen. La plataforma tiene 8 millones de usuarios activos globales según datos de la propia compañía.
El problema concreto que resuelve se mide en escala. Un estudio de Deloitte de 2026 encontró que el 67% de las empresas consume más de 1.000 millones de tokens al mes. A esa escala, gestionar las integraciones directamente con cada proveedor deja de ser un detalle técnico y se convierte en carga operativa real. El CTO de Uber declaró que el presupuesto de IA de 2026 se agotó en pocos meses, un reflejo de lo que ocurre cuando el consumo de tokens escala sin una capa que lo optimice.
Por qué sigo montando mis propios routers
Dicho todo lo anterior, hay casos en los que el código propio gana sin discusión.
Lógica de negocio que nadie más entiende
Cuando el criterio de routing no es solo "el más barato" o "el que no esté caído", sino algo parecido a: "si la petición viene del módulo de facturación usa Claude, si viene del módulo de soporte usa el modelo fine-tuned interno, y si el cliente tiene contrato enterprise activa el fallback a GPT-4o con un system prompt diferente", ninguna plataforma de terceros va a hacer eso por ti de forma limpia.
El routing con lógica de negocio compleja requiere acceso a estado interno que una API externa no tiene: datos del usuario, contexto de sesión, flags de feature, restricciones contractuales. Montar eso encima de OpenRouter es posible, pero lo que acabas construyendo es básicamente tu propio router que llama a OpenRouter como capa de transporte, lo cual tiene sentido solo si aprovechas el resto de funcionalidades de la plataforma.
Orquestación con servicios internos
Si el router necesita consultar una base de datos vectorial interna antes de decidir qué modelo usar, o escribir trazas en un sistema de observabilidad propio, o aplicar transformaciones al prompt basadas en metadatos que solo existen dentro de tu infraestructura, el código propio es la respuesta natural. No porque OpenRouter sea malo, sino porque el problema no es de enrutamiento de modelos: es de orquestación de sistemas, y ahí el código es el único lenguaje que habla con todo.
Para este tipo de arquitecturas, merece la pena revisar cómo estructurar la capa de enrutamiento de IA a nivel empresarial, donde AWS, Microsoft y Anthropic también están peleando por ese mismo "último kilómetro".
El coste del mantenimiento de integraciones directas
Aquí viene la parte incómoda de reconocer: mantener integraciones directas con diez o quince proveedores es un trabajo que no acaba nunca. Cada proveedor actualiza su API a su ritmo. Los modelos deprecan, los parámetros cambian, los límites de tasa se modifican, los formatos de error evolucionan. Normalmente la persona que toca ese código soy yo.
La fricción acumulada de ese mantenimiento es un coste real que durante mucho tiempo no puse en la balanza porque era difuso y llegaba en pequeñas dosis. Un par de horas aquí cuando OpenAI depreca gpt-4, otra hora allá cuando Anthropic cambia el formato de los mensajes de sistema, un rato más cuando un proveedor nuevo te obliga a añadir un cliente distinto. Solo cuando lo sumas empiezas a ver el número.
La economía detrás del routing multi-modelo
El argumento económico para una capa de enrutamiento unificada se vuelve más claro cuando miras los precios de los modelos más populares dentro de la plataforma.
Según los datos de OpenRouter, los modelos de DeepSeek y Tencent lideran el volumen de tokens en la plataforma, no porque sean los más potentes en todos los benchmarks, sino porque son los más baratos para las tareas que más se repiten. DeepSeek V4 cuesta aproximadamente 0,43$/M tokens de entrada frente al dólar de Claude Haiku. Cuando tienes una capa de routing que puede mover tráfico entre modelos en función del coste y la complejidad de la tarea, esa diferencia de precio se convierte en una palanca real.
El auge de modelos de código abierto como los de DeepSeek acelera esta lógica. Ninguna empresa grande quiere atarse a un único proveedor cuando hay alternativas competitivas y más baratas para una buena parte de sus casos de uso. Una capa de enrutamiento que gestiona esa diversidad de opciones, y que cambia el modelo automáticamente cuando uno falla o se encarece, tiene un valor que se paga solo a cierta escala.
La pregunta nunca es cuál modelo es mejor. La pregunta es cuál modelo necesitas para cada tarea concreta, y quién decide eso en tiempo real.
Inversores como ServiceNow, MongoDB, Snowflake y Databricks participaron en la Serie B de OpenRouter. No son fondos de venture capital generalistas apostando por una startup prometedora: son empresas de infraestructura que ven en OpenRouter la puerta de entrada a la IA empresarial. Eso dice algo concreto sobre hacia dónde creen que va el mercado.
Cuándo OpenRouter tiene sentido y cuándo no
Después de darle vueltas, el mapa que tengo en la cabeza es bastante concreto.
OpenRouter tiene sentido cuando:
- Estás en fase de exploración y quieres probar varios modelos sin montar infraestructura para cada uno. Yo lo he usado exactamente para esto: probar Llama, Mistral y algún modelo más de forma gratuita sin integrar cinco SDKs distintos.
- Tu equipo no tiene un ingeniero dedicado a mantener integraciones con proveedores de LLM.
- Tu lógica de routing es estándar: fallback por disponibilidad, selección por coste o por capacidad declarada del modelo.
- Necesitas facturación unificada y reporting de uso sin construirlo tú.
- Operas a escala media-alta y el coste de oportunidad de gestionar veinte APIs supera el coste de delegar esa capa.
El código propio tiene sentido cuando:
- Tu lógica de routing depende de estado interno de tu sistema que una API externa no puede ver.
- Necesitas orquestar el modelo con servicios internos, bases de datos, sistemas de observabilidad, pipelines de datos, en el mismo flujo.
- Tienes restricciones de compliance o privacidad que te impiden que tus peticiones pasen por un intermediario externo.
- Quieres control total sobre los reintentos, los timeouts y el comportamiento ante fallos con lógica que no se puede configurar desde fuera.
- Tu equipo tiene la capacidad técnica de mantener ese código y el tiempo que cuesta hacerlo está justificado por los requisitos del proyecto.
La señal de que estás en el caso equivocado es bastante clara en ambas direcciones: si llevas tres semanas manteniendo clientes de API en lugar de construir el producto, deberías mirar OpenRouter. Si estás intentando meter lógica de negocio compleja en los parámetros de configuración de un gateway externo, deberías mirar Python.
Lo que los 100 billones de tokens al mes me dicen realmente
El crecimiento de OpenRouter, de 20 billones a 100 billones de tokens al mes en seis meses según TechCrunch, no significa que construir tus propios routers sea obsoleto. Significa que el problema de gestionar múltiples proveedores de LLM a escala es real y que mucha gente ha decidido resolverlo con una capa de abstracción externa.
La Serie A fue de 40M$ en junio de 2025, liderada por a16z y Menlo Ventures. Un año después, la Serie B es de 113M$ con una valoración de 1.300M$. El salto refleja un cambio de percepción del mercado: el valor no está solo en entrenar los modelos, está en la capa que decide cuándo usar cuál, a qué coste y con qué fallback.
Vercel lo vio antes que muchos: construyó un router interno para sus propios sistemas, sus clientes lo pidieron como producto y acabó lanzándolo. Ese patrón, herramienta interna que se convierte en producto porque el problema es universal, es una señal más limpia que cualquier nota de prensa.
Lo que me resulta más interesante del posicionamiento de OpenRouter como el "Stripe de los tokens de IA" no es la analogía en sí, sino lo que implica sobre la madurez del mercado. Stripe no reemplazó a los equipos de ingeniería de pagos en las grandes empresas: los liberó para construir el producto en lugar de mantener integraciones. Si OpenRouter consigue hacer lo mismo con los proveedores de LLM, el valor que captura es real y sostenido.
Pero Stripe tampoco reemplazó a los equipos que necesitaban lógica de pagos compleja y específica. Hay empresas enteras construidas sobre lógica de pagos custom que Stripe nunca podrá manejar. La misma tensión existe aquí.
Preguntas frecuentes
¿Qué es OpenRouter y para qué sirve?
OpenRouter es una API unificada que da acceso a más de 400 modelos de lenguaje de más de 60 proveedores, OpenAI, Anthropic, Google, DeepSeek, Meta y otros, desde un único endpoint. Incluye enrutamiento inteligente, fallback automático ante fallos y facturación unificada. Resuelve el problema de mantener integraciones separadas con cada proveedor.
¿Cuándo merece la pena construir tu propio router en Python en vez de usar OpenRouter?
Cuando tu lógica de routing depende de estado interno de tu sistema que un gateway externo no puede ver, cuando necesitas orquestar el modelo con servicios internos propios, o cuando tienes restricciones de compliance que impiden que las peticiones pasen por un intermediario. Si tu lógica es estándar y no tienes un ingeniero dedicado a mantener integraciones, OpenRouter es difícil de ignorar.
¿Cuánto procesa OpenRouter actualmente?
Según datos de TechCrunch de mayo de 2026, OpenRouter procesa 25 billones de tokens por semana, lo que equivale a unos 100 billones al mes. Es cinco veces más que seis meses antes. La plataforma tiene 8 millones de usuarios activos globales.
¿Por qué los inversores estratégicos como Snowflake o MongoDB entraron en la Serie B de OpenRouter?
Porque apuestan por la tesis de que la puerta de entrada a la IA empresarial estará en la capa de enrutamiento, no en un modelo particular. ServiceNow, MongoDB, Snowflake y Databricks participaron en la ronda junto a CapitalG y NVentures. No son fondos generalistas: son empresas de infraestructura que ven en esa capa el "último kilómetro" del stack de IA empresarial.
