Análisis post mortem de tres problemas recientes de degradación de calidad en Claude

• Entre agosto y principios de septiembre, se produjo una degradación en la calidad de las respuestas de Claude debido a tres bugs de infraestructura
• Las causas principales del problema fueron, respectivamente, un error de enrutamiento de la ventana de contexto, corrupción de salida y un error de miscompilación de top-k aproximado en XLA:TPU
• Cada bug se superpuso con los otros en distintos tipos de hardware y rutas de despliegue, lo que hizo mucho más difícil el diagnóstico
• Entre las razones del retraso en la detección y resolución estuvieron fallas en el proceso de validación y restricciones de acceso derivadas de políticas de privacidad
• Anthropic está trabajando para prevenir incidentes similares mediante mejoras en evaluación y monitoreo, además del desarrollo de herramientas de depuración más rápidas

---

Resumen y contexto

• Desde agosto hasta principios de septiembre, se reportó una degradación intermitente en la calidad de las respuestas de Claude
• Al principio se consideró una variación normal dentro del feedback de los usuarios, pero al aumentar de forma sostenida los reportes, se inició una investigación
• Anthropic aclaró explícitamente que la causa del problema fueron únicamente bugs de infraestructura, no la demanda ni la carga de los servidores
• Claude se ofrece a millones de usuarios a través de varias plataformas (APIs, Amazon Bedrock, Google Vertex AI, etc.) y mantiene criterios estrictos de validación para garantizar resultados equivalentes en hardware diverso como AWS Trainium, NVIDIA GPU y Google TPU
• En este análisis post mortem se explican las causas de los bugs, por qué se retrasaron el diagnóstico y la solución, y qué medidas se tomarán para evitar que vuelva a ocurrir

Cómo se opera Claude a gran escala

• El servicio de Claude mantiene un despliegue global sobre distintos tipos de hardware (Trainium, GPU, TPU)
• Los criterios de equivalencia de implementación para garantizar la misma calidad en cada plataforma son estrictos
• Cuando se hacen cambios de infraestructura, se requiere un proceso riguroso de validación en todas las plataformas y configuraciones

Cronología de los principales incidentes

• 5 de agosto: el primer bug afecta aproximadamente al 0.8% de las solicitudes de Sonnet 4
• 25 y 26 de agosto: se despliegan el segundo y el tercer bug, respectivamente
• 29 de agosto: un cambio en el balanceo de carga dispara el tráfico afectado, y más usuarios comienzan a verse impactados
• Los síntomas de cada bug se superpusieron, lo que elevó mucho la dificultad del diagnóstico

Los tres bugs superpuestos y cómo se resolvieron

1. Error de enrutamiento de la ventana de contexto

• El 5 de agosto, algunas solicitudes de Sonnet 4 fueron dirigidas por error a servidores destinados a una ventana de contexto de 1M tokens
• Tras el cambio de balanceo de carga, el problema llegó a afectar hasta el 16% de las solicitudes de Sonnet 4, con impacto menor también en Amazon Bedrock y Google Vertex AI
• Como el método de enrutamiento era "sticky", una vez que una conexión caía en un servidor incorrecto, seguía conectándose al mismo servidor después
• Solución: se mejoró la lógica de enrutamiento; el parche se aplicó en la plataforma propia el 4 de septiembre, se desplegó en Google Cloud hasta el 16 de septiembre y su aplicación gradual en Bedrock sigue en curso

2. Corrupción de salida (bug)

• El 25 de agosto, se aplicó una configuración incorrecta a los servidores TPU de la API de Claude, lo que provocó errores durante la generación de tokens
• Se observaron casos en los que, por ejemplo, en respuestas a preguntas en inglés aparecían caracteres extraños mezclados, como tailandés o chino, además de errores de sintaxis evidentes insertados en código
• Solo afectó a Opus 4.1, Opus 4 y Sonnet 4; las plataformas de terceros no se vieron afectadas
• Solución: el cambio se revirtió el 2 de septiembre y se agregó al proceso de despliegue una prueba para detectar salidas con caracteres anómalos

3. Error de miscompilación de top-k aproximado en XLA:TPU

