Benchmark diario para rastrear la degradación de rendimiento de Claude Code

• Sistema de seguimiento que mide diariamente el rendimiento de Claude Code Opus 4.5 en tareas de SWE para detectar una degradación de rendimiento estadísticamente significativa
• Usa un subconjunto seleccionado de SWE-Bench-Pro para evaluar 50 instancias de prueba cada día, y los resultados reflejan el rendimiento real del modelo ejecutado directamente en un entorno CLI
• En los últimos 30 días se detectó una tasa promedio de aprobación del 54%, una caída estadísticamente significativa de 4.1% frente a la línea base de 58%
• Los resultados diarios y semanales se analizan con base en intervalos de confianza del 95% y umbrales de significancia (±14.0%, ±5.6%), para distinguir entre variaciones de corto plazo y tendencias de largo plazo
• Operado por una tercera parte independiente, es una herramienta para la detección temprana de degradación de rendimiento causada por cambios en el modelo o en el entorno de ejecución

---

Descripción general

• El objetivo de este rastreador es detectar una degradación estadísticamente significativa en el rendimiento de Claude Code Opus 4.5 en tareas de SWE
  • La evaluación se realiza todos los días usando un subconjunto resistente a contaminación de SWE-Bench-Pro
  • Se ejecuta directamente en Claude Code CLI, reflejando el entorno real de los usuarios sin un harness personalizado adicional
• Es una tercera parte independiente, sin afiliación con proveedores de modelos frontier
• Se opera como un recurso para detectar de forma temprana casos similares en el futuro, a raíz del postmortem de Anthropic sobre degradación de rendimiento de septiembre de 2025

Resumen de rendimiento

• Tasa de aprobación de referencia: 58%
• Tasa de aprobación de los últimos 30 días: 54% (sobre 655 evaluaciones)
• Tasa de aprobación de los últimos 7 días: 53% (sobre 250 evaluaciones)
• Tasa de aprobación del último día: 50% (sobre 50 evaluaciones)
• La degradación de rendimiento en 30 días es estadísticamente significativa al nivel p < 0.05
  • Variación en 30 días: -4.1%
  • Umbral de significancia: ±3.4%
• Las variaciones de 1 día (-8.0%) y 7 días (-4.8%) no son estadísticamente significativas

Tendencias diarias y semanales

• Tendencia diaria (Daily Trend)
  • Visualiza la tasa de aprobación diaria de los últimos 30 días
  • Línea base de 58%, rango de umbral de significancia de ±14.0%
  • Puede mostrar intervalos de confianza del 95%; cuanto menor sea el tamaño de la muestra, más amplio será el intervalo
• Tendencia semanal (Weekly Trend)
  • Proporciona una tendencia suavizada con un promedio móvil de 7 días para reducir la volatilidad diaria
  • Línea base de 58%, rango de umbral de significancia de ±5.6%
  • También puede mostrar intervalos de confianza del 95%

Resumen de cambios (Change Overview)

• Cambio de 1 día (vs. ayer): -8.0%, no es estadísticamente significativo
  • Basado en 50 evaluaciones, se requiere un cambio de ±14.0% (p < 0.05)
• Cambio de 7 días (vs. la semana pasada): -4.8%, no es estadísticamente significativo
  • Basado en 250 evaluaciones, se requiere un cambio de ±5.6% (p < 0.05)
• Cambio de 30 días (vs. el mes pasado): -4.1%, estadísticamente significativo
  • Basado en 655 evaluaciones, se requiere un cambio de ±3.4% (p < 0.05)

Metodología (Methodology)

• Cada prueba se modela como una variable aleatoria de Bernoulli y se calculan intervalos de confianza del 95%
• Se analizan las diferencias estadísticas en las tasas de aprobación diarias, semanales y mensuales para reportar si existe una degradación de rendimiento significativa
• La evaluación se realiza con 50 instancias de prueba diarias, por lo que existe volatilidad de corto plazo
• Los resultados agregados semanales y mensuales ofrecen estimaciones más estables
• Permite detectar degradación de rendimiento tanto por cambios en el modelo como por cambios en el harness de ejecución

Función de alertas

