Autor: Zhang Aila
Hoy hablemos de las estaciones de transferencia.
En pocas palabras, una estación de transferencia de modelos es colocar modelos como OpenAI, Claude, Gemini, DeepSeek, etc., detrás de un mismo punto de entrada, permitiendo a los desarrolladores utilizar una única interfaz, una cuenta y una factura unificada para llamar a múltiples modelos, y elegir, cambiar o utilizar modelos o proveedores alternativos.
Por supuesto, para los usuarios en China, una razón más importante para usar una estación de transferencia es acceder a modelos extranjeros y obtener precios más bajos.
Esto es algo que todos entienden, no profundizaremos en las estaciones de transferencia nacionales. Hoy nos centraremos principalmente en OpenRouter.
Para 2026, OpenRouter ya ha recaudado 113 millones de dólares en su Serie B, y su valoración se acerca a los 13.000 millones de dólares.
Es decir, ya es una empresa unicornio.
Analicemos por qué una estación de transferencia de modelos que "no construye modelos" puede valer tanto dinero.
¿Qué hace realmente OpenRouter?
La posición oficial de OpenRouter es: una interfaz unificada para modelos grandes.
Actualmente, OpenRouter admite más de 400 modelos y más de 70 proveedores de modelos.
El sitio web también revela que la plataforma procesa mensualmente 100 billones (trillones) de tokens y tiene más de 10 millones de usuarios en todo el mundo.
En el anuncio de financiación de la Serie B de mayo de 2026, también se menciona que en los últimos 6 meses, el volumen de procesamiento semanal de OpenRouter ha crecido de 5 billones a 25 billones de tokens, y sirve a más de 8 millones de desarrolladores.
Estas cifras demuestran una cosa:
OpenRouter ya no es una pequeña herramienta para desarrolladores, sino un gran punto de entrada para llamadas de IA.
La forma en que los desarrolladores lo utilizan también es muy sencilla.
Antes, tenías que integrarte por separado con OpenAI, Anthropic, Google, DeepSeek, Mistral, xAI, etc.
Por cada integración, debías revisar la documentación, solicitar una API key, vincular la facturación, manejar diferencias en las interfaces, revisar reglas de limitación de tasa y gestionar excepciones.
Al usar OpenRouter, los desarrolladores pueden llamar a diferentes modelos a través de la misma interfaz.
A menudo, el código que antes utilizaba la interfaz de OpenAI solo necesita cambiar la URL base, reemplazar la API key y especificar el nombre del modelo para poder llamar a otros modelos a través de OpenRouter.
Esta es también una de las razones de su rápido crecimiento inicial: el bajo coste de migración.
¿Por qué los desarrolladores no se conectan directamente con las compañías de modelos?
Parece que los desarrolladores podrían evitar OpenRouter yendo directamente a los sitios web de las compañías de modelos para activar sus APIs.
Pero en el desarrollo real, esto no es tan simple.
Si un producto de IA es solo un demo, con un solo modelo basta. Pero una vez que entra en un negocio real, es difícil depender únicamente de un modelo.
Por ejemplo, una herramienta de escritura con IA puede tener varios tipos de tareas diferentes:
- Generar títulos: con un modelo barato es suficiente;
- Escribir artículos largos: requiere un modelo con mayor capacidad de texto;
- Analizar datos: necesita un modelo con contexto largo;
- Moderación de contenido: necesita capacidad de clasificación de bajo coste y alta estabilidad;
- Los clientes empresariales exigen que los datos no se retengan, por lo que deben elegir proveedores que cumplan con las políticas de datos;
- En horas pico, si el modelo tiene limitación de tasa, es necesario cambiar automáticamente a un modelo alternativo.
En este punto, el problema no es solo "conectar una API".
El equipo debe mantener un sistema completo de llamadas a modelos:
Qué modelo es responsable de cada tarea, cuál es más barato, qué proveedor es más rápido, cuál tiene una tasa de fallos más baja, cómo cambiar si hay problemas, cómo atribuir los costes en las facturas, cómo aislar los datos de los clientes empresariales.
Lo más complicado es que el mercado de modelos cambia muy rápido.
Hoy Claude es bueno para escribir código, mañana Gemini tiene ventaja con el contexto largo, pasado mañana DeepSeek o algún modelo de código abierto reduce el precio.
Las capacidades de los modelos, los precios, la longitud del contexto, las políticas de los proveedores... todo está en constante cambio.
Aquí es donde radica el valor de OpenRouter.
No se trata de escribir aplicaciones de IA para los desarrolladores, sino de gestionar para ellos "qué modelo usar, cómo llamarlo, cómo tener respaldo, cómo controlar los costes".
No solo es un supermercado de modelos, es una capa de orquestación de modelos
Si solo ves OpenRouter como un "supermercado de modelos", lo estás subestimando.
Un supermercado de modelos resuelve "aquí hay muchos modelos, puedes elegir".
Pero la capacidad realmente importante de OpenRouter es orquestar entre modelos y proveedores.
El mismo modelo puede ser proporcionado por diferentes proveedores de servicios de inferencia.
Por ejemplo, un modelo de código abierto puede estar alojado por varios proveedores de servicios en la nube o de inferencia. El precio, la velocidad y la estabilidad no son los mismos entre proveedores.
En la documentación de OpenRouter hay una capacidad llamada "provider routing", o enrutamiento de proveedores.
Los desarrolladores pueden, según condiciones como precio, latencia, rendimiento, orden de proveedores, etc., hacer que las solicitudes pasen automáticamente por diferentes proveedores.
También admite "fallback", es decir, si un modelo o proveedor falla, el sistema cambia automáticamente a una opción alternativa.
Para los desarrolladores, OpenRouter equivale a separar la "selección de modelos" y el "manejo de fallos" del código de negocio, y delegárselo a una plataforma especializada.
¿Por qué las empresas necesitarían esta capa?
Cuando una empresa adopta la IA, los primeros problemas suelen ser "si se puede usar", pero rápidamente se convierten en "cómo gestionarlo".
Dentro de una empresa, puede haber muchos equipos utilizando IA.
El equipo de marketing la usa para crear contenido, el de servicio al cliente para responder a usuarios, el de desarrollo para escribir código, el de operaciones para analizar datos, el legal para procesar contratos.
Si cada equipo se conecta a los modelos por su cuenta, los problemas se multiplican:
- No se distingue la facturación; la selección de modelos no es uniforme;
- Las políticas de datos no son transparentes; diferentes equipos realizan integraciones duplicadas;
- Si hay un problema, nadie sabe de qué llamada se trata;
- Si cambian los proveedores de modelos, es difícil ajustar el sistema de manera unificada.
Las áreas de trabajo, el control de presupuestos, los registros de llamadas, las estrategias de proveedores y el enrutamiento con retención de datos cero que proporciona OpenRouter están diseñados para resolver estos problemas.
Por ejemplo, la retención de datos cero.
Para muchas empresas, no se pueden enviar todas las solicitudes a cualquier proveedor de modelos. La información de clientes, el contenido de contratos, datos médicos, financieros, pueden tener requisitos estrictos.
La documentación de OpenRouter admite "Zero Data Retention", o retención de datos cero.
Los desarrolladores pueden configurar que las solicitudes solo se envíen a proveedores que no almacenen datos. Esta política se puede aplicar a nivel global, por grupo de modelos, regla de seguridad o solicitud individual.
Otro ejemplo es el "prompt caching", o caché de prompts.
Muchas aplicaciones de IA utilizan repetidamente prompts de sistema largos, contenido de bases de conocimiento o contexto. Si cada vez se recalcula, el coste es muy alto.
OpenRouter admite aumentar la tasa de aciertos de caché mediante el enrutamiento por afinidad de proveedor, intentando que las solicitudes posteriores vayan al mismo endpoint del proveedor, reduciendo así el coste del contexto repetido.
Este tipo de funciones no suenan muy atractivas, pero son muy prácticas, y cuanto mayor sea la escala de la aplicación de IA, más evidentes serán los ahorros.
¿Cómo gana dinero OpenRouter?
El modelo de negocio de OpenRouter es claro: gana dinero según el uso.
Los desarrolladores primero compran créditos en la plataforma, luego pagan según los modelos y tokens realmente utilizados.
OpenRouter lo explica claramente:
La plataforma cobra una tarifa del 5.5% al comprar créditos, con un mínimo de 0.8 dólares; el precio del proveedor del modelo subyacente se transfiere al usuario al precio original, sin recargos adicionales en el precio de inferencia del modelo.
Este es un negocio típico de "peaje por tráfico".
La ventaja de este modelo es que los ingresos están vinculados al volumen de uso.
Cuantas más llamadas hagan los desarrolladores, mayores serán los ingresos de la plataforma; cuantas más aplicaciones de IA haya y más tokens se consuman, mayor será el negocio de OpenRouter.
Pero también tiene una característica: la comisión por transacción no es alta, por lo que debe depender de la escala.
Es por eso que el volumen de procesamiento de tokens es tan importante para OpenRouter.
Su métrica principal no es el número de usuarios registrados, sino cuántos tokens pasan por ella semanal o mensualmente.
En 2025, el volumen anual procesado por OpenRouter creció de aproximadamente 10 billones a más de 100 billones de tokens.
Para 2026, OpenRouter ya alcanzaba un volumen de procesamiento anualizado de aproximadamente 1.5 mil billones (cuatrillones) de tokens.
Esta es la lógica subyacente de este negocio.
Mientras más aplicaciones de IA funcionen en sistemas multi-modelo, OpenRouter podrá extraer continuamente tarifas de servicio de esas llamadas.
¿Por qué el crecimiento reciente ha sido tan rápido?
El crecimiento de OpenRouter, en resumen, se ha beneficiado de tres cambios.
El primer cambio es la proliferación de modelos.
Antes, al desarrollar una aplicación de IA, muchos equipos usaban OpenAI por defecto. Ahora es diferente.
Claude, Gemini, DeepSeek, Qwen, Mistral, Llama, Grok, además de una gran cantidad de modelos de código abierto y pesos abiertos, tienen ventajas en diferentes escenarios.
Este no es un mercado de "quién reemplaza completamente a quién".
Algunos modelos son buenos para escribir código, otros son baratos, otros tienen un contexto largo fuerte, otros son rápidos, otros son adecuados para role-playing, otros para documentos empresariales, otros para multimodalidad.
Cuanto más modelos hay, mayor es el coste de elección; cuanto mayor es el coste de elección, más valiosa es la capa intermedia.
El segundo cambio es que las aplicaciones de IA comienzan a preocuparse por los costes.
Muchos productos inicialmente usan el modelo más potente, porque primero deben demostrar resultados.
Pero una vez que el producto tiene usuarios, el coste de los modelos rápidamente se convierte en un problema.
Un chatbot de servicio al cliente, un producto de búsqueda con IA, un asistente de código, una herramienta de generación de contenido... si todas las solicitudes pasan por el modelo más caro, el margen bruto se puede comer fácilmente.
Una práctica más madura es dividir las tareas:
- Tareas simples con modelos baratos;
- Tareas complejas con modelos potentes;
- Tareas de alta frecuencia priorizando modelos de baja latencia;
- Cambiar a un modelo alternativo tras un fallo;
- Cuando se trata de datos sensibles, usar solo proveedores que cumplan con las políticas de datos.
Este es precisamente el escenario de uso de OpenRouter.
No necesariamente te ayuda a encontrar el "modelo más potente", pero sí te ayuda a equilibrar entre efectividad, precio, velocidad y estabilidad.
El tercer cambio es que las aplicaciones de IA están pasando de cuadros de chat a agentes inteligentes.
Los agentes inteligentes llaman a herramientas, leen archivos, buscan en la web, ejecutan tareas y también realizan múltiples llamadas consecutivas al modelo.
En comparación con el chat ordinario, los agentes consumen más tokens y dependen más de la estabilidad.
Esto es favorable para OpenRouter.
Porque cuantas más llamadas haya y más larga sea la cadena, más necesitan los desarrolladores enrutamiento, respaldo, registros, control de costes y gestión de proveedores.
Por eso en el anuncio de financiación de OpenRouter se enfatiza que la IA está pasando de la experimentación a aplicaciones críticas de producción y escenarios de agentes inteligentes.
Su crecimiento proviene esencialmente del aumento en el volumen de llamadas a la IA.
Este negocio también tiene riesgos
La posición de OpenRouter es buena, pero no es segura.
Está atrapado entre las compañías de modelos, los proveedores en la nube y los desarrolladores de aplicaciones. Esta posición tiene valor, pero también es fácil de comprimir.
El primer riesgo es que las grandes empresas pueden construir su propia solución.
Para equipos pequeños, OpenRouter es muy conveniente.
Pero para las grandes empresas, el enrutamiento de modelos, los permisos, los registros, la gestión de costes, también pueden hacerlo ellos mismos, o delegarlo a los proveedores en la nube.
Especialmente los clientes financieros, médicos, gubernamentales y empresariales, pueden preocuparse más por el control de datos y el despliegue privado.
Para que OpenRouter ingrese a estos clientes, no puede depender solo de "tener muchos modelos". Debe profundizar lo suficiente en permisos, auditoría, políticas de datos, gestión de proveedores y soporte empresarial.
El segundo riesgo es que los proveedores en la nube también harán pasarelas de modelos.
Plataformas en la nube como AWS, Google Cloud, Azure ya tienen clientes empresariales, sistemas de facturación, sistemas de permisos y capacidades de cumplimiento.
Podrían integrar completamente las llamadas multi-modelo, el enrutamiento, la monitorización y la gestión de costes como parte de sus servicios en la nube.
La ventaja de OpenRouter es su apertura y neutralidad, una cobertura de modelos más amplia y una integración más rápida.
Pero la ventaja de los proveedores en la nube son las relaciones con los clientes y los procesos de compra empresarial. Esta es una competencia a largo plazo.
El tercer riesgo es la relación con los proveedores de modelos.
OpenRouter aporta tráfico a las compañías de modelos, pero también aleja a estas compañías de los desarrolladores finales.
A medida que la plataforma crece, obtendrá más relaciones con usuarios y datos de uso de modelos.
Los proveedores de modelos, aunque desean la distribución, también se preocupan por ver debilitado su poder de negociación.
Este tipo de plataformas intermedias suelen ser bienvenidas por el lado de la oferta en las primeras etapas; cuando su escala aumenta, la relación se vuelve más delicada.
El cuarto riesgo es que la tarifa de la plataforma pueda reducirse.
OpenRouter cobra un 5.5% de tarifa de plataforma, lo que ahora parece bajo.
Pero si surgen más servicios similares, los desarrolladores compararán precios, estabilidad, cobertura de modelos y funciones empresariales.
Si algunos competidores están dispuestos a tarifas más bajas, o si los proveedores en la nube integran este tipo de capacidades en sus servicios existentes, OpenRouter necesita demostrar que no es solo un "reenviador de solicitudes".
Debe seguir proporcionando un mejor enrutamiento, una cobertura de modelos más fuerte, precios más transparentes, servicios más estables y controles empresariales más completos.
