Cómo funciona LLM Live

Cada diagnóstico de este sitio se basa en reglas públicas que puedes consultar aquí. Ningún proveedor paga por aparecer y los números que ves abajo son exactamente los mismos que usa el código.

Estado

Un veredicto a partir de cuatro señales. Prevalece la peor.

Nuestras comprobaciones: Donde disponemos de clave de API, un worker envía una pequeña petición en streaming (contar del 1 al 20, máximo 80 tokens) a la propia API del proveedor cada 60–120 segundos y registra el tiempo hasta el primer token y los tokens por segundo. Si una comprobación falla, se reintenta dos veces con 20 segundos de intervalo. Los límites de tasa (rate limits) y los errores de nuestra propia infraestructura no se contabilizan. La página de cada servicio indica si nuestras comprobaciones están activas para él.
Reglas: Últimas 3 comprobaciones fallidas → Caída total (Major outage). Al menos la mitad de las comprobaciones en 10 minutos fallidas → Caída parcial (Partial outage). Al menos un 20% fallidas, o la mediana del tiempo hasta el primer token supera los 3 s y es 3 veces más lenta que su mediana de 24 horas → Degradado (Degraded).
Páginas oficiales de estado: Se consultan cada minuto. Se descarta cualquier estado con más de 15 minutos de antigüedad, de modo que una página bloqueada no pueda mantener un servicio artificialmente en verde o en rojo.
Vía OpenRouter: OpenRouter publica la tasa de peticiones con éxito de cada proveedor para cada modelo. Si al menos 2 modelos en los endpoints directos del proveedor, y al menos la mitad de ellos, bajan del 80% en 30 minutos y están 10 puntos por debajo de su nivel habitual de 24 horas → Degradado; por debajo del 50% de media → Caída parcial. Si fallan 3 o más proveedores a la vez, se considera un problema de OpenRouter y se ignora esta señal.
Reportes de usuarios: Al menos 10 reportes en 15 minutos y como mínimo 4 veces la tasa habitual → Degradado. Los reportes por sí solos nunca marcan un servicio como caído.
Recuperación y alertas: El estado se reevalúa cada 30 segundos. Un servicio vuelve a Operativo solo tras 3 minutos sin incidencias, evitando que una API intermitente sature de alertas. Se envían notificaciones cuando un problema empieza, se agrava o se resuelve.
Barras: Cada barra representa 30 minutos y se colorea según el peor estado registrado en ese intervalo. El gris indica falta de datos. El uptime es el porcentaje de barras sin incidentes.

Modelos y precios

Todos los precios proceden de una API pública y se actualizan cada 5 minutos.

Fuente: El catálogo de modelos, los precios y las ventanas de contexto proceden de la API pública de OpenRouter. Los precios se indican por 1M de tokens tal como los lista OpenRouter; suelen coincidir con los precios directos del proveedor, pero no siempre.
Historial de precios: Guardamos una captura cada 5 minutos y registramos cada variación, por lo que las bajadas de precio, los modelos nuevos o los descatalogados aparecen en el canal de noticias en cuestión de minutos.
Dónde ejecutarlo: El número de proveedores distintos que ofrecen un modelo en OpenRouter. Se excluyen los niveles flex, batch, priority y spot, ya que a menudo no están disponibles de forma garantizada.

Arena de ajedrez

Los modelos se enfrentan entre sí. Un motor de ajedrez garantiza la imparcialidad.

Una jugada: El modelo recibe la posición (FEN) y la lista de movimientos previos, y responde con una jugada y un breve comentario. La validez legal se comprueba con chess.js. Si hace un movimiento ilegal, recibe la lista de jugadas legales y vuelve a intentarlo; al tercer movimiento ilegal pierde la partida. Tres respuestas seguidas sin movimiento conllevan la derrota por tiempo.
Límite de razonamiento: El razonamiento está limitado a 1024 tokens por jugada para que la partida cueste céntimos. Esto reduce el rendimiento real de los modelos de razonamiento avanzado: la arena compara modelos bajo un mismo presupuesto estricto, no en su máximo potencial.
Puntuación: Glicko-2, que tiene en cuenta la incertidumbre de la puntuación. La clasificación se ordena por puntuación menos dos desviaciones típicas, una estimación conservadora. Un modelo es provisional hasta que completa 10 partidas. Los emparejamientos priorizan modelos con menos partidas y puntuaciones similares.
Precisión: Stockfish evalúa cada posición a profundidad 14. Una pérdida de probabilidad de victoria de 5, 10 o 15 puntos se clasifica como imprecisión, error o fallo grave; el cálculo de precisión sigue la fórmula de Lichess.
Partidas no puntuadas: Una partida interrumpida por errores de API del proveedor no puntúa. También se puede anular una partida de forma manual indicando públicamente el motivo.

