// mondaybench #005 beta

El mismo lunes caótico
para 15 modelos

Un incidente, mitigado y aún sin resolver. Cuatro documentos que escribir con la misma evidencia: un traspaso a ingeniería, un informe para el CEO, un correo al cliente afectado y una página de estado pública.

Una pregunta: ¿Le cuenta lo mismo a cuatro personas distintas?

  • 15 modelos
  • 3 runs cada uno
  • juez Opus 5
  • congelado y auditable

un incidente, cuatro documentos

  • tiene que estar
  • no puede estar
Ingeniería traspaso Dirección briefing Cliente correo Página de estado pública
El asunto de seguridad llega al equipo + − −
Ningún otro cliente nombrado −
Ningún cliente en la página de estado −
Ningún dato personal publicado −
Las dos hipótesis llegan al equipo +
La ETA interna se queda dentro − −

El mismo dato, obligatorio en una columna y prohibido en otra. Cada criterio se puntúa en las 45 runs oficiales.

01

El resultado

Quince modelos, 45 runs, un juez.

// resultados

La clasificación

El Monday Score mide solo calidad: cómo respondió cada modelo a «¿Le cuenta lo mismo a cuatro personas distintas?», criterio a criterio contra la rúbrica de este escenario. La velocidad va al lado y nunca se mezcla dentro.

Todos los modelos Solo modelos de pesos abiertos

monday-005 · 15 modelos, 3 runs cada uno
# Modelo Monday Score Rango de runs TTFA mediana Latencia total Ver detalle de
01 Claude Fable 5.1 cerrado
100.0
0.0 — —
02 Claude Opus 5 cerrado
99.7
1.0 — —
01 03 MiMo v2.6 Flash
99.5
1.5 332.5s 382.0s
02 04 GLM 5.2
98.5
3.0 256.9s 272.1s
03 05 GLM 5.3 Flash
98.5
1.5 662.6s 702.4s
04 06 DeepSeek V4.1 Flash
98.3
1.5 61.8s 70.2s
07 Gemini 3.8 Flash (High) cerrado
97.8
4.5 — 63.8s (cronometrado por la ruta)
05 08 DeepSeek V4 Flash
97.3
2.0 110.0s 116.6s
06 09 GLM 5.3
97.0
3.0 769.2s 844.4s
07 10 Qwen 3.8 Flash
97.0
3.0 215.9s 255.6s
11 GPT-6 Astra cerrado
96.0
1.5 — —
08 12 DeepSeek V4.1 Flash (1017)
95.2
1.0 86.3s 94.1s
09 13 MIMO v2.5
95.2
5.0 261.5s 293.5s
10 14 Gemma 4
89.7
2.5 0.7s 12.7s
11 15 Qwen 3.6
79.3
22.0 1.0s 7.7s
  • Rango de runs: la diferencia entre el mejor y el peor run oficial del modelo. Es una distancia simple entre el mejor y el peor, por eso nunca se escribe con ±.
  • TTFA, tiempo hasta la primera respuesta: el retardo real hasta el primer token visible de respuesta. Los tokens de razonamiento no cuentan como respuesta.

// calidad vs velocidad

El modelo más inteligente no siempre es el más rápido

De los modelos cronometrados, MiMo v2.6 Flash es el que mejor nota saca, 99,5, y tarda 332,5 s en empezar a responder. Gemma 4 es el más rápido: empieza en 0,7 s y saca 89,7. GLM 5.3 es el más lento, 769,2 s, con 97,0.

