OpenRouter
Por qué importa
En profundidad
OpenRouter se sitúa entre una aplicación y los muchos proveedores que realmente ejecutan los modelos. Un desarrollador envía una petición de chat-completion a un único endpoint y nombra el modelo de destino con un identificador con prefijo de proveedor, como una variante de Claude de Anthropic o un lanzamiento de Llama de pesos abiertos. OpenRouter normaliza la petición al formato que espera el proveedor upstream, la reenvía, mide los tokens y devuelve la respuesta en un esquema consistente. La facturación funciona con créditos prepagados, así que cien modelos distintos aparecen en una sola factura en lugar de cien suscripciones separadas. El resultado es que la elección del modelo deja de ser una decisión de infraestructura y pasa a ser una línea de configuración que puede cambiar por petición, por función o por experimento.
Una API, muchos back ends
El truco central es que la pasarela habla la forma de API popularizada por OpenAI, así que la mayoría del código existente funciona con solo una nueva URL base y clave. Los modelos frontera de Anthropic y Google se proxean desde sus APIs propias, mientras que los modelos de pesos abiertos son servidos por proveedores de inferencia independientes como Together AI y Fireworks AI. Como varios back ends suelen alojar el mismo modelo abierto, OpenRouter puede enrutar cada petición por precio, rendimiento o disponibilidad, y recurrir a otro proveedor cuando el primero falla o alcanza sus límites de tasa. Solo ese failover elimina toda una clase de caídas nocturnas para equipos pequeños que no pueden negociar redundancia con cada proveedor por su cuenta.
Cuánto cuesta y qué registra
El precio es de pago por uso por token, generalmente trasladando las tarifas del proveedor upstream con una pequeña comisión encima, así que no hay suscripción que justificar antes de experimentar. El compromiso es directo: a volúmenes bajos y medios domina la comodidad de una sola factura y cero configuración por proveedor, mientras que a volúmenes muy grandes un contrato directo con un proveedor suele ser más barato. La parte del panel de control del producto es posiblemente tan útil como el enrutamiento. Cada petición queda registrada con su modelo, recuento de tokens, coste y latencia, lo que facilita ver cuánto cuesta realmente una función por usuario y detectar un cambio de prompt que duplicó silenciosamente el gasto. Para equipos que hacen evaluación rápida, poder ejecutar el mismo prompt en una docena de modelos con una sola factura, y luego leer coste y velocidad lado a lado, comprime semanas de onboarding de proveedores en una tarde.
El leaderboard de rankings
Como gran parte del tráfico fluye por una sola pasarela, OpenRouter publica un leaderboard público que clasifica los modelos por el volumen de tokens que sus usuarios realmente les envían. Es una señal distinta de la de los benchmarks de calidad como Chatbot Arena: muestra lo que los desarrolladores despliegan en producción, no qué modelo gana una votación cara a cara, y a menudo saca a la luz lanzamientos de pesos abiertos en ascenso rápido semanas antes de que la industria en general se dé cuenta. Las cifras requieren cierto cuidado al interpretarlas, ya que la base de usuarios se inclina hacia desarrolladores y aficionados más que hacia el mercado completo, y los modelos gratuitos o muy descontados reciben un impulso natural. Aun así, como lectura casi en tiempo real de qué modelos están ganando cuota de uso real, se ha convertido en una de las fuentes de datos públicas más citadas del sector.
No ejecuta los modelos por sí misma
Un concepto erróneo común es que OpenRouter es una empresa de servicio de modelos con su propia flota de GPU. En la práctica es sobre todo un proxy y un marketplace: salvo pocas excepciones, la petición sale de tu infraestructura, pasa por OpenRouter y se ejecuta en el hardware de un proveedor tercero. Eso tiene implicaciones reales. Los prompts y las respuestas son visibles para al menos dos partes adicionales, y las condiciones de retención de datos varían según el proveedor upstream en lugar de fijarlas solo la pasarela, así que las cargas de trabajo sensibles necesitan una revisión de política por proveedor en lugar de una aprobación general. El salto de red adicional también puede añadir latencia, y una caída en la propia pasarela derriba todos los modelos a la vez. Nada de esto anula la comodidad, pero los equipos deberían tratar OpenRouter como una capa de enrutamiento y facturación con su propia superficie de confianza, no como la entidad que genera sus respuestas.