Votos humanos

Tú eliges la mejor entre dos respuestas anónimas. Un modelo Bradley–Terry convierte los votos en puntuaciones.

Una batalla: Tu consulta se envía a dos modelos distintos elegidos de un conjunto de unos 20 modelos actuales de una docena de laboratorios; la posición de cada uno se asigna al azar y los nombres permanecen ocultos hasta que votas. Los modelos y parejas con menos votos aparecen con más frecuencia; los modelos insignia más caros, con menos. Cada respuesta tiene un límite de 1024 tokens sin razonamiento (o 512 tokens si no se puede desactivar), evaluando así respuestas rápidas del día a día y no el rendimiento a máxima capacidad.
Votos: Solo puedes votar cuando ambas respuestas se han completado, y una sola vez por batalla. Un voto por A o B cuenta como victoria para ese modelo; el empate y la opción «ambas son malas» suman media victoria a cada uno, al igual que en LMArena. Las batallas en las que un modelo no respondió no se contabilizan.
Puntuación: Se ajusta un modelo Bradley–Terry a todos los votos simultáneamente, por lo que, a diferencia del sistema Elo, el orden de los votos no altera el resultado. Se muestra en escala Elo: una diferencia de 400 puntos implica una probabilidad de preferencia de 10 a 1, y el modelo mediano se fija en 1000. Una distribución a priori suave (un empate virtual por modelo) evita puntuaciones infinitas en modelos invictos.
Intervalo de confianza: El intervalo del 95% se calcula a partir de 100 remuestreos bootstrap de los votos. La posición en el ranking es 1 más el número de modelos cuyo intervalo completo queda por encima del de este modelo; por tanto, los modelos con intervalos solapados comparten puesto. Los modelos con menos de 20 votos figuran al final. Todo el cálculo se actualiza cada 10 minutos.
Categorías: Un modelo de lenguaje ligero clasifica los prompts votados en programación, matemáticas, escritura creativa, consejos y guías, conocimientos y hechos u otros, y detecta el idioma; la clasificación de prompts en ruso utiliza exclusivamente consultas en ese idioma. Un modelo entra en una categoría en cuanto alcanza al menos 20 votos en ella.
Limitaciones: Cualquiera puede votar de forma anónima. Los límites por visitante (8 batallas por hora, 40 al día, rastreadas mediante un hash con sal de la dirección IP) y un presupuesto diario dificultan la manipulación masiva, aunque no la impiden del todo. Los usuarios valoran tanto el estilo como el fondo: las respuestas más largas y bien maquetadas suelen ganar más votos. Los prompts se conservan para la clasificación por categorías y pueden publicarse de forma agregada; las direcciones IP directas nunca se almacenan.

Debates

Dos modelos debaten una moción en tres rondas. Un juez IA puntúa por partida doble y luego vota el público.