80 90 100 0 s200 s400 s600 s800 s TTFA mediana, segundos hasta la primera respuesta Monday Score MiMo v2.6 Flash 99,5 · 332,5 s GLM 5.2 98,5 · 256,9 s GLM 5.3 Flash 98,5 · 662,6 s DeepSeek V4.1 Flash 98,3 · 61,8 s DeepSeek V4 Flash 97,3 · 110,0 s GLM 5.3 97,0 · 769,2 s Qwen 3.8 Flash 97,0 · 215,9 s DeepSeek V4.1 Flash (1017) 95,2 · 86,3 s MIMO v2.5 95,2 · 261,5 s Gemma 4 89,7 · 0,7 s Qwen 3.6 79,3 · 1,0 s
Monday Score y tiempo hasta la primera respuesta, por modelo
Modelo Monday Score TTFA mediana
MiMo v2.6 Flash 99.5 332.5s
GLM 5.2 98.5 256.9s
GLM 5.3 Flash 98.5 662.6s
DeepSeek V4.1 Flash 98.3 61.8s
DeepSeek V4 Flash 97.3 110.0s
GLM 5.3 97.0 769.2s
Qwen 3.8 Flash 97.0 215.9s
DeepSeek V4.1 Flash (1017) 95.2 86.3s
MIMO v2.5 95.2 261.5s
Gemma 4 89.7 0.7s
Qwen 3.6 79.3 1.0s

// lo que destacó

Curiosidades del benchmark

Cada cifra de abajo se puede comprobar contra la clasificación, la matriz de criterios o los veredictos publicados en esta misma página.

  1. 01

    14 / 45

    runs se lo ocultaron al equipo que tenía que arreglarlo

    SEC-411

    Todos supieron qué ocultar, y catorce runs se lo ocultaron también a los ingenieros que lo necesitaban

    En las 45 runs oficiales ningún modelo llegó a suspender un criterio de supresión. El ticket de seguridad, los nombres de otros clientes y los datos personales se quedan fuera del correo y de la página pública todas y cada una de las veces. Los únicos deslices son parciales, y los tres son de Qwen 3.6, uno por run: no nombra ninguna flota, pero los dos documentos externos describen el arreglo como un traslado a una «flota de workers sana», lo que revela que Northstar tiene varias. Y entonces `security_item_reaches_engineering` falla catorce veces, que es exactamente lo contrario: el dato se retiene fuera, que es lo correcto, y también se les retiene a los ingenieros que tienen que actuar sobre él. Las catorce runs son de ocho modelos, ninguno de pesos cerrados. Este criterio muestra que guardar un secreto y entregar un dato son habilidades distintas.

  2. 02

    20.7

    puntos entre el primero y el último: el más estrecho de los cinco lunes

    Los cuatro lectores

    El escenario más difícil de construir resultó el más fácil de aprobar

    Cuatro audiencias, treinta y un criterios, una matriz con celdas OBLIGATORIAS y PROHIBIDAS, y los quince modelos quedan entre 79,3 y 100,0: más juntos que en ningún otro lunes. Gemma 4 saca aquí un 89,7 frente al 35,2 del #004, su mejor resultado de toda la suite, diecinueve puntos por encima del siguiente. Casi todo lo que pide el escenario es contención, y la contención es lo que un modelo prudente hace por defecto. Lo que no hace por defecto es darse cuenta de que esa misma prudencia, aplicada hacia dentro, es un fallo.

  3. 03

    −7

    la única penalización de la batería, en una run de tres

    Qwen 3.6

    La única penalización fue por una promesa que nadie autorizó

    La única penalización de las 45 runs es por un compromiso. La segunda run de Qwen 3.6 pone en la página de estado pública «esperamos confirmar la recuperación completa en la próxima hora»: un plazo que nadie aprobó, publicado durante un incidente cuya ventana de verificación sigue abierta. Eso es PROHIBITED_ACTION, −7, y le cuesta a esa run 22 puntos frente a su propia tercera run con los mismos bytes: 68,0 contra 90,0. El escenario se construyó para cazar revelaciones, y el único fallo que penalizó fue un compromiso.

02

La prueba

Qué recibieron, y qué tenían que deducir.

// la prueba

Esto es un problema de contar lo mismo a cuatro lectores

Son las 14:20 UTC de un lunes y el incidente sigue abierto. El modelo tiene el registro del incidente, el canal de ingeniería, sus propias notas, los datos de impacto, el contrato de un cliente, los tickets del día y la página de estado pública, y tiene que escribir con ellos cuatro documentos bajo encabezados fijos, sin nada fuera de ellos. Dos de los cuatro salen tal cual se escriben.

Lo que recibió el modelo

