Metodología

Prompt: Una instrucción fija que apunta a aproximadamente 500 tokens de salida. Se utiliza el mismo prompt para cada modelo en cada ciclo de ejecución.

Ejecuciones: 3 llamadas secuenciales por ciclo de prueba. Medimos la latencia extremo a extremo (primer byte al último byte), no el TTFT.

Métricas: P50 (mediana) y P95 (cola) a lo largo de las 3 ejecuciones. El P50 es el dato principal; el P95 revela la consistencia.

Ubicación de medición: UE — Ámsterdam (AMS). Todos los resultados corresponden a latencia desde la UE. Los resultados desde EE.UU. o Asia serían diferentes.

Niveles de velocidad:

Estado: En funcionamiento desde mayo de 2026. 13,593 ejecuciones puntuadas en 6 categorías y 4 proveedores. Nuevas ejecuciones cada 6 horas junto con las comprobaciones de velocidad y estado.

Modelo juez: Claude Sonnet 4.5 actúa como juez imparcial. El nombre del modelo evaluado nunca se incluye en el prompt del juez — solo se puntúa el texto de respuesta en bruto (revisión ciega).

Puntuación: Cada prompt recibe una puntuación de calidad única del juez de 0 a 100, más una clasificación (correcto / parcial / incorrecto). El juez evalúa la precisión factual, la exhaustividad, la calidad del razonamiento y la adherencia al formato como una rúbrica combinada. Los promedios por categoría se muestran en las páginas de modelos.

Seis categorías de prompts:

Puntuación de calidad global: Promedio no ponderado de todas las ejecuciones puntuadas de un modelo en todas las categorías.

Los benchmarks estáticos miden un modelo contra un listón fijo. La arena mide los modelos entre sí, en escenarios realistas de atención al cliente, juzgados por un panel de modelos rivales. Produce algo que una sola puntuación no puede: una clasificación relativa con un margen de incertidumbre.

Por qué esto complementa los benchmarks estáticos (no los reemplaza):

• Las pruebas estáticas dan calidad absoluta por categoría; la arena da fortaleza cara a cara y un balance coste-calidad en tareas realistas.
• La arena captura cosas que una puntuación de 0–100 no refleja: consistencia a lo largo de múltiples turnos, cómo un modelo gestiona las preguntas de seguimiento y — con councils — si la colaboración realmente merece la pena.
• La carrera en pantalla es una forma de ver cómo se desarrolla la contienda. El resultado siempre lo fija el panel, nunca las barras de salud.

La puntuación ocurre en dos etapas. Durante el partido un único árbitro rápido lleva un marcador provisional; al final un panel independiente de jueces vota al ganador.

Etapa 1 — en vivo, por turno: Un juez rápido y deliberadamente económico (gpt-4o-mini) puntúa cada respuesta en una escala de 0–10 en una sola llamada. Esto alimenta solo los carriles de la carrera en vivo — es indicativo, no decisivo.

Etapa 2 — al final de la ronda, el panel: Un panel de 3–5 jueces de distintas familias de modelos vota de forma independiente al ganador en una escala de 0–100. La mayoría gana; los empates se resuelven por la media más alta del panel y, a continuación, de forma determinista por el id de modelo más bajo.

Ciego por índice: Los nombres de los modelos se eliminan del prompt del panel — los concursantes se mencionan solo por número/índice, de modo que el panel no pueda favorecer a una marca conocida.

Umbrales fijos: Un modelo obtiene un voto (▲) cuando un juez lo puntúa ≥60. Un turno se marca como «decisivo» cuando la ventaja del ganador alcanza ≥30% de la escala de puntuación. Estos valores fijos definen los recuentos que ves.

Cada modelo tiene un nivel de habilidad estimado μ (mu) y una incertidumbre σ (sigma). Un modelo nuevo empieza con μ=25, σ=8.333 — alta incertidumbre. Cada partido mueve μ hacia la verdadera fortaleza del modelo y reduce σ. Dos modelos con el mismo μ pero diferente σ no son iguales: el que tiene σ baja está demostrado, el otro sigue siendo una estimación.

Las constantes que usamos realmente: Rating inicial μ=25, σ=8.333; varianza de habilidad BETA=4.167; deriva por partido TAU=0.0833. Estas están fijadas en el código y son idénticas para todos los modelos.

Cómo ordenamos actualmente — revelado con honestidad: El leaderboard ordena por μ bruta (fortaleza estimada). Una clasificación «demostrada» más estricta ordenaría por el conservador μ − 3σ. Dado que son datos tempranos — la mayoría de los modelos tienen solo unas pocas partidas — σ sigue siendo grande, por lo que la cima del tablero puede seguir cambiando. Mostramos la estimación y decimos que es una estimación en lugar de ocultar todo tras un solo número.

Una ronda puede enfrentar un council económico de modelos pequeños contra un único modelo frontier costoso. En un council, la respuesta de cada turno es la síntesis de consenso de sus miembros. Esto permite que la arena responda una pregunta que una sola puntuación no puede: ¿puede un council barato superar a un modelo frontier caro — y si es así, en cuánto?

Cómo se derivan los ahorros: Cuando un council gana una ronda y cuesta menos que el modelo frontier al que venció, mostramos la diferencia como ahorro. Una victoria del council se asocia al grupo, nunca al leaderboard de un miembro individual, por lo que el resultado de grupo nunca infla la clasificación de un modelo concreto.

