¿100 mil millones de dólares por una estación de transferencia? ¿Qué ve Stripe en OpenRouter?

A finales de julio de 2026, un rumor de adquisición rompió la calma en el ámbito de la infraestructura de IA. Según el Wall Street Journal, el gigante de pagos Stripe está en conversaciones para adquirir la plataforma de agregación de modelos de IA OpenRouter por aproximadamente 10 mil millones de dólares. Si se concreta la transacción, esta valoración equivaldría a 70 veces los ingresos anuales de OpenRouter. Lo más llamativo es que, apenas tres meses antes, OpenRouter había completado una ronda de financiación Serie B de 113 millones de dólares, con una valoración de 1.3 mil millones. En solo unos meses, su valoración se ha multiplicado por casi 8, detrás de un negocio que parece no tener barreras tecnológicas: una estación de transferencia de API de IA.

Entre los muchos intermediarios que revenden API, ¿por qué OpenRouter se destaca y hace que Stripe esté dispuesto a pagar una prima tan alta? Para responder a esta pregunta, es necesario desentrañar la superficie de los rumores de valoración y volver a la trayectoria de desarrollo de OpenRouter, su modelo de negocio y la experiencia del desarrollador en sí.

Rumores de 10 mil millones de dólares y 70 veces el múltiplo de ventas: ¿dónde está el techo de una estación de transferencia?

El mercado de capitales ya anticipaba una explosión en la capa de aplicaciones de IA, pero que OpenRouter, como capa intermedia, obtenga una prima tan alta sigue superando la comprensión de muchos. Un múltiplo de 70 veces el precio sobre ventas (PS) es un número extremadamente alto en el ámbito de SaaS. Es importante aclarar que los aproximadamente 140 millones de dólares en ingresos anuales son una tasa de operación calculada por el mercado; no hay datos de auditoría pública sobre los ingresos netos reales de OpenRouter (ingresos netos después de deducir los costos de tokens pagados a los proveedores de modelos subyacentes). Si se calcula sobre la base de ingresos netos, el múltiplo PS real podría ser mucho más alto que 70.

La razón por la cual el mercado está dispuesto a ofrecer tal valoración radica en la extrema demanda de un "punto de entrada para la liquidación de la economía de Agentes de IA". Los fabricantes de grandes modelos están compitiendo por parámetros, los desarrolladores están compitiendo por aplicaciones, y OpenRouter está actuando como "la caja registradora y sala de control de las API". Stripe es en sí mismo el procesador de pagos de backend de OpenRouter. En la era de los Agentes de IA, la invocación y liquidación mutua entre Agentes requiere infraestructura; al adquirir OpenRouter, Stripe estaría controlando el flujo de tráfico y capital en el ecosistema de aplicaciones de IA.

Pero esta es solo la lógica a nivel de capital. OpenRouter ha logrado acumular una escala ecológica que respalda esta valoración en solo unos pocos años, gracias a la fuerte adhesión que ha establecido en la comunidad de desarrolladores. Hasta mediados de 2026, OpenRouter procesa más de 25 billones de tokens por semana, sirve a más de 8 millones de desarrolladores y se conecta con más de 400 modelos y más de 70 proveedores. Los inversores en la ronda B no son solo VC financieros, sino que CapitalG lideró la ronda, con empresas de infraestructura empresarial como Nvidia, ServiceNow, MongoDB y Snowflake también participando. Esto indica que OpenRouter ha pasado de ser un "juguete para desarrolladores" a formar parte del "stack de IA empresarial".

De mercado de NFT a enrutador de IA: la memoria muscular de un emprendedor en serie

El rápido ascenso de OpenRouter está íntimamente relacionado con la trayectoria de emprendimiento en serie de su fundador, Alex Atallah. Alex Atallah es cofundador y ex CTO del mayor mercado de NFT del mundo, OpenSea. Antes del pico de la burbuja de NFT, eligió salir y fundó OpenRouter a principios de 2023.

Desde la agregación de transacciones de activos digitales hasta la agregación de potencia de IA y enrutamiento de API, estas dos pistas aparentemente no relacionadas tienen una alta isomorfía en términos de lógica comercial. Lo que Atallah hace esencialmente es "no producir activos/modelos, solo actuar como una capa intermedia de liquidez y enrutamiento". En OpenSea, el núcleo es agregar activos digitales en diferentes blockchains y proporcionar un mercado de transacciones unificado; en OpenRouter, el núcleo es agregar las API de diferentes fabricantes de grandes modelos y proporcionar una interfaz de invocación unificada.

Esta memoria muscular de los modelos de negocio de Marketplace (mercado) y Router (enrutador) es clave para que OpenRouter pueda expandir rápidamente su ecosistema. Sabe que una vez que se establece el efecto de red de una plataforma de agregación, el costo de seguimiento para los nuevos entrantes aumentará exponencialmente. Durante su tiempo en OpenSea, Atallah experimentó cómo atraer usuarios al reducir la fricción en las transacciones y agregar activos de cola larga, formando finalmente una barrera de mercado bilateral. Esta experiencia se trasladó directamente al diseño del producto de OpenRouter: al unificar el formato de la API, ofrecer una amplia selección de modelos y reducir las barreras de acceso, OpenRouter atrajo rápidamente a una gran cantidad de desarrolladores. Cuando los desarrolladores se acostumbran a usar una clave para invocar todos los modelos, el costo de migración se vuelve extremadamente alto, y este efecto de red constituye su defensa más fundamental.