• Si se detecta estadísticamente una degradación de rendimiento, se envía una alerta por correo electrónico
• Los usuarios pueden suscribirse registrando su dirección de correo electrónico
• Tras confirmar la suscripción, pueden recibir alertas; si ocurre un error, se indica reintentar

---

[iolothebard]

No es que Claude Code se haya vuelto más tonto… quizá sea que quien lo usa ahora sabe aprovechar mejor a Claude…

[GN⁺]

Comentarios de Hacker News

• Soy Thariq del equipo de Claude Code
  Ya corregimos el problema del harness que ocurrió el 26 de enero. También hicimos rollback de inmediato el 28 de enero, así que recomendamos actualizar a la versión más reciente con el comando claude update

  • La versión 2.1.x de Claude se congela con frecuencia o usa el CPU al 100%, al punto de volverse prácticamente inutilizable. El issue relacionado está en GitHub #18532
  • Claude desperdició tokens y me pregunto si habrá alguna compensación por eso
  • Quisiera saber con más precisión qué significa exactamente “harness issue” y qué impacto tuvo
  • El problema existía desde antes del 26 de enero. Desde entonces Claude empezó a modificar planes arbitrariamente diciendo que era una “mejora”
  • Más que el modelo en sí, me interesa el sistema de control de calidad. Me pregunto si existe algún proceso interno para revisar periódicamente muestras reales de salida o monitorear degradaciones de rendimiento con benchmarks. Desde la perspectiva de la seguridad en IA, este tipo de validación es indispensable

• Soy coautor de SWE-bench
  Parece que la prueba actual solo se ejecuta una vez al día sobre 50 tareas. Para mejorar la precisión, habría que probar 300 tareas entre 5 y 10 veces al día y luego sacar el promedio. Factores aleatorios como la carga del servidor pueden afectar mucho los resultados

  • ¿No debería medirse también la degradación causada por sobrecarga del servidor? Al menos si no se busca medir solo la destilación del modelo
  • Probablemente el problema sea el costo de ejecutar el modelo. Estaría bien que Anthropic diera algo de crédito o que abrieran un enlace para donaciones
  • La diferencia de rendimiento según la hora del día podría ser todavía mayor
  • Existe la preocupación de que el costo de ejecutar SWE-bench sea demasiado alto como para correrlo suficiente. En mafia-arena.com están pasando por un problema parecido
  • Suena raro decir “el servidor está sobrecargado y por eso la medición no es precisa”. Entonces, ¿acaso hay algún horario laboral en el que Claude sí funcione bien?

• Resumen de por qué no creo que Anthropic esté entregando a los usuarios un modelo peor a propósito

  1. La caída de precisión es pequeña y oscila hacia arriba y abajo
  2. No hay una línea base de comparación con Sonnet 4.5, y bajo carga de GPU Opus podría caer al nivel de Sonnet
  3. Es muy probable que estén haciendo pruebas A/B con varios checkpoints. También podrían influir las actualizaciones de versión de Claude Code o la no determinación del muestreo de tokens
  • Entiendo la explicación científica, pero usándolo todos los días de verdad se siente que el rendimiento empeora
  • Yo también creo que las pruebas A/B son la causa principal. Ojalá publicaran con transparencia cosas como los límites de ventana de contexto o cambios en el system prompt. Lo ideal sería que el usuario pudiera elegir la versión y dar feedback directamente
  • Me da curiosidad por qué el gráfico empieza el 8 de enero. Ese momento podría haber sido un día anormalmente alto
  • También podría ser una estructura que ajusta automáticamente la relación rendimiento-costo según la carga. Tal vez empieza con alto rendimiento y luego, para ahorrar costos, reduce gradualmente el modelo o disminuye la cantidad de expertos en un MoE
  • Decir que “la caída es demasiado pequeña” es solo un juicio subjetivo que ignora la significancia estadística

• La metodología estadística es extraña
  Ellos solo consideran el intervalo de confianza del valor anterior y miran si el nuevo valor queda fuera, pero ese no es un método correcto para verificar la significancia estadística de la diferencia. Como ambas mediciones tienen incertidumbre, habría que calcular el intervalo de confianza de la diferencia en sí. Además, si la comparación es mensual, entonces habría que comparar los datos de hace 60 a 31 días con los de hace 30 días hasta ayer, así que el gráfico debería mostrar al menos dos meses