Mociones: Unas 40 mociones seleccionadas en cinco categorías: tecnología e IA, sociedad, ciencia, ética y vida cotidiana, redactadas en inglés y en ruso. Excluimos elecciones y candidatos políticos, religión contra religión y cualquier ataque a colectivos. La siguiente moción es la menos utilizada que no figure entre las últimas diez; uno de cada tres debates se realiza en ruso.
Debatientes: Dos modelos distintos extraídos del grupo de unas 20 opciones actuales. Los modelos con menos debates y los emparejamientos menos frecuentes se eligen con más frecuencia; los modelos insignia de alto coste, con menos. La postura (A favor o En contra) se asigna al azar, de modo que el modelo no elige su postura ideológica afín. Si un modelo acumula fallos continuados, queda pausado 2 horas (o 24 horas tras un error grave de cuenta o del modelo). Cada 30–60 minutos arranca un nuevo debate, mientras el presupuesto diario lo permita.
Personajes: Desde el 29 de octubre de 2026 los modelos debaten asumiendo un papel: dos personajes de un elenco de diez figuras de ficción (sin personalidades reales, políticas ni religiosas), cada uno con su propio estilo de comunicación. Los personajes se asignan independientemente de los modelos, priorizando los que han participado menos. Cada personaje mantiene una memoria: su historial, sus antecedentes contra el adversario de hoy, notas breves de sus tres debates previos y una frase célebre característica, datos que se inyectan en su prompt. Un modelo ligero (Qwen Flash) redacta las notas tras cada debate; pasan los mismos filtros de moderación y las citas solo se aceptan si coinciden palabra por palabra con la intervención del personaje. La clasificación de personajes usa los veredictos del juez con la misma metodología; el juez tiene orden de puntuar los argumentos, no el estilo del personaje.
Rondas: Seis intervenciones en estricta alternancia: declaraciones iniciales, réplicas y conclusiones. La postura A favor abre cada ronda y En contra responde, reservándose la última palabra. Cada debatiente conoce la moción, su postura y toda la transcripción previa acumulada, con un límite de 250 palabras (600 tokens, u 800 en ruso) y el razonamiento desactivado (o topado a 512 tokens si no se puede desactivar). Tienen instrucción expresa de no inventar datos estadísticos ni citas, y de no identificarse con su nombre real.
Moderación: Cada intervención pasa por un filtro previo: Llama Guard 4, un clasificador de seguridad ligero, con un modelo general pequeño como respaldo. Si una intervención no pasa el filtro, su texto se sustituye por «eliminado por moderación», el debate se cancela de inmediato y queda fuera de toda clasificación.
Juez: Un modelo compacto de un laboratorio diferente al de ambos participantes (Claude Haiku, DeepSeek Flash o Qwen Flash) lee las intervenciones agrupadas por bando, sin conocer la identidad de los modelos, califica a cada bando del 1 al 10 en argumentación, refutación y claridad, y proclama un ganador con una breve justificación. Evalúa el debate dos veces: una leyendo primero los textos A favor y otra leyendo primero los textos En contra, neutralizando así la tendencia de los jueces LLM a favorecer la primera postura que leen. Solo se declara ganador a un bando si coincide en ambas pasadas; de lo contrario, el resultado es empate.
Votación del público: Al concluir un debate, cualquier usuario puede votar A favor, En contra o Empate durante 7 días: un voto por debate y visitante (controlado por un hash con sal de la IP, nunca la IP en claro) y un máximo de 30 votos por hora. Los resultados se muestran tras votar, al igual que el veredicto del juez (salvo que solicites verlo antes). Un debate puntúa para el ranking del público en cuanto reúne al menos 5 votos; decide la opción mayoritaria y el empate entre A favor y En contra computa como tablas.
Clasificaciones: Dos tablas basadas en Bradley–Terry con el mismo método de las batallas: una calculada a partir de los veredictos del juez y otra de las mayorías del público; los empates otorgan media victoria a cada parte. Todo se ajusta de forma global, por lo que el orden cronológico no influye y los debates anulados simplemente se descartan. Escala Elo con el modelo mediano fijado en 1000, intervalo de confianza del 95% mediante 100 remuestreos bootstrap, y los modelos con menos de 10 debates puntuados colocados al final. Se recalcula cada 15 minutos.
Limitaciones: Este sistema mide la capacidad de debatir bajo límites estrictos de tiempo y extensión, no la posesión de la verdad: un modelo hábil puede ganar defendiendo una premisa débil. El juez es un modelo pequeño con sesgos propios, como premiar un tono excesivamente asertivo; invertir el orden de lectura elimina el sesgo de posición, pero no todos los sesgos. Ciertas mociones pueden favorecer a un bando por su propia naturaleza, pero como la asignación de lados es aleatoria, el efecto se neutraliza tras muchos debates.

Arena de código

Los modelos resuelven el mismo problema en Python o JavaScript. Deciden los tests ocultos; la velocidad solo desempata.

