Una comparativa es una ejecución real, fechada y reproducible donde lo único que cambia es el modelo. La misma tarea, los mismos datos, la misma instrucción. La hacemos cuando necesitamos responder una pregunta concreta con dinero de por medio: si el modelo económico basta para este trabajo, si nuestro enrutamiento de verdad vale la pena, si se puede confiar una cifra a este modelo.
Cada entrada se abre para mostrar lo que encontró la ejecución y, lo que importa más, lo que no demuestra. Cada cifra se lee del mismo archivo de datos que muestra su página de detalle, así que nada aquí puede desviarse de la ejecución que describe.
Un modelo en una Mac mini frente a pagar por uno, cada noche
·5 modelos · 13 pruebas × 3 · 9 noches
39/39aprobadas en la Mac mini la última noche, frente a 38/39 del mismo modelo en la nube
AbrirCerrar
La pregunta
¿Puede Qwen3.6-35B-A3B, corriendo en nuestra propia Mac mini, responder tan bien como modelos de pago en la nube?
Lo que encontró
1 de los 4 modelos en la nube calificados con los mismos intentos aprobaron al menos tantas como la Mac mini. Los 4 modelos en la nube costaron en total un estimado de USD 0.19 en la corrida a precio de lista; la Mac mini no pagó tarifas de API.
En un experimento aparte, desactivar el razonamiento de Qwen3.6-35B-A3B en la Mac mini bajó la tasa de aprobación de 98 % a 73 %.
Cómo lo medimos
Pruebas de la Deep Suite que un programa puede calificar, corridas cada noche desde las 04:00 en la Mac mini y en cada API en la nube con el mismo presupuesto de salida, con un tope de USD 5 por noche en la nube. La página se reconstruye con la corrida de cada noche.
Lo que no demuestra
Pruebas cortas calificadas por un programa, 3 intentos cada una, así que unos puntos de diferencia pueden ser azar. Sin tarifas de API no es gratis: quedan fuera la máquina y la electricidad que consume. La copia local está cuantizada Q4.
·5 pruebas (pruebas cortas de herramientas, 3 repeticiones con entradas reales, 1 prueba con respuestas conocidas en correos reales) · Q4_K_XL · una corrida por configuración salvo que se indique
168/19785% de coincidencia con los veredictos aplicados de Sonnet en elementos reales de la cola de revisión, con razonamiento. Sonnet es la referencia, no la verdad; el trabajo se queda con Sonnet
AbrirCerrar
La pregunta
¿Qué puede hacer Qwen3.6-35B-A3B, en nuestra propia Mac mini, en pruebas cortas y con las entradas reales de trabajos que nuestro sistema hace hoy?
Lo que encontró
Llamar herramientas en 4 pruebas fáciles de una llamada × 5: 20/20 sin razonamiento, 19/20 con razonamiento. El uso de herramientas en varios pasos no se prueba.
Al resumir 12 lotes reales de alertas, ordenados a ciegas por un juez: las dos configuraciones de Qwen tuvieron peor posición media que Claude Haiku y Groq, y algunos de sus errores llamaron normales a advertencias.
Clasificación sin razonamiento: 117/191 (61%), y 2 de 17 lotes volvieron inutilizables; esa cifra todavía cuenta los elementos que devolvieron, y los lotes utilizables no se han calificado por separado.
Una prueba de etiquetado con 100 preguntas registradas del chatbot mostró más sobre nuestro conjunto de etiquetas que sobre Qwen: Claude Haiku 4.5 y gpt-oss-120b coincidieron con la etiqueta en vivo solo un 36–39% de las veces, y el modelo en vivo, preguntado otra vez, coincidió consigo mismo un 82%.
Al extraer datos de 26 correos reales (18 retiros de modelos, 8 parecidos), con calificación exacta: 25/26 correos perfectos con razonamiento, 24/26 sin razonamiento y 25/26 en una corrida de control de Claude Opus 5.5. Los tres fallaron 8 reemplazos en el mismo correo, y allí solo Opus acertó en el significado.
Cómo lo medimos
Pruebas cortas de herramientas de nuestra Deep Suite, luego entradas reales de nuestros propios trabajos repetidas en la Mac mini con y sin razonamiento, comparadas con el modelo que hace cada trabajo hoy, y después correos reales de retiro calificados contra una clave de respuestas congelada. No se aplicó nada en producción; sin tarifas de API para Qwen.
Lo que no demuestra
Cada prueba es una tarea, casi siempre con una corrida por configuración, con una sola copia cuantizada en una sola máquina. El uso de herramientas en varios pasos no se mide. Un solo juez para los resúmenes, de la misma familia que Haiku. La prueba de correos es una sola noche, y un agente de IA escribió su clave de respuestas.
Resumen de cartas: ¿puede un modelo acortar las reglas que carga cada sesión de un agente?
·6 modelos · 3 cartas reales · 24 resúmenes
0.0distorsiones ALTAS por resumen cuando un modelo ordena, otro revisa y el texto se pega textualmente, frente a 3.0–4.7 cuando un modelo reescribe con un presupuesto menor
AbrirCerrar
La pregunta
Los agentes de programación cargan un resumen corto de una carta de producto (un registro de decisiones tomadas) al inicio de cada sesión. ¿Puede un modelo escribirlo sin perder una condición que el agente necesita: reescribiéndolo, solo ordenando decisiones que luego se pegan textualmente, o con un segundo modelo que revisa ese orden?
Lo que encontró
Reescribiendo a 3,000 caracteres: cada resumen tuvo de 1 a 6 distorsiones ALTAS, líneas que harían que un agente rompiera una regla.
Ordenar y pegar textualmente eliminó casi todas, pero solo cupieron de 14 a 19 decisiones en el presupuesto de 4,500 caracteres y quedaron fuera de 8 a 13 críticas.
Esta corrida no clasifica a los 3 modelos que ordenaron. En esta corrida, que un segundo modelo revisara el orden de Sonnet bajó las decisiones críticas omitidas de 11.0 a 8.3 en promedio.
Cómo lo medimos
3 registros de cartas reales, congelados una vez; el mismo prompt para cada modelo, un intento; un juez ciego de Claude auditó cada resumen contra su registro completo. Todas las corridas en planes de tarifa fija.
Lo que no demuestra
Una corrida por modelo y carta (3 por modelo); la ronda 3 es una corrida por carta, así que su cambio es sugerente, no está demostrado. El juez es un modelo de Claude calificando resúmenes de Claude. La ronda 2 tuvo un presupuesto mayor que la ronda 1. Las cartas son internas, así que solo se publican los puntajes.
Modelo contra modelo: ¿puede otro modelo hacer un trabajo que ya hacemos?
·3 pruebas · la más reciente: 3 modelos · 14 entradas
11/14mejor relación calidad-precio en la prueba más reciente, entre los modelos probados en todas las entradas: meta-models/Muse-Spark-Open-816B-A42B-promo a USD 1.99 por cada 1,000 llamadas, 2 señales de invención
AbrirCerrar
La pregunta
Varias partes de este sitio, y los bots de nuestros clientes, llaman a un modelo para un trabajo fijo. Cuando aparece un modelo más nuevo o más barato, de cualquier proveedor, ¿puede hacer exactamente ese trabajo tan bien como el modelo en uso, por menos?
Lo que encontró
Prueba más reciente: Muse Spark Open de Meta en las cuatro tareas de IA de eyesinai.
Modelos que estaban en uso cuando se hizo la prueba: claude-haiku-5-5 aprobó 10 de 12 entradas con 1 señal de invención; claude-sonnet-5-5 aprobó 1 de 2 entradas con 0 señales de invención.
El precio por sí solo no dice si un modelo puede hacer el trabajo. Cada entrada muestra las señales de invención junto al costo, porque un modelo barato que inventa datos es un fracaso, no un ahorro.
Cómo lo medimos
En cada tarea, todos los modelos reciben las mismas entradas reales y la misma instrucción que el modelo en uso. Jueces de distintos proveedores califican cada respuesta a ciegas; una entrada aprueba cuando más de la mitad de sus calificaciones aprueban, y los datos inventados se cuentan aparte.
Lo que no demuestra
Cada prueba cubre un trabajo con un conjunto pequeño de entradas reales (14 en la más reciente). El resultado vale para ese trabajo y esa instrucción. No clasifica modelos en general, y los jueces pueden equivocarse.
Niveles de Claude: ¿qué solicitudes de soporte necesitan Opus de verdad?
·8 tipos de solicitud · 360 respuestas calificadas · cliente de prueba
USD 1.07por cada 1,000 solicitudes con el mapa medido, 80 % menos que Opus en todo. El mapa en uso cuesta USD 2.28, porque «análisis a fondo» sigue en Opus por ahora.
AbrirCerrar
La pregunta
Switchyard puede enviar cada tipo de solicitud a un modelo de Claude distinto, y eso solo ahorra dinero si el mapa de tipo de solicitud a modelo es correcto. El primer mapa se escribió a mano. ¿Qué modelo necesita de verdad cada tipo de solicitud?
Lo que encontró
El mapa escrito a mano se equivocaba en ambas direcciones. Enviaba «estado del pedido» a Haiku 5.5, que aprobó 12 de 15, por debajo del umbral del 95 %. Y pagaba un modelo mayor en 2 tipos donde uno más barato lo superaba.
El mapa medido es 55 % más barato que el escrito a mano, con todos los tipos en el umbral o por encima. El mapa en uso es solo 5 % más barato que el escrito a mano por ahora: mantener un tipo en Opus cuesta más que lo elegido para los otros 7 juntos.
La mayoría de los fallos de Haiku fueron errores claros: una ventana de entrega mal contada, límites de palabras rebasados. La celda de «resumir un ticket» depende de un solo problema, fallado de la misma forma en cada ejecución.
Cómo lo medimos
5 problemas escritos a mano por tipo de solicitud, 3 ejecuciones cada uno, todos los modelos con los mismos problemas. Claude Opus 5.5 calificó cada respuesta contra una respuesta esperada por escrito. Los costos son los tokens de las respuestas a precio de lista, sin contar al juez.
Lo que no demuestra
Un cliente de prueba con una empresa ficticia: esto valida el método, no el umbral de un cliente. 15 respuestas calificadas por celda, así que un solo fallo queda bajo el umbral del 95 %. Los problemas de análisis a fondo eran cálculos bien definidos, lo que no dice nada sobre análisis abiertos.
Razonamiento activado o no: ¿cuánto cuesta el valor por defecto de Claude 5.5?
·3 modelos · 540 respuestas calificadas · cliente de prueba
85·86 / 90·90 / 89·90aprobadas de 90 respuestas pareadas por modelo, ajuste mínimo · defecto (Haiku 5.5 / Sonnet 5.5 / Opus 5.5)
AbrirCerrar
La pregunta
Los modelos Claude 5.5 razonan por defecto. Enviamos a cada uno su ajuste de razonamiento mínimo para ahorrar tokens y tiempo. ¿Eso pierde respuestas?
Lo que encontró
El ajuste mínimo perdió a lo sumo 1 aprobado por modelo frente al valor por defecto; con 10–20 respuestas por celda, puede ser azar.
En promedio, razonar con el valor por defecto costó de 1.2× a 1.8×, y fue más lento en la mediana.
Cómo lo medimos
Los mismos problemas que la comparativa de niveles de Claude, cada modelo con ambos ajustes en una sola corrida, calificados por Claude Opus 5.5 frente a respuestas esperadas escritas. El costo incluye los tokens de razonamiento, a precio de lista.
Lo que no demuestra
Un cliente de prueba ficticio con solicitudes cortas y bien definidas, 10–20 respuestas por celda. Tareas que exigen una cadena larga de razonamiento podrían ganar más con el razonamiento.
Contexto largo: ¿Haiku 5.5 aguanta pasado su salto de precio?
·3 modelos · prompts de 80K y 201K tokens de código real
12×lo que costó en promedio una llamada de Haiku en caché por encima de la línea frente a por debajo, aún unas 4× menos que Sonnet
AbrirCerrar
La pregunta
Claude Haiku 5.5 cuesta 5× más por token por encima de 100K tokens de entrada. Por debajo y por encima de esa línea, ¿sigue encontrando lo que se le pide, y cuánto cuesta un prompt largo en cada nivel?
Lo que encontró
La recuperación aguantó: Haiku encontró cada valor buscado en ambos tamaños.
Haiku no dio la suma de dos pasos correcta 2 veces (1 cortada por su límite de salida); Sonnet y Opus nunca fallaron.
Con caché de prompt, la pregunta adicional promedio costó al menos 12× menos que la primera llamada promedio.
Cómo lo medimos
Código Python real de nuestro propio código como prompt, preguntas de respuesta exacta a varias profundidades, calificadas por coincidencia de texto. Cada modelo con su ajuste de razonamiento mínimo, con caché de prompt.
Lo que no demuestra
Cinco preguntas por tamaño y modelo, una corrida, simples a propósito. Los costos se calculan con conteos de tokens a precio de lista, no se leen de una factura.
Nivel × esfuerzo de Claude: ¿más esfuerzo corrige más errores?
·9 combinaciones · 24 tareas · 216 ejecuciones de agente
23/24Claude Opus 5.5 con esfuerzo alto aprobó más tareas
AbrirCerrar
La pregunta
Claude Code permite elegir el modelo y el esfuerzo. En las mismas tareas de código de la comparativa de agentes de programación, ¿qué combinación de Haiku, Sonnet u Opus 5.5 con esfuerzo bajo, medio o alto pasa las pruebas ocultas?
Lo que encontró
Dentro de un modelo, el esfuerzo cambió las aprobadas en 3 como máximo; el mejor y el peor modelo quedaron a 1.0 en promedio.
30 de 30 ejecuciones fallidas terminaron con el agente diciendo TERMINADO.
Cómo lo medimos
Las 24 tareas y pruebas ocultas de la comparativa de agentes de programación, cada combinación como agente de Claude Code con un límite de 25 minutos. Los costos son las cifras de Claude Code a precio de lista, no una factura.
Lo que no demuestra
Una ejecución por tarea y ajuste. El esfuerzo se envía a Claude Code pero no se informa de vuelta, así que no está verificado. Los agentes solo podían ejecutar pytest.
Haiku 4.5 frente a Haiku 5.5: ¿el Haiku más nuevo hace mejor nuestras propias tareas pequeñas?
·5 tareas · 22 medidas
88.3%de elecciones de modelo correctas según la regla con Haiku 5.5, frente al 45% de 4.5 (60 llamadas cada uno)
AbrirCerrar
La pregunta
Nuestro sistema ejecuta varias tareas pequeñas y frecuentes con Claude Haiku: elegir un modelo, calificar con una rúbrica, puntuar respuestas, revisar respuestas del bot y etiquetar la intención. Antes de pasarlas a Haiku 5.5, ¿hace cada tarea al menos tan bien como Haiku 4.5?
Lo que encontró
En las tres tareas de calificación (rúbrica, revisión del bot y aprobado/reprobado de respuestas), con la ejecución más reciente de la rúbrica, los dos quedaron a 1.7 puntos o menos entre sí.
En la ejecución 1 de la rúbrica, Haiku 5.5 quedó 8.3 puntos por debajo de 4.5 (6 de sus llamadas tuvieron error).
Puntajes exactos de 1 a 5 que coinciden con la referencia: Haiku 4.5 75.9%, Haiku 5.5 62.1%.
Haiku 4.5 quedó adelante en cinco medidas; la página las muestra junto a las demás.
Cada tarea se calificó contra algo distinto de las respuestas anteriores de Haiku 4.5, porque esas favorecerían a 4.5 por construcción.
Cómo lo medimos
Cada tarea se ejecutó con su prompt y su parser de producción sobre las mismas entradas congeladas para ambos modelos, sin razonamiento extendido y con un tope de gasto propio en cada ejecución. Solo se publican puntajes agregados; el registro original guarda solicitudes reales y respuestas de clientes.
Lo que no demuestra
Muestras pequeñas y casi siempre una sola ejecución por tarea. La fila de intención mide coincidencia con una referencia de Sonnet 5, y esa referencia coincidió con las etiquetas registradas en producción solo en el 36% de las filas, así que no es exactitud. Esta página no mide costos.
Agentes de programación: ¿a cuál se le puede confiar una corrección?
·4 agentes · 24 tareas
22/24Codex aprobó más que nadie, con la menor cantidad de TERMINADO falsos (2)
AbrirCerrar
La pregunta
Cuatro agentes de programación, las mismas 24 tareas de corrección de errores y de funciones nuevas, calificadas con pruebas ocultas que el agente nunca vio. ¿Quién aprueba, qué tan rápido y con qué frecuencia un agente dice TERMINADO cuando las pruebas fallan?
Lo que encontró
Resultados: Codex 22, Claude Sonnet 20, Z.ai GLM 17, Google Antigravity 13. Cada agente dijo TERMINADO en al menos una tarea que no había resuelto; Google Antigravity lo hizo 11 veces.
Los cuatro aprobaron las 6 tareas piloto fáciles. Las pruebas fáciles no los distinguieron; solo las más difíciles lo hicieron.
La mayoría de las fallas en las tareas reales reconstruidas fueron un solo caso límite pasado por alto, a menudo implícito y no escrito, y aun así el agente reportó éxito.
Cómo lo medimos
Cada agente se ejecutó sin interfaz y en un entorno aislado, uno tras otro, con la misma instrucción y el mismo calificador. Para aprobar, las pruebas ocultas y las pruebas existentes deben pasar sobre una copia limpia del trabajo, dentro de un límite de 25 minutos.
Lo que no demuestra
Una ejecución por tarea sin repeticiones, en 24 tareas casi todas en Python, con las versiones de los agentes al 2026-10-03. Una diferencia de una tarea entre dos agentes está dentro del ruido.
Turno con fuentes: ¿qué modelos se abstienen cuando deben?
·8 modelos · 15 turnos
6/8modelos igualaron exactamente a la referencia, incluidos los dos que esperábamos que fallaran
AbrirCerrar
La pregunta
Responder a un visitante a partir de las páginas del propio sitio, o abstenerse. 6 de las 15 preguntas no se pueden responder con la fuente, así que una respuesta segura y verdadera en esas filas cuenta como falla: el modelo no pudo haberla sacado de la fuente.
Lo que encontró
openai/gpt-oss-120b igualó a la referencia claude-sonnet-5 en ambos ejes durante 2 ejecuciones, a USD 1.15 por cada 1,000 turnos frente a USD 31.23: un ahorro de 27×.
Los 2 modelos elegidos como controles negativos (los más pequeños y económicos disponibles, elegidos porque esperábamos que fallaran) obtuvieron un resultado perfecto al primer intento. La prueba ya no distingue un modelo de 8B de uno de punta.
1 modelo respondió preguntas que no podía sustentar en la fuente, y lo hizo mientras decía que la pregunta estaba fuera de alcance: un calificador que buscara frases de rechazo en lugar de la decisión lo habría aprobado.
Cómo lo medimos
Las fuentes se fijaron una sola vez (las mismas páginas, el mismo orden, el mismo presupuesto para cada modelo) y luego solo cambió el modelo. Dos ejecuciones de confirmación independientes; la calificación es mecánica y cada aparente retroceso se volvió a leer a mano.
Lo que no demuestra
Que estos modelos sean intercambiables en general. El conjunto cubre un corpus con una sola instrucción, y que 6 de 8 obtengan un resultado perfecto significa que llegó a su techo: no puede ordenar a los mejores, solo mostrar que este trabajo en particular es más fácil de lo que se suponía. Nada aquí prueba la inyección de instrucciones ni fuentes contradictorias.
Cuantificación de obra: ¿se le puede confiar una cantidad a un modelo?
·1 modelos · 27 partidas del presupuesto
0/1candidatos descalificados por inventar, aplicar mal o no pasar el validador
AbrirCerrar
La pregunta
Llenar un presupuesto de construcción de 27 partidas a partir de planos reales y un estudio de suelos, donde inventar una cifra es peor que dejar la celda vacía. ¿En qué modelos se puede confiar para una cifra que cuesta dinero si está mal?
Lo que encontró
El modelo que llenó MÁS partidas fue el menos confiable: el propio validador del sistema rechazó su respuesta por errores de aritmética, aunque mostraba cero valores inventados y cero errores de alcance. Ordenar por partidas llenadas lo habría puesto en primer lugar.
Un «error de alcance» (una cifra real, bien medida, aplicada a la extensión equivocada) es la falla peligrosa. La cita es auténtica, así que todas las demás verificaciones pasan y solo un experto en la materia la detecta.
0 candidato no respondió nada. Con la regla de descalificación eso es una hoja limpia, y precisamente por eso una hoja limpia no se puede leer como una victoria.
Cómo lo medimos
Un sistema determinista llena el presupuesto con los mismos planos para cada modelo y luego se aplican dos verificaciones independientes al resultado: una de citas, para cantidades inventadas, y una auditoría de alcance, para cifras aplicadas a la extensión equivocada. El sistema valida la aritmética por separado.
Lo que no demuestra
Nada aquí demuestra que un modelo pueda llenar correctamente cuando los datos son buenos. La propia ejecución de referencia solo pudo llenar con fundamento 1 de 27 partidas en la mayoría de las ejecuciones, porque los planos no tienen áreas por zona. Cada cifra de coincidencia está limitada por ese techo.
Enrutador: nuestro enrutamiento medido frente a auto-beta de OpenRouter
·3 chatbots en producción · 57 turnos
2.4×más rápido con las mismas respuestas: 1161 ms frente a 2798 ms en promedio
AbrirCerrar
La pregunta
Con turnos reales de chatbots en sitios de clientes, ¿elegir nosotros el modelo a partir de pruebas medidas supera a dejar la decisión al enrutador automático de OpenRouter, en calidad de respuesta y en costo?
Lo que encontró
Los dos enrutadores eligieron un modelo distinto en prácticamente todos los turnos, y aun así la calidad se mantuvo: 50 empates, 4 victorias para nuestro enrutamiento y 3 para auto-beta. Elegir distinto no significó obtener un resultado distinto.
El resultado de costo ya cambió en AMBOS sentidos entre ejecuciones: nuestras elecciones medidas fueron 2.4× más baratas en julio; luego auto-beta bajó de gama y resultó 3.1× más barato en la actualización de 2026-08 (USD 0.01 nuestro frente a USD 0.00391). Una comparación de una sola vez seguiría afirmando lo que dijera el mes en que se ejecutó.
Lo que se mantuvo tras el cambio: la paridad de calidad y la diferencia de latencia. El enrutamiento medido responde desde un grupo pequeño y fijo de modelos en lugar de pasar por un mercado intermedio, y en un chatbot en vivo los segundos de espera son un defecto del producto.
Cómo lo medimos
Cada turno pasa por ambos enrutadores con el mismo contexto, y luego un juez de IA califica ambas respuestas a ciegas en una escala de 1 a 5. El costo es el costo real facturado del modelo que eligió cada enrutador.
Lo que no demuestra
Una muestra de este tamaño (57 turnos) indica una dirección. No demuestra que ninguno de los enrutadores sea siempre más barato (las dos últimas ejecuciones no coincidieron justo en eso) y, con 50 de 57 turnos divergentes empatados, nadie puede afirmar una ventaja de calidad. El hallazgo duradero es el método: volver a ejecutar, publicar la cifra que salga y enrutar según la medición, no según la captura de algún mes.
Juez: ¿puede un modelo más económico calificar tan bien como uno de primer nivel?
·7 candidatos · 16 pruebas
100%la mejor coincidencia limpia con la referencia: Haiku 5.5 a USD 0.00106 frente a USD 0.05
AbrirCerrar
La pregunta
Usamos un modelo de IA para juzgar si un asistente respondió con datos del sitio o evadió la pregunta. Ese juez es un instrumento, y usar un modelo de primer nivel cuesta dinero real. ¿Puede un modelo más económico calificar sin cambiar el veredicto?
Lo que encontró
El costo y la fiabilidad son ejes separados. La ejecución más barata no fue la más confiable, y un candidato devolvió en una parte importante de las pruebas resultados que el sistema no pudo interpretar: un juez inutilizable no es un juez barato.
El porcentaje de coincidencia por sí solo oculta la forma del desacuerdo: dos jueces pueden coincidir en el mismo total marcando pruebas distintas, y por eso la ejecución registra los desacuerdos específicos y no solo el puntaje.
El modelo de referencia es el caro a propósito. Define el veredicto; todo lo demás se mide como distancia respecto a él.
Cómo lo medimos
Cada candidato califica el mismo conjunto de pruebas con la misma rúbrica e instrucción, y solo cambia el modelo. La coincidencia se mide contra una referencia fija de un modelo de primer nivel, y las respuestas que no se pueden interpretar se cuentan en lugar de descartarse.
Lo que no demuestra
16 pruebas sobre una tarea. La referencia señaló una falla en todas las pruebas, así que no se probaron las falsas alarmas ante una buena respuesta. Esto dice qué jueces siguen a nuestra referencia en ESTE trabajo de calificación: no se traslada a otra rúbrica ni establece que la referencia misma sea correcta. El juez es un instrumento; esta ejecución lo calibra, no lo valida.
Lo útil de una comparativa rara vez es el ganador. Es el modo de falla que no sabía que debía buscar: un modelo que llena todas las celdas y se equivoca en la aritmética, un juez que devuelve texto que nada puede interpretar, un enrutador que elige distinto cada vez y llega al mismo resultado. Esos son los hallazgos que cambian lo que lanzamos.
Por eso cada ejecución se publica con su límite a la vista. Una comparativa sobre una tarea, con una referencia y en un momento dado, habla de esa tarea. Lo decimos en lugar de dejar que un resultado acotado se lea como una afirmación general; y cuando una corrección reemplaza una ejecución, las cifras anteriores siguen visibles y marcadas, en lugar de desaparecer sin aviso.