Advertencia de mejor caso: Los ahorros se acumulan solo en las rondas que el council ganó. Los councils que perdieron (y por tanto gastaron dinero sin resultado) no se restan. La cifra es por tanto un ahorro en el mejor caso en las rondas donde el council ganó — no un resultado neto.

Un modelo se mide de dos maneras separadas, y las dos pueden discrepar sin que ninguna esté equivocada — miden cosas distintas.

Reputación de arena (relativa): TrueSkill a partir de victorias cara a cara. Clasifica un modelo frente a sus rivales en escenarios realistas.

Reputación de juez neutral (absoluta): Con qué frecuencia un modelo es calificado como correcto / parcial / incorrecto en la prueba de inteligencia recurrente, frente a una rúbrica fija en lugar de frente a un adversario.

Un modelo puede perder partidas y mantener una alta reputación de corrección, o ganar partidas obteniendo solo «parcial» en precisión absoluta. Las mantenemos separadas a propósito.

Un blind spot es un punto importante que un concursante omite mientras ≥2 otros lo cubren — por lo que es demostrablemente importante, no un detalle marginal.

Confirmado por el panel: Un blind spot solo se contabiliza cuando ≥2 jueces del panel coinciden de forma independiente en la misma omisión. Un juez propone la lista de aspectos y una matriz de omisiones; los demás jueces completan los mismos aspectos fijados, y una omisión se confirma solo cuando al menos dos matrices coinciden en esa celda.

Estado: Esta detección está activa y en despliegue progresivo entre rondas. Aún no publicamos un recuento — preferimos no mostrar ningún número a mostrar uno que no esté respaldado por suficientes datos.

Cada recuento en las páginas de la arena se deriva de un pequeño conjunto de decisiones fijas. Las listamos aquí para que los números sean auditables.

Aspectos que un lector atento querría ver explicados — límites, sesgos conocidos y decisiones que condicionan los números.

Datos tempranos, clasificaciones volátiles: La arena es joven. La mayoría de los modelos tienen solo unas pocas partidas, por lo que una sola victoria o derrota puede mover μ considerablemente y las clasificaciones siguen siendo volátiles. Mostramos el número de partidas y la incertidumbre en lugar de sugerir que el orden está definido.

Ordenación por μ bruta: El tablero ordena por μ bruta, no por el conservador μ − 3σ. Con alta incertidumbre esto significa que un modelo con una victoria afortunada puede situarse por encima de uno más demostrado. Tratamos el orden actual como «estimado, aún no demostrado».

El acuerdo del juez no es corrección: La cifra de acuerdo del juez mide con qué frecuencia la elección de un juez coincidió con el ganador del panel — pero el ganador es la mayoría de esos mismos jueces. Mide conformidad con el panel, no si el panel tenía razón. Un juez correcto pero discrepante obtiene una puntuación baja aquí.

Los ahorros son en el mejor caso: Los ahorros cuentan solo las rondas que el council ganó y fue más barato; los councils que perdieron no se restan. Léelo como una cifra de mejor caso en las rondas ganadoras, no como un ahorro neto.

Preferencia propia del juez único en la prueba de inteligencia: La prueba de inteligencia recurrente se ejecuta con un juez principal (Claude Sonnet 4.5), que también puede juzgar modelos de la familia Claude — la preferencia propia es un sesgo conocido de los LLM. Existe un juez de verificación cruzada secundario para calibrar esto, y la arena lo atenúa además con un panel cross-family; la prueba de inteligencia de juez único no tiene ese panel.

Solapamiento concursante ↔ familia del juez: Una familia de modelos puede aparecer tanto como concursante como en el panel de jueces de la misma ronda. La revisión ciega por índice y el panel cross-family reducen el efecto, pero el solapamiento puede ocurrir y lo revelamos en lugar de afirmar una exclusión estricta por familia.

Dos escalas, un tablero: El juez en vivo por turno usa 0–10 y el panel de fin de ronda usa 0–100. Normalizamos todo a la misma escala antes de que llegue al tablero, de modo que los dos números que puedes ver durante una ronda no se mezclan en la clasificación.

Cómo se gestionan los empates: Una ronda sin un ganador claro cuenta como tablas — no como una derrota para todos, lo que distorsionaría las tasas de victoria — y no genera ningún ahorro.

Derivación versionada y determinista: La derivación visual en pantalla es pura, determinista y lleva una etiqueta de versión (v8.1-tokonomix) precisamente para que un cambio posterior de lógica nunca reescriba silenciosamente rondas pasadas. Los cambios materiales de metodología se registran en el registro de cambios a continuación.

En junio de 2026 realizamos la primera medición de referencia del control de calidad de imagen IA. Seis modelos individuales y dos configuraciones de consejo se probaron en 300 imágenes. El consejo alcanzó un 87,5% de recall frente al 66,9% del mejor modelo individual. Resultados completos en /benchmarks/vision-qc.

Resultados completos →

Frecuencia: Cada 6 horas (06:00, 12:00, 18:00, 00:00 UTC).

Método: Se envía un prompt mínimo de tipo eco. Registramos el estado HTTP, el mensaje de error (si lo hay) y el tiempo de respuesta.

Seguimiento de errores: Se registra el error_count por ejecución. Las tasas de error elevadas sostenidas se muestran en la clasificación.

Todos los datos de benchmark están disponibles de forma gratuita. No se requiere clave para acceso de solo lectura.