Problemas: 71 problemas seleccionados: 12 fáciles, 21 medios y 38 difíciles. Los más accesibles cubren algoritmos clásicos y procesamiento de cadenas o datos (CSV, versiones, logs, rutas JSON); los complejos exigen algoritmos avanzados o una lógica muy rigurosa: árboles de segmentos perezosos (lazy segment trees), flujo máximo y emparejamiento, autómatas de sufijos, programación dinámica sobre árboles y bitmasks, geometría con enteros exactos, un pequeño intérprete, un libro de órdenes de mercado o un planificador. Cada problema consta de enunciado, firma de función, ejemplos visibles, entre 6 y 19 tests ocultos con casos límite y, en 66 de ellos, entradas masivas bajo límite de tiempo. Los resultados esperados se basan en soluciones de referencia contrastadas por fuerza bruta contra miles de entradas aleatorias pequeñas. El límite de tiempo equivale al doble de la más lenta de tres ejecuciones aisladas en sandbox de la solución de referencia y de una solución estándar de manual, más 100 ms: el algoritmo óptimo pasa con holgura, uno cuadrático no. Seis de cada diez rondas plantean un problema difícil, tres uno medio y una uno fácil; dentro de cada nivel se selecciona el menos usado que no haya aparecido en los últimos diez.
Una ronda: Cuatro modelos de un grupo de unos 20 especializados en código, a ser posible uno por laboratorio, reciben el enunciado al mismo instante con el razonamiento desactivado (o topado a 1024 tokens si no es posible desactivarlo) y un límite de 2048 tokens por respuesta, ampliado a 4096 en problemas difíciles. Aproximadamente dos de cada tres rondas se disputan en Python 3.12 y una en JavaScript (Node.js 24) sobre uno de los 65 retos cuyas entradas y salidas son transparentes para JavaScript (sin enteros por encima de 2^53); JavaScript compite con idénticos tests y límites de tiempo, con la firma y los ejemplos adaptados a su sintaxis. Los modelos deben contestar con un único bloque de código; extraemos el bloque que declare la función requerida. El tiempo de respuesta se mide desde el envío de la petición hasta recibir el resultado completo y se muestra a título orientativo. Cada 20–30 minutos arranca una nueva ronda, mientras el presupuesto diario lo permita.
Sandbox: Cada solución se ejecuta una única vez dentro de un contenedor nuevo bajo gVisor: sin conexión a red, sistema de archivos de solo lectura, 512 MB de memoria por contenedor (unos 380 MB útiles para código Python; en JavaScript, un heap de 192 MB más buffers), un núcleo de CPU, 64 procesos, una carpeta temporal de 16 MB y salida estándar limitada. El código corre en un proceso independiente; un proceso supervisor externo le suministra las pruebas una a una y cronometra cada llamada desde el exterior, desde que envía la entrada hasta que recibe el resultado completo, impidiendo que el código altere o consulte el reloj. Si un test agota el tiempo o provoca la caída del proceso, se interrumpe y los restantes se evalúan en un proceso limpio. Las respuestas esperadas jamás entran al contenedor: el supervisor devuelve un hash del resultado que se valida desde fuera. Los ejemplos visibles muestran lo devuelto por el código; las entradas y salidas de los tests ocultos no se revelan nunca.
Puntuación: Un problema se considera resuelto solo cuando supera todos los tests, incluidas las entradas masivas dentro del tiempo límite. En cada ronda, cada par de modelos conforma un duelo que se dirime por el porcentaje de tests superados. La velocidad solo entra en juego en caso de empate exacto: el código cuyo tiempo de ejecución total en el sandbox sea al menos un 25% y 20 ms inferior se anota la victoria; de lo contrario, es empate. La rapidez con la que el modelo generó la respuesta no influye en ningún caso. Hasta el 28 de octubre de 2026 el tiempo de generación servía para desempatar soluciones correctas; en esa fecha se recalcularon todas las clasificaciones históricas bajo el reglamento actual.
Clasificación: Modelo Bradley–Terry aplicado a todos los duelos en conjunto, con la misma base que los votos de batallas: escala Elo situando la mediana en 1000, intervalo de confianza del 95% obtenido con 100 remuestreos bootstrap, y los modelos con menos de 10 rondas puntuadas relegados al final. Si un modelo no responde por fallo de su proveedor, queda excluido de esa ronda y entra en pausa durante 2 horas (o 24 horas si el fallo es de cuenta o del modelo).
Limitaciones: La clasificación evalúa un único intento por problema (pass@1), sin opción de ejecutar ni depurar el código previamente, bajo un presupuesto de tokens estricto; no refleja el rendimiento de los modelos en entornos de desarrollo interactivos. Los tiempos de ejecución se miden en un servidor compartido, por lo que las variaciones mínimas son mero ruido; de ahí que solo se computen diferencias notables. Los límites temporales se calibraron tomando como base Python, por lo que resultan más holgados para JavaScript, que suele ser más rápido. Los enunciados están exclusivamente en inglés y los 71 problemas acabarán repitiéndose; un modelo podría haber visto retos similares durante su entrenamiento.
Segundo intento: Si el código de un modelo falla en cualquier test, se le concede un turno extra facilitándole su código anterior y los resultados: cuántas pruebas pasó, cada ejemplo visible fallado con su resultado obtenido frente al esperado o el error devuelto, y, en el caso de los tests ocultos y de gran volumen, únicamente cuántos fallaron y por qué motivo, sin mostrar nunca sus entradas. El nuevo código pasa por los mismos tests. Se expone debajo de la primera respuesta y figura en la clasificación como corregido / reintentado, sin alterar nunca las posiciones ni las puntuaciones oficiales.

Gráficos

Los gráficos de mercado se basan exclusivamente en nuestros propios datos. Donde la muestra es pequeña, se indica claramente.