• El 25 de agosto, al mejorar el método de selección de tokens, salió a la luz un bug latente en el compilador XLA:TPU
• Afectó a Claude Haiku 3.5, a parte de Sonnet 4 y a Opus 3
• Las plataformas de terceros no se vieron afectadas
• Solución: Haiku 3.5 se revirtió el 4 de septiembre y Opus 3 el 12 de septiembre; Sonnet 4 no pudo reproducirse directamente, pero también se revirtió como medida preventiva
• En paralelo, se está trabajando con el equipo de XLA:TPU para corregir el bug del compilador y se está migrando al uso de top-k exacto

Análisis detallado del bug del compilador XLA

• Durante la generación de tokens, Claude calcula probabilidades para cada candidato y realiza muestreo
• Las TPUs operan en entornos distribuidos, por lo que sincronizar el cálculo de probabilidades de tokens añade complejidad
• En diciembre de 2024, se detectó un problema en el que, por errores derivados del uso de precisión mixta bf16-32 bits, podía omitirse el token con mayor probabilidad, y se desplegó una corrección temporal
• El 26 de agosto, durante una refactorización del código de muestreo para resolver la causa raíz, se expuso un bug más profundo que hacía que la operación de top-k aproximado devolviera resultados completamente incorrectos en ciertos casos
• Ese bug había quedado oculto por la corrección temporal anterior
• Además, el bug en la operación de top-k aproximado mostraba síntomas irregulares según el entorno de producción y el tamaño del batch
• En lugar de top-k aproximado, recientemente se migró a exact top-k, cuyo costo de rendimiento se ha reducido mucho, y se mejoraron operaciones clave mediante una estandarización en fp32

Por qué se retrasó la detección

• Ya se utilizaban procedimientos como evaluaciones automatizadas periódicas y despliegues previos en grupos reducidos
• Estos incidentes dejaron en evidencia vacíos en el proceso de evaluación. Por ejemplo, había métricas que no detectaban bien las condiciones problemáticas, y las políticas internas de privacidad (que impiden a los ingenieros acceder a solicitudes específicas de usuarios) dificultaron un análisis rápido
• Como los síntomas aparecían de distintas formas según la plataforma y la versión, fue difícil identificar una causa única
• Incluso cuando aumentaron bruscamente los reportes en línea, no se reconoció de inmediato la relación con un cambio estándar en el balanceo de carga

Mejoras y medidas futuras

• Desarrollo de métricas de evaluación más sensibles y refuerzo de evaluaciones automatizadas capaces de distinguir con mayor claridad entre estados corruptos e implementaciones normales
• Ampliación de los sistemas de evaluación y monitoreo a todo el entorno de producción, por ejemplo con evaluaciones centradas en condiciones operativas como errores de enrutamiento de la ventana de contexto
• Creación de herramientas de depuración más rápidas y sofisticadas, junto con infraestructura y herramientas personalizadas para analizar con rapidez el feedback de la comunidad preservando la privacidad
• Además de las evaluaciones internas, se destaca la importancia de seguir recopilando feedback de los usuarios: los errores o bugs difíciles de predecir suelen detectarse primero a través de reportes reales
• Se alienta activamente a usar el comando /bug o la función "thumbs down", y a enviar por correo observaciones sobre cómo evaluar la calidad del modelo

Explicación de referencia

• XLA:TPU es un compilador que convierte código del lenguaje de optimización de alto nivel XLA en instrucciones para TPU
• Como el tamaño del modelo es grande, se divide entre varios chips en lugar de colocarse en uno solo, y operaciones como sorting deben implementarse en forma vectorizada
• La operación de top-k aproximado se usa para mejorar el rendimiento, pero puede implicar problemas graves como omitir el token con mayor probabilidad
• Actualmente ya se adoptó el método de top-k exacto, y puede haber cambios sutiles en qué tokens quedan incluidos cerca del umbral de top-p. En algunos casos, los usuarios podrían necesitar ajustar el valor de top-p

[GN⁺]

Opinión de Hacker News

