Cargando datos de benchmark…
EyesInAI·Cargando datos de benchmark en vivo
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.
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?
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.
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.
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?
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.
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.
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?
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.
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.
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?
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.
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.
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?
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.
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.
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?
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.
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.
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?
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.
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.
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?
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.
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.
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.
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.
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.
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?
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.
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.
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?
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.
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.
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?
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.
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.