Precio vs. calidad: El precio corresponde al coste combinado por 1M de tokens en una proporción de 3 tokens de entrada por 1 de salida (el estándar aplicado en todo el sitio), representado en escala logarítmica; se excluyen los modelos gratuitos. La calidad refleja la puntuación de votos humanos (Bradley–Terry) cuando al menos 5 modelos acumulan 20 o más votos, o en su defecto la puntuación de ajedrez (Glicko-2); puedes alternar entre ambas. Un modelo forma parte de la frontera de Pareto si no existe ninguna opción más barata con mejor puntuación. Con menos de 3 modelos con puntuación consolidada, la frontera se traza incluyendo modelos provisionales, advirtiéndolo de forma explícita. No importamos métricas de rankings externos.
Fechas de lanzamiento: El trimestre de un modelo corresponde a la fecha en que se incorporó al catálogo de OpenRouter, lo que suele ocurrir pocos días después de su lanzamiento oficial. Las versiones fechadas de un mismo modelo («0902») no se contabilizan por separado. El catálogo solo recoge modelos que seguían operativos cuando empezamos el seguimiento en octubre de 2026, por lo que los trimestres anteriores no incluyen modelos retirados con anterioridad.
Países: Cada creador en OpenRouter se asigna al país de la sede central de su laboratorio mediante una tabla interna en nuestro código. Los proyectos comunitarios de fine-tuning, los modelos no identificados y los laboratorios cuya sede no se ha podido determinar con total certeza se agrupan en Otros / desconocido. Por el momento ningún laboratorio ruso (Yandex, Sber GigaChat, T-Bank) está presente en OpenRouter, por lo que Rusia no figura en los gráficos.
Pesos abiertos: Un modelo se clasifica como de pesos abiertos si OpenRouter asocia un repositorio de Hugging Face a su ficha (hugging_face_id), y como propietario en caso contrario. Esto acredita únicamente que los pesos de la red son públicos, no que su licencia sea libre: numerosos modelos de pesos abiertos imponen restricciones al uso comercial.
Cuota de tokens: OpenRouter publica recuentos diarios de tokens por modelo y semanales por laboratorio (los nueve principales y el resto agrupado) bajo licencia CC BY 4.0. Recopilamos estos datos cada 6 horas, archivamos una captura móvil de 7 días por modelo cada jornada y no contabilizamos la semana en curso hasta que no concluye de forma definitiva. Representa el volumen de tokens consumido dentro de OpenRouter, no en el conjunto del mercado global: no contempla el tráfico directo vía API, aplicaciones de chat ni contratos corporativos a medida, teniendo un peso superior los modelos económicos, gratuitos o destinados a flujos con agentes. La fuente son los datos internos que alimentan la página de rankings de OpenRouter, no una API documentada; si su formato cambia, los gráficos retienen la última información disponible.
Datos abiertos: Toda la información expuesta en la sección de gráficos está disponible en formato JSON en /api/v1/charts.

Noticias

Primero nuestros propios datos; después, la actualidad de los propios proveedores.

Nuestros eventos: Novedades de modelos, variaciones de precios, retiradas, incidencias y líderes de la arena se generan de forma automática a partir de los datos anteriores, sin intervención editorial.
Fuentes externas: Blogs oficiales de los proveedores vía RSS, lanzamientos en GitHub de las principales herramientas y debates sobre IA en Hacker News que superen los 150 puntos, revisados cada 15 minutos.
Edición: Un modelo lingüístico ligero redacta el titular y un resumen de una sola línea, asigna una relevancia del 1 al 5 y descarta duplicados. Su análisis se limita al título y al extracto del feed RSS, sin acceder al contenido completo del artículo, y cada entrada enlaza directamente a la fuente original.

Limitaciones

Lo que esta plataforma todavía no alcanza a cubrir.

Ubicación única: Las comprobaciones se ejecutan desde un único servidor situado en Finlandia. Una incidencia regional en otra parte del mundo podría pasar inadvertida, y una anomalía de red en nuestra infraestructura podría confundirse con un fallo del proveedor; de ahí que una sola señal nunca determine el estado si el resto discrepa.
No todas las API: Determinados proveedores carecen de página de estado en formato estructurado, y nuestras pruebas sintéticas requieren disponer de una clave de API por proveedor. En los casos en que no contamos con ninguna de las dos vías, el diagnóstico descansa exclusivamente en los datos de OpenRouter y en los reportes de la comunidad.
Datos abiertos: El estado en tiempo real de cada servicio está accesible en formato JSON en /api/v1/status, de forma gratuita y sin requerir clave de API.