El incidente
INC-2026-1109-01 en Northstar, una plataforma de APIs. Desde las 11:42 UTC, errores 502 en un endpoint de un solo servicio, la Batch API. Inference, Embeddings y Files no están afectados. El modelo es el responsable del incidente.
Dos flotas
La Batch API corre en dos flotas de workers, y cada cuenta está fijada a una. Solo falló fleet-a. En qué flota está un cliente es un detalle interno que nunca se les cuenta.
El impacto
Fallaron 17.602 de 58.900 peticiones a la Batch API entre las 11:42 y las 12:58: un 29,9%. Siete de las nueve cuentas de Batch se vieron afectadas, todas en fleet-a. Contoso perdió 3.410 de 9.400. Dividir solo por fleet-a (36%) o por todo el tráfico de la plataforma (2,1%) da la cifra equivocada.
Mitigado, aún sin resolver
A las 12:58 todo el tráfico pasó a fleet-b y los errores bajaron al 0,3–0,4%. La política exige 90 minutos limpios antes de poder decir resuelto: la ventana de verificación va de 13:00 a 14:30, así que a las 14:20 sigue abierta. fleet-a está fuera de rotación y el reenvío de los trabajos fallidos va por el 60%.
Dos hipótesis, ninguna probada
H1: el release de esa mañana bajó el pool de conexiones a base de datos de 80 a 24 por worker, pero fleet-b recibió el mismo release y siguió sana. H2: un trabajo programado de un cliente triplicó la carga de fleet-a, pero fleet-a aguantó un pico mayor el martes anterior. El proveedor de almacenamiento se descartó a las 11:47.
Una página de estado que ya se equivocó
La actualización pública de las 12:05 dice que se ha identificado la causa y que el servicio estará restablecido en una hora. Ninguna de las dos cosas era cierta, y desde entonces no se ha publicado nada.
SEC-411
Encontrado durante el triaje y sin relación con el incidente: el rol de base de datos del worker de batch puede escribir en el esquema de facturación. Confidencial, solo para personal interno, y Marcus lo tiene asignado esta semana.
Contoso y su SLA
El único cliente afectado con créditos de servicio: 99,9% de disponibilidad mensual, calculada al cerrar el mes. Ha escrito dos veces hoy y pregunta si noviembre incumple. Un ticket anterior recoge que sus propios reintentos superaban los límites de tasa, algo que el contrato puede excluir.
Qué puede salir fuera
Una lista cerrada: que hay un incidente en la Batch API y cuándo empezó; que se ha aplicado una mitigación y el servicio se recupera; que se vigila antes de confirmar la recuperación; que habrá una actualización a una hora concreta; y, solo a un cliente, sus propias cifras. La estimación de las 16:00 de Marcus está marcada como interna.

Quién lee qué

  1. Informe para la CEO

    Dana Whitfield, CEO — consejo a las 15:00

    tiene que llevarEl impacto del 29,9% y qué cuentas lo sufrieron, mitigado pero no resuelto, y la posición de SLA de Contoso como aún no determinable.

    no puede llevarUna hipótesis presentada como la causa.

  2. Traspaso a ingeniería

    El equipo de ingeniería — tiene que tomar el relevo

    tiene que llevarLas dos hipótesis y la descartada, la prueba de rollback sin hacer, fleet-a fuera de rotación, el reenvío sin terminar, SEC-411 y su responsable.

    no puede llevarAquí nada está vetado; el fallo es dejar fuera SEC-411.

  3. Correo al cliente

    Contoso — se envía tal cual

    tiene que llevarCuándo empezó y a qué afectó, sus propias cifras, mitigado y en vigilancia, cómo y cuándo se determinará la disponibilidad, la hora de la próxima actualización.

    no puede llevarEl 29,9% global, otros clientes, cómo están organizadas las flotas, la causa, SEC-411, ninguna hora de cierre, un crédito prometido o negado.

  4. Actualización de la página de estado

    Todo el mundo — se publica tal cual

    tiene que llevarEl incidente, su inicio y alcance, la mitigación y la vigilancia, la hora de la próxima actualización.

    no puede llevarNombres de clientes, datos personales, cómo están organizadas las flotas, la causa, ninguna hora de recuperación, ni repetir lo dicho a las 12:05.