Por lo tanto, OpenRouter desde el principio no se posicionó como un simple agente de API, sino como un "mercado de modelos de IA", enfatizando la diversidad de modelos, la facilidad de acceso y la estabilidad del enrutamiento.

Un impuesto invisible del 5.5% y la transmisión de tokens: ¿para quién está pagando realmente el desarrollador?

El modelo de facturación oficial de OpenRouter afirma que "la transmisión de tokens no tiene recargo", es decir, OpenRouter cobra lo mismo que los fabricantes de modelos subyacentes. Su principal fuente de ingresos proviene de una tarifa de plataforma del 5.5% cobrada al recargar créditos (mínimo $0.80). Además, para los usuarios que utilizan claves API propias (BYOK), no hay tarifas hasta un límite de $25,000 al mes; cualquier cantidad que exceda se cobra con un 5% de tarifa.

Este modelo de facturación ha generado diferentes lógicas de cálculo en la comunidad de desarrolladores. Podemos deducir algunos escenarios típicos:

Para un desarrollador independiente o un equipo muy pequeño que realiza llamadas por un valor de 100 dólares al mes, usar la conexión directa oficial significa que necesita registrarse por separado en cuentas de OpenAI, Anthropic, etc., gestionar múltiples tarjetas de crédito y lidiar con diferentes formatos de documentación de API. Sin embargo, a través de OpenRouter, solo necesita pagar una tarifa de 5.5 dólares para obtener la experiencia de "una clave API para gobernarlos a todos" y disfrutar de la garantía de recuperación automática en caso de fallos. Esta experiencia sin preocupaciones es extremadamente atractiva para equipos de startups que iteran rápidamente.

Cuando la escala aumenta a un volumen de llamadas de 10,000 dólares al mes para equipos medianos, la tarifa de 550 dólares sigue siendo aceptable. En este punto, el equipo puede necesitar probar varios modelos de ajuste fino de código abierto; si implementan estos modelos por su cuenta, los costos de potencia y mantenimiento superan con creces los 550 dólares. La vasta biblioteca de modelos y las características listas para usar que ofrece OpenRouter les ayudan a ahorrar una gran cantidad de costos ocultos en la fase de selección de modelos.

Sin embargo, para grandes empresas que consumen un millón de dólares al mes, la situación es completamente diferente. La tarifa del 5.5% significa un "peaje" de 55,000 dólares al mes, suficiente para formar un equipo dedicado al mantenimiento de la puerta de enlace API. Esta es también la razón por la cual las grandes empresas a menudo optan por construir sus propias puertas de enlace.

Más interesante es la controversia sobre los costos ocultos. Aunque oficialmente se afirma que la transmisión de tokens es transparente, algunos desarrolladores han descubierto en comunidades como Hacker News y Reddit que las tarifas de algunos modelos populares en OpenRouter son ligeramente más altas que las de la conexión directa oficial. Los desarrolladores sospechan que hay un recargo dinámico o que algunos proveedores de terceros a los que se conecta OpenRouter tienen diferencias en los criterios de cálculo de tokens. Como se analiza en el artículo de OmniTools "Desglosando la estructura de precios de GPT-5.6: la ilusión del precio unitario y la lucha por el costo real de la tarea", la fijación de precios de API a menudo presenta ilusiones de precios unitarios, y los desarrolladores deben prestar atención al costo real de la tarea. La controversia sobre los costos ocultos de OpenRouter nos recuerda que al evaluar su modelo de negocio, no solo debemos considerar la publicidad oficial, sino también combinar los datos de invocación reales para calcular los costos. Si estas diferencias en las tarifas no se explican de manera transparente, podrían debilitar la confianza de los desarrolladores en su promesa de "transmisión de tokens".

Sin mantenimiento y mecanismo de recuperación: ¿por qué no LiteLLM o Portkey?

En el ámbito de las estaciones de transferencia de IA, OpenRouter no carece de competidores. Herramientas como LiteLLM y Portkey también están compitiendo por la atención de los desarrolladores. Sin embargo, la razón por la cual OpenRouter se destaca radica en su posicionamiento como "sin mantenimiento y gestionado" y su "amplia variedad de modelos".

LiteLLM es una biblioteca de proxy de Python de código abierto, adecuada para equipos con fuertes capacidades de mantenimiento y requisitos de privacidad de datos muy altos para construir su propia puerta de enlace. Su ventaja radica en ser de código abierto y gratuito, con datos completamente localizados y sin intermediarios, pero su desventaja es que el equipo debe mantener sus propios servidores y el código del proxy. Para grandes empresas con equipos dedicados de DevOps, LiteLLM ofrece un gran control, pero para equipos de startups que carecen de recursos de mantenimiento, este modelo de autoconstrucción tiene una barrera demasiado alta.