• Últimamente me llamó la atención la ausencia de pruebas unitarias. Incluso las pruebas para el bug del compilador XLA parecían limitarse a imprimir la salida, muy lejos de verdaderas pruebas unitarias ejecutadas en un harness de testing real para rastrear cobertura. La respuesta parece ser algo como depender más de Eval. Hoy por hoy, hacer pruebas unitarias del LLM completo no es realista, pero la mayoría de los bugs que han aparecido hasta ahora estaban en partes pequeñas y deterministas del sistema. Por ejemplo, balanceo de carga, cálculo de probabilidades top-k, etc., son partes de ingeniería como en cualquier otro software, así que en principio sí se pueden cubrir con pruebas unitarias. Si hace falta, con un PRNG inyectable basta. Los bugs de optimización no determinista sí son un dolor de cabeza, pero incluso suites de prueba de aplicaciones convencionales han encontrado bugs en compiladores y bases de datos en el pasado. Si en CI ejecutas muchas pruebas repetidamente, también pueden salir a la luz eventos raros. En un proyecto personal corro todas las pruebas unitarias en paralelo dentro del mismo proceso, y con ese método he podido detectar bastante bien problemas raros de thread safety y deadlocks de base de datos. Hace unos días, en un hilo sobre el lanzamiento de Java, comenté que una razón por la que Java se percibe como más “enterprise” que Python es que el código suele escribirse con mucho foco en pruebas unitarias. Eso lleva a mucha abstracción por temas como inyección de dependencias. En cambio, en la cultura de lenguajes de scripting muchas veces no hay pruebas o son solo superficiales, por ejemplo, aserciones de tipos. Tuve una impresión parecida al aprender PyTorch: los tutoriales van subiendo de complejidad poco a poco, pero casi no hablan de testing ni de estructura de código. Eso puede servir en investigación de ML, donde la meta es subir métricas de evaluación, pero no encaja bien con despliegues de producción a gran escala. Me hace pensar si a los laboratorios de IA no les haría falta más gente con experiencia en SRE o en software HA. Personalmente, dudo que en producción la mejor defensa contra bugs sea simplemente ejecutar Eval de forma agresiva
  • He tenido experiencias donde tuve que darle a la IA prompts y ejemplos muy detallados para que escribiera el tipo de pruebas unitarias en Python que yo quería. También he visto muchas veces que solo usa aserciones sobre tipos. Lo que yo quiero son aserciones sobre los valores mismos. La IA tiende a hacer mocking de absolutamente todo; el mocking sirve, pero en pruebas unitarias, mientras más código real invoques, más cubres riesgos de interacción e interfaz. Sin embargo, las pruebas unitarias en Python generadas por IA suelen obsesionarse tanto con el mocking que terminan verificando solo código tautológico y nada más. Por eso meto en el prompt advertencias explícitas contra abusar del mocking y ejemplos de pruebas bien cuidadas. Y por cierto, Python también tiene muy buenas herramientas para escribir código estructurado, incluyendo inyección de dependencias
• Me sorprendió que el artículo sugiriera que Anthropic puede influir directamente en la infraestructura de AWS Bedrock. Eso iría contra la promesa original de AWS. Imagino que con Google Vertex AI pasa algo parecido, aunque todavía no lo he verificado desde el lado de compliance.

Entiendo que, por políticas internas de privacidad y seguridad, el acceso de los ingenieros a las interacciones de usuarios de Claude es limitado. También coincido en que sigue siendo más útil que el usuario envíe feedback directamente y en que se puede usar el comando /bug en Claude Code. Si al reportarlo por ese comando los ingenieros pueden revisar el contexto, me gustaría que eso se comunicara de forma muy clara a los usuarios (yo no uso Claude Code). La recomendación de usar el botón de "thumbs down" en la app de Claude me preocupa un poco. La mayoría de los usuarios probablemente no interpreta ese clic con el mismo peso que renunciar a su privacidad

• (Empleado de Anthropic, hablando a título personal)

No es cierto que Anthropic administre directamente la infraestructura de AWS Bedrock. Actualmente la opera AWS. Sobre la advertencia de privacidad del botón de "thumbs down", el modal sí indica: "Al enviar este feedback, la conversación actual completa se enviará a Anthropic y se usará para mejorar el modelo". Me pregunto si hay alguna forma de hacer ese texto más claro todavía