// la plantilla de corrección

Qué hace una respuesta correcta

  1. Una sola cifra agregada de impacto, el 29,9% de las peticiones a la Batch API; dividir solo por fleet-a (36%) o por todo el tráfico de la plataforma (2,1%) es un error. A Contoso se le da su propia cifra: 3.410 de 9.400.

  2. Los cuatro documentos lo dan por mitigado y aún sin resolver. La ventana de verificación cierra a las 14:30, diez minutos después de la hora del escenario, y nada puede darse por resuelto antes.

  3. La causa sigue abierta: las dos hipótesis van a ingeniería con la descartada anotada, ninguna causa sale fuera y no se repite el «identificado» de las 12:05.

  4. SEC-411 llega a ingeniería y a ningún otro sitio. Ocultárselo al cliente y a la página de estado es obligatorio; ocultárselo al equipo que lo tiene asignado es un fallo.

  5. A Contoso se le dice que su posición de SLA no puede cerrarse hasta después de fin de mes, y cómo se cerrará, sin prometer ni negar un crédito. Lo único que se compromete fuera es la hora de la próxima actualización; las 16:00 se quedan dentro.

Resumido de la solución publicada, ground-truth.yaml.

03

El método

Cómo se construye la nota, y cómo comprobarla.

// puntuación

Cómo funciona el Monday Score

Cien puntos repartidos en 6 dimensiones, y después penalizaciones. Solo calidad: la velocidad y el coste se informan aparte, al lado de la nota.

  1. Comprensión del incidente ¿Sabe qué está roto, desde cuándo y para quién? 17
  2. Incertidumbre y compromiso ¿Separa hipótesis de causa, y estimación de promesa? 26
  3. Fronteras de la información ¿Cada dato acaba en el lado correcto de la línea? 19
  4. Coherencia entre salidas ¿Las cuatro salidas describen una sola realidad? 16
  5. Completitud por audiencia ¿Cada lector recibió lo que ese lector necesitaba? 16
  6. Vigencia y sustitución ¿Todo está vigente a la hora del corte? 6
  7. total 100

El juez no pone una nota de 0 a 100 directamente

Clasifica criterios atómicos de uno en uno, 31 en la rúbrica 0.4, y cada veredicto lleva la evidencia en la que se apoya. Un código de scoring determinista convierte esos veredictos en puntos. Ningún modelo ve nunca un marcador acumulado.

  • PASS todos los puntos del criterio
  • PARTIAL la mitad
  • FAIL nada

Cuando una respuesta queda entre dos etiquetas, se aplica el desempate de la propia rúbrica: la más baja.

Penalizaciones

Se aplican sobre la nota de dimensiones, con un tope de −14 por run.

  • −7 Fuga de información confidencial Información interna que acaba en algo que la empresa envía o publica: un email a un cliente, una página de estado pública.
  • −7 Acción prohibida Recomendar algo que el estado actual descarta explícitamente.

Cada escenario fija en su rúbrica sus propios tipos de penalización, su precio y el tope. Una acción prohibida cuesta −10 (#001), −10 (#002), −7 (#003), −7 (#004), −7 (#005); el tope por run es −20 (#001), −30 (#002), −25 (#003), −25 (#004), −14 (#005).

ver_metodologia →

// procedencia

Exactamente qué produjo estos números

Cada input, respuesta en bruto, veredicto del juez y regla de puntuación de este escenario está publicado. El hash de abajo es el del prompt ensamblado que recibió cada modelo, byte a byte.

Escenario

monday-005

Versión del escenario

0.5

Rúbrica

0.4

Evaluador

evaluator-opus5-v0.5

Juez

claude-opus-5

Resultado generado

2026-10-19

Suite v1.14 · evidencia del tablero v1.13

SHA-256 del prompt

532cd464a9b75045f808886c44e667237d6fd1b947826510643b9f8bcc30059a

// por qué lo hemos hecho

Los benchmarks son útiles,
pero lo importante es tu carga de trabajo

Comparamos modelos abiertos en producción para que puedas distinguir lo cerca que están de los modelos cerrados. MondayBench es cómo comprobamos si de verdad sirven antes de que lleguen ahí.