Portkey, por otro lado, es una puerta de enlace de IA empresarial y una plataforma de observabilidad, orientada a análisis de registros, caché y gestión de cumplimiento de seguridad. Su valor central radica en ayudar a las empresas a gestionar los modelos que ya han integrado, proporcionando registros de invocación detallados y monitoreo de rendimiento. Sin embargo, en términos de capacidad de agregación de modelos, Portkey no es tan rica como OpenRouter; se inclina más hacia la "gestión" que hacia el "mercado". Si la necesidad de un equipo es controlar de manera precisa la invocación de modelos existentes, Portkey es una mejor opción; si la necesidad es probar rápidamente varios nuevos modelos, OpenRouter tiene más ventajas.

En comparación, la ventaja central de OpenRouter radica en la experiencia de "sin mantenimiento" gestionada por SaaS y su vasta biblioteca de modelos. Se asemeja más a un mercado de modelos de IA, donde los desarrolladores pueden invocar modelos de ajuste fino de código abierto más recientes a un costo extremadamente bajo, sin necesidad de implementar por su cuenta. Más importante aún, su mecanismo de recuperación (Fallback). Cuando un proveedor de modelos de código abierto se cae o la API oficial limita el flujo, OpenRouter puede redirigir automáticamente las solicitudes a otros proveedores, garantizando la disponibilidad en el entorno de producción. Esta capacidad de recuperación es clave para diferenciarse de las estaciones de transferencia de "revender API" comunes y constituye su defensa. Para los equipos que integran capacidades de IA en sus procesos comerciales centrales, las limitaciones o caídas de los proveedores de modelos subyacentes son la norma; la capacidad de reintento automático y cambio de enrutamiento de OpenRouter está directamente relacionada con la continuidad del negocio.

Caja negra de cumplimiento de datos y punto único de fallo: preocupaciones ocultas detrás de la alta valoración

A pesar de que OpenRouter se destaca en la experiencia del desarrollador, como capa intermedia, enfrenta desafíos y limitaciones que no deben pasarse por alto.

Primero, está el problema de la "caja negra" de la privacidad de datos y el cumplimiento. Todos los prompts y respuestas pasan por los servidores de OpenRouter. Aunque la empresa ofrece una política de "cero retención de datos", para empresas en sectores altamente regulados como finanzas y salud, entregar datos críticos a una plataforma de agregación de terceros sigue planteando obstáculos de cumplimiento. En industrias fuertemente reguladas, la salida de datos sensibles a menudo está sujeta a estrictas limitaciones, y las empresas deben asegurarse de que los datos sensibles no pasen por nodos de terceros no auditados. Esta es también la razón por la cual competidores como Portkey, que enfatizan la localización de datos, aún tienen un lugar en el mercado empresarial.

En segundo lugar, está el problema del "punto único de fallo" y la latencia en el entorno de producción. Algunos desarrolladores experimentados han señalado en Hacker News que OpenRouter es más adecuado para escenarios de Dev/Chat o de baja a media concurrencia. En cadenas de producción críticas con alta concurrencia, cada salto adicional en la red añade latencia. Para aplicaciones en tiempo real que son extremadamente sensibles al tiempo de respuesta (como el comercio de alta frecuencia o la interacción de voz en tiempo real), este costo adicional de red puede convertirse en un cuello de botella. Además, si OpenRouter se cae, todos los servicios descendentes se paralizarán. Esta dependencia de la estabilidad de terceros es una de las principales preocupaciones de las grandes empresas al adoptar OpenRouter en sus negocios centrales. Si OpenRouter experimenta una falla global, todas las aplicaciones que dependen de él perderán instantáneamente la capacidad de IA; esta concentración de riesgo es un punto crítico que los defensores de las puertas de enlace autoconstruidas suelen criticar.

Finalmente, está la continua controversia sobre los costos ocultos. Aunque OpenRouter ha logrado un ciclo comercial a través de una tarifa del 5.5%, la aparición de tarifas ligeramente más altas en algunos modelos en comparación con la conexión directa oficial, si no se explica de manera transparente, podría debilitar la confianza de los desarrolladores en su promesa de "transmisión de tokens". En un momento en que los costos de invocación de API siguen siendo el principal gasto en aplicaciones de IA, los desarrolladores son extremadamente sensibles a los precios; cualquier regla de facturación poco clara podría convertirse en un motivo de fuga.

El rumor de adquisición de 10 mil millones de dólares, independientemente de si se concreta o no, ya ha colocado a OpenRouter en el centro del escenario de la infraestructura de IA. Ha demostrado que, en el ecosistema de IA, la capa intermedia de agregación y enrutamiento tiene un valor que no se puede ignorar. Pero para pasar de ser un "juguete para desarrolladores" a convertirse realmente en el "stack de IA empresarial", OpenRouter aún necesita proporcionar respuestas más claras en cuanto a cumplimiento de datos, optimización de latencia y transparencia de costos. Para los desarrolladores, elegir entre OpenRouter y construir su propia puerta de enlace es, en esencia, una cuestión de equilibrar la "experiencia sin preocupaciones" con el "control", y este punto de equilibrio determinará el futuro de OpenRouter.