• Cuando haces clic en "thumbs down", sí aparece el mensaje de que "al enviar este feedback, la conversación completa se enviará a Anthropic", así que me parece una advertencia bastante clara
• Si un laboratorio del tamaño de Anthropic está compartiendo este nivel de detalle sobre su infraestructura, da la impresión de que la situación está bastante difícil. El bug de precisión relacionado con FMA (multiplicación-acumulación) realmente es desafortunado, y los problemas numéricos suelen ser bastante confusos; todavía no es un área que la IA pueda resolver sola. En una situación de presión extrema, con competidores quitándote participación de mercado en tiempo real, la intervención humana termina siendo indispensable, y encontrar la causa raíz puede tomar semanas
• Dicen que “un cambio de balanceo de carga del 29 de agosto terminó enviando accidentalmente más solicitudes de contexto corto a servidores de contexto 1M, y durante una hora del 31 de agosto afectó al 16% de las solicitudes a Sonnet 4”. Eso hace pensar que esos servidores de contexto 1M en realidad rinden peor con entradas de contexto corto. ¿Quizá porque allí aplican medidas aparte como compresión de caché KV, eviction o sparse attention?
  • Eso se debe al escalado de RoPE (embeddings posicionales rotatorios). La mayoría de los frameworks open source conocidos implementan static YaRN, y ahí el factor de escalado queda fijo sin importar la longitud de entrada, lo que puede perjudicar el rendimiento en textos cortos. Solo conviene añadir la configuración rope_scaling cuando de verdad necesitas contexto largo, y también ajustar el factor a la longitud promedio de entrada de tu aplicación. Por ejemplo, si andas alrededor de 520 mil tokens, es mejor usar factor 2.0 Fuente (página descriptiva de Qwen3-Next-80B)
  • Lo clave del postmortem es que en dos de los tres problemas no dieron una causa exacta. Por lo que entiendo, mi solicitud ahora mismo puede terminar en cualquiera de tres rutas de código completamente distintas, cada una con su propio stack y tuning. Y esas optimizaciones podrían cambiar de golpe aunque no haya actualización de versión del modelo, así que algo que ayer funcionaba hoy podría romperse. Me cuesta entender por qué este tipo de postmortems recibe elogios; a mí más bien me deja aún más frustrado