• Hace como una semana Claude estuvo caído alrededor de una hora. Justo después de recuperarse, quizá porque bajó la cantidad de usuarios, la velocidad se volvió más de 3 veces mayor. En esa hora hice el trabajo que normalmente me tomaría medio día. Se sintió como ver por un momento cómo sería el futuro sin restricciones de recursos

  • Durante los feriados en EE. UU. también se relajaron los límites de uso y todo funcionaba mucho mejor
  • A mí me pasó lo mismo hace unos días. Fue tan rápido que hasta busqué “claude speed boost”. Era una velocidad relámpago momentánea, como cuando antes te mejoraban el módem
  • Si se vuelve demasiado rápido, hasta da un poco de pena. Ahora al menos se siente que el modelo está trabajando duro

• Si se mide la frecuencia de groserías en los prompts de los usuarios, quizá se podría detectar un aumento de la hostilidad cuando baja el rendimiento del modelo

  • Pero, ¿existe alguna forma de escanear “simplemente” los prompts de los usuarios de Claude?
  • Hay una correlación entre el aumento de groserías y momentos justo después de solicitudes de feedback como “How’s Claude Doing This Session?”
  • Yo suelo decir groserías de por sí, así que mis datos podrían estar sesgados
  • Yo también soy así, qué alivio
  • A veces me salen groserías cuando responde algo demasiado tonto. Es una reacción causada por expectativas altas

• Existe la posibilidad de que con el tiempo cuanticen gradualmente el modelo (quantization). Eso facilitaría la escalabilidad y la reducción de costos, además de hacer que una nueva versión “parezca” mejor por comparación

  • Lo uso entre 5 y 10 horas diarias y, definitivamente, en la última semana se ha sentido más tonto. Aunque lo nieguen, en la práctica sí se percibe un cambio
  • Ni siquiera haría falta cuantización; también se podría reducir la carga con cosas como acortar la longitud de la conversación o reducir el tiempo de razonamiento
  • Modelos abiertos como GPT-OSS o Kimi K2.x también fueron entrenados con capas de 4 bits. Opus 4.5 cuesta 8 veces más por token, así que probablemente sea un modelo más grande, pero por la estructura de precios de suscripción no es fácil compararlos directamente
  • Anthropic no parece una empresa tan limitada por costos de infraestructura. En un entorno de competencia intensa, bajar la calidad a propósito sería una mala estrategia. Tal vez los usuarios simplemente reconocen mejor los defectos después del “efecto luna de miel”
  • Aun así, una estrategia de degradación gradual sí parece perfectamente posible. Podría maximizar la mejora relativa percibida del modelo nuevo

• En modo API, cuando Claude supera cierta cantidad de tokens, de pronto se vuelve más tonto y empieza a hacer cosas raras, como decir “hay un bug en la línea 23” y luego borrar toda la funcionalidad. Incluso falla en arreglos simples que ChatGPT 3.5 podría hacer. No entiendo por qué pasa esto

  • Probablemente sea por restricciones de recursos. Es posible que hayan optado por dar respuestas decentes a más usuarios, en lugar de dar muy buenas respuestas a algunos pocos
  • A mí me pasó lo mismo. Claude se siente cada vez más flojo

• En la última semana la calidad del código de Claude empeoró de forma notable. Por ejemplo, sugiere usar frozen en un Enum, o vuelve a proponer urlparse dentro de una función que ya usa urlparse. Antes no cometía este tipo de errores básicos

• Una gran queja sobre los proveedores de LLM es la falta de consistencia en la capacidad de razonamiento. Con ChatGPT pasa igual: al ingresar más de 45k tokens, la inteligencia cae bruscamente o la entrada se recorta. Sería mejor recibir un mensaje de “rechazo” que una degradación silenciosa, porque eso destruye la confianza. La transparencia es realmente importante

  • Probablemente esté relacionado con el fenómeno de Maximum Effective Context Window