• Con todo respeto al equipo de Anthropic, la calidad de la página de status de Claude ya debería haber disparado una alerta interna de código rojo. Hubo 50 incidentes en julio, 40 en agosto y 21 en septiembre. En otras épocas, con la mitad de esos números ya habría visto un giro fuerte para que todo el mundo se enfocara en uptime y calidad. Aun así, Claude sigue siendo un producto excelente y por eso sigo pagando. Probé la API y enseguida contraté la membresía Max. Mi productividad se disparó gracias a eso. Pero con las degradaciones de calidad repetidas de las últimas semanas, ya me estoy preguntando si vale la pena seguir suscrito. Agradezco la honestidad al compartir el estado del problema, pero como cliente sí genera mucha molestia. Todavía no creo que temas como el balanceo de carga estén completamente detectados ni resueltos. En concreto, cerca de las 12 del este / 9 del oeste, siento claramente que la calidad de Claude Code baja bastante. Ojalá el equipo siga encontrando y resolviendo estos problemas. También me he topado con muchos bugs complejos corriendo modelos locales en casa, así que entiendo que no son problemas fáciles. Enlace a la página de status
  • No puedo afirmar categóricamente que Claude sea mejor o peor que otras empresas, pero una cosa sí tengo clara: muchas páginas de status mienten. En la práctica hay fallas bastante seguido y aun así no aparecen ahí. De hecho, hoy en día hasta sorprende más cuando una empresa informa sus problemas con honestidad. Yo no he sufrido problemas graves con Claude, aunque quizá solo tuve suerte. Desde mi perspectiva, incluso parece que Claude reporta incidentes con más fidelidad. Claro, también podría ser casualidad
  • Lo más preocupante es que en la página de status se omiten muchos incidentes menores. Todos los proveedores de IA hacen algo parecido. Si publicaran gráficas de estadísticas como latencia de espera de tokens en tiempo real, solicitudes fallidas o rendimiento de tokens por segundo, sería bastante impactante. Los datos de OpenRouter muestran que el uptime de las APIs no es nada bueno. Claude Code también a veces se pone lentísimo y toca interrumpirlo manualmente y reintentar. Se pone especialmente lento entre las 4 y 6 de la tarde (hora del Reino Unido), cuando coinciden Europa, la costa este y la costa oeste de EE. UU. Hoy mismo Gemini AI Studio devolvió errores 503 por sobrecarga del modelo, pero en la página de status no apareció nada. Me pregunto si Claude y otros no podrían introducir planes más baratos en horas valle para repartir mejor la demanda. Aunque ese tipo de plan también podría verse mal de cara al público. Además, parece que el despliegue de GPUs GB200 fue mucho más lento de lo esperado, y hubo bastantes fallas de hardware y software. Los problemas con refrigeración líquida tampoco parecen haber sido menores (y si falla, falla feo)
  • El hecho de que alguien diga “igual pago porque Claude es demasiado bueno” ya es una señal importante. En este momento, para los clientes —incluyéndome— la calidad de la IA importa más que la confiabilidad del servicio. Obviamente los proveedores van a enfocarse en la confiabilidad a largo plazo, pero ¿por qué hoy habría que priorizarla por encima de la calidad?
  • Las caídas recientes de calidad me tienen bastante intranquilo. Por suerte todavía no uso IA en servicios de producción, pero en desarrollo es realmente difícil sortear que un modelo de pronto “se vuelva tonto”. A estas alturas incluso sospecho que varios vendors en OpenRouter podrían estar traicionando la confianza y recortando en secreto contexto, bajando cuantización o reduciendo expertos como truco para gastar menos cómputo
  • Por eso usan la estrategia de minimizar la cantidad de incidentes que aparecen en la página de status. La percepción de los clientes empeora temporalmente, pero con el tiempo ese efecto negativo desaparece. En cambio, si mantienes una página de status de forma consistente, queda evidencia clara de los problemas. A la larga sale más rentable engañar. De hecho, S3 tuvo varias caídas con errores y nunca las hizo públicas, y nadie armó problema. La gente dice muchas cosas, pero en la práctica el sistema recompensa más a quien oculta. Todos los growth hackers de startups ya saben esto muy bien
• Explican que el 25 de agosto se desplegó una configuración incorrecta en los servidores TPU de la API de Claude, lo que provocó errores durante la generación de tokens. Los bugs de código me resultan familiares, pero los LLM no los escribe una persona directamente, sino que nacen de entrenamiento automatizado a gran escala, así que me da curiosidad cómo ocurre un bug así. Por ejemplo, cuando un modelo mete de repente “สวัสดี” en medio de una consulta en inglés, me pregunto estructuralmente cómo se puede inyectar ese tipo de bug desde el punto de vista humano
  • Al final, un LLM corre sobre código escrito por humanos. En la última etapa, el modelo genera una distribución de probabilidad sobre todos los tokens del vocabulario (aprox. 200 mil). Después, los humanos deciden cómo escoger el siguiente token real. Por ejemplo, puedes elegir siempre el token con mayor probabilidad o seleccionar aleatoriamente dentro del top-k para subir la creatividad. Para procesar ese muestreo top-k de forma eficiente, compilan un kernel con XLA, y parece que el bug estuvo ahí: a veces se seleccionaban tokens fuera del top-k
  • Un LLM produce una distribución de probabilidad para el siguiente token, y el resultado final cambia según el método de muestreo ejemplo. Por ejemplo, si la regla era “elige aleatoriamente entre los 4 tokens más probables” y el operador (la desigualdad) estaba mal, puede pasar exactamente lo que describe el texto
  • Entre el usuario y los parámetros del modelo hay varias capas de código escritas por humanos
  • Dicho de forma simple, hay dos etapas: entrenamiento e inferencia. El entrenamiento está muy automatizado y toma mucho tiempo, pero la inferencia es un stack de software distinto que se ejecuta de inmediato cuando entra el prompt del usuario. Ese stack recibe actualizaciones continuas para mejorar rendimiento, y en ese proceso aparecen problemas de inferencia como estos
  • Como los kernels de IA usan operaciones de punto flotante, a veces en rangos numéricos aparentemente normales puede aparecer un valor negativo de forma extraña. Por rendimiento, a veces se desactivan chequeos de overflow y si aparece un negativo, se lo trata como un número muy grande (como si pidieras el índice -1 de un arreglo y te devolviera el último elemento)
• Me parece que intentar hacer determinista el proceso de inferencia de un LLM podría ayudar a rastrear problemas. Hace poco salió incluso un paper que dice que la idea extendida de que “todo se debe al orden de asociación en punto flotante” en realidad no explica por completo el origen del problema. Presentación del paper relacionado
  • El tráfico de red o la carga de las máquinas son inherentemente no deterministas. En el corto plazo, lograr determinismo total (por ejemplo, para auditoría) solo parece realista en trabajos batch donde el costo no sea sensible. En la práctica, ni la búsqueda de Google ni la carga del número de recomendaciones en redes sociales son deterministas. En sistemas distribuidos, la recomendación clave es graceful degradation (mantener servicio parcial), pero con un sistema completamente determinista eso no se puede hacer
  • Diseñar de forma determinista perjudica el rendimiento. Al final quedaría un enfoque tipo “prueba de IQ”: construir otro modelo para monitorear y alertar sobre la calidad del modelo existente
• Me hizo sentido la parte de que “en Google Cloud Vertex AI, el enrutamiento incorrecto entre el 27 de agosto y el 16 de septiembre fue menor a 0.0004%”. En mi trabajo uso CC con esa cuenta y nunca sentí una degradación de calidad. En general, aunque estos bugs sí fueron serios, me parecieron mucho más raros de lo que daban a entender las reseñas online. El período afectado en realidad se concentró mayormente en una o dos semanas. Y la proporción de solicitudes afectadas frente al total también fue relativamente baja
  • Pero el propio artículo de la empresa también dice que “el 30% de los usuarios de Claude Code fue enroutado al menos una vez a un servidor incorrecto y sufrió degradación en la calidad de respuesta”. El routing es “sticky”, así que una vez que te asigna mal un servidor, las siguientes solicitudes siguen yendo al mismo. Si el 30% de los usuarios de Claude Code sufrió degradación, eso es un bug enorme
  • Últimamente me cuesta confiar en las empresas porque, incluso cuando hay caídas globales, suelen decir cosas suaves como “aumentaron los errores para un pequeño subconjunto de usuarios”, y solo actualizan la página de status cuando ya lo aprobó el CTO. Si hubiera una empresa que de verdad se comunicara con honestidad, eso sería una ventaja competitiva en el mercado
• La idea de hacer que los servicios LLM operen de manera determinista ayudaría a rastrear problemas. También se menciona un paper reciente que plantea que no todo se explica solo por el orden de asociación de operaciones de floating point, sino que hay más factores detrás del quiebre del determinismo. Enlace al paper
• Últimamente he vivido un problema grave al diseñar webapps: Claude hace que aparezca texto aleatorio en el DOM. Parece darse específicamente al usarlo junto con Svelte. No estoy seguro de si está relacionado con los fenómenos descritos en el texto, pero antes no había visto una caída de calidad tan seria
• Ojalá el post hubiera incluido cuáles fueron los casos de falla reales. En Claude Code me ha pasado muchas veces que se queda completamente detenido después de una llamada a herramientas, y me pregunto si eso estaba relacionado con alguno de los bugs mencionados aquí
  • A mí también me está pasando exactamente lo mismo cada vez más seguido en estos últimos días. Creo que podría ser algo aparte del bug del texto principal (aunque seguiría siendo un bug), pero ojalá esté equivocado. He notado que aumentó bastante la frecuencia con la que tengo que volver a mandar cosas como “¿por qué te detuviste? sigue por favor”