Durante el último mes, algunos usuarios reportaron una baja en la calidad de las respuestas de Claude. Tras investigarlo, Anthropic confirmó que la causa fueron tres cambios distintos que afectaron a Claude Code, Claude Agent SDK y Claude Cowork. La API en sí no se vio afectada, y la empresa indicó que todos los problemas quedaron resueltos al 20 de abril de 2026 (v2.1.116). Este postmortem detalla las causas del problema, las correcciones realizadas y las medidas para evitar que vuelva a ocurrir.
Las tres causas de la falla y su evolución
- Reducción del valor predeterminado de reasoning effort (4 de marzo): Se cambió el nivel predeterminado de reasoning effort de Claude Code de
highamedium. La medida buscaba reducir tiempos de espera tan largos que hacían parecer que la UI se había quedado congelada, pero los usuarios percibieron una caída en la calidad de las respuestas, por lo que el cambio se revirtió el 7 de abril. Actualmente, el valor predeterminado esxhighen Opus 4.7 yhighen los demás modelos. - Eliminación del historial de razonamiento por un bug en la optimización de caché (26 de marzo): Al reanudar sesiones que habían estado inactivas por más de una hora, una función diseñada para limpiar una sola vez el historial previo de razonamiento (
thinking) terminó, por un bug, borrándolo repetidamente en cada turno posterior de la conversación. Esto hizo que Claude dejara de recordar por qué había realizado ciertas acciones, causando la “mala memoria”, respuestas repetidas y selección anómala de herramientas que reportaron los usuarios. Como además se producían cache misses de forma reiterada, los límites de uso se consumían más rápido de lo esperado. Se corrigió el 10 de abril. - Instrucción excesiva de brevedad en el system prompt (16 de abril): Para reducir las salidas demasiado verbosas de Opus 4.7, se añadió al system prompt la instrucción “entre llamadas de herramientas, el texto debe ser de 25 palabras o menos, y la respuesta final de 100 palabras o menos”. En las pruebas internas no se detectaron problemas, pero luego se confirmó que afectaba negativamente la calidad real al programar, por lo que se eliminó el 20 de abril.
Por qué el problema tardó en detectarse
- Los tres cambios se aplicaron en momentos distintos y a diferentes volúmenes de tráfico, por lo que parecían una degradación general e inconsistente de la calidad y era difícil identificar una causa puntual.
- Había diferencias entre el entorno interno de pruebas y el entorno real de los usuarios. En el caso del bug de caché, un experimento separado que seguía ejecutándose internamente y diferencias en la forma de mostrar la UI hicieron que reproducirlo no fuera sencillo.
- La suite de evaluación existente no era lo suficientemente amplia. El impacto del cambio en el system prompt solo mostró una caída de rendimiento del 3% después de ejecutar evaluaciones más diversas.
Medidas para evitar que vuelva a pasar
- Se exigirá que el personal interno use los builds públicos reales, para reducir la brecha con los builds de prueba internos.
- Se reforzará el control sobre los cambios en el system prompt. En cada cambio se harán evaluaciones amplias por modelo, análisis de ablación de cada línea, despliegues graduales y un período suficiente de validación (
soak period). - Se mejorará la herramienta de Code Review. A partir de que Opus 4.7 pudo detectar el bug de caché cuando se le dio como contexto todo el repositorio de código relacionado, se ampliará el alcance de los repositorios que puede consultar durante la revisión de código.
- Se abrirá un canal de comunicación con usuarios (@ClaudeDevs) para compartir con transparencia el contexto detrás de las decisiones del producto.
Sobre el punto de que “no hubo una degradación intencional de la calidad”
- Anthropic afirma que nunca degradó intencionalmente el modelo y confirmó que ni la API ni la inference layer se vieron afectadas. Aun así, es cierto que cambios de configuración y bugs en la capa de producto (Claude Code) se combinaron para empeorar la calidad percibida por los usuarios. También se anunció una medida para reiniciar los límites de uso de todos los suscriptores.
13 comentarios
¿Cómo es que las tres causas de la falla están todas directamente relacionadas con recortar costos? jajajaja
Parece que de verdad andan muy, muy cortos de recursos de GPU como para que el rendimiento baje así de tanto...
Esa es la respuesta correcta, pero qué larga la excusa jajaja
Básicamente se aventaron un texto larguísimo diciendo que estuvieron desplegando builds públicas sin siquiera probarlas y que ni después de desplegarlas las probaron. Yo mismo me topé con el bug de inmediato el 26 de marzo, ¿y de verdad creen que tiene sentido que internamente se tarden 3 semanas en confirmarlo...?
En cuanto aplicaron el parche, la cuota de 5 horas que antes tardaba 3-4 horas en agotarse empezó a consumirse en solo 30 minutos; pero como las cuentas de empleados no tienen cuota de 5 horas, o al menos no es tan limitada como para tener que trabajar mirando
/usagea cada rato, seguro que tardaron bastante en detectarlo.En el benchmark diario de SWE-Bench-Pro (conjunto curado), al ver claude code se nota algo interesante
En el tramo del 10/4 al 20/4, el runtime se redujo a la mitad (653 s→345 s), las tool calls también a la mitad (3.3K→1.8K) y los tokens bajaron un 18%, pero la pass rate más bien subió +16 pp. No es un patrón común que las cuatro métricas se muevan al mismo tiempo en una dirección favorable
Los 3 incidentes que explotaron en ese proceso son el postmortem del 23/4, y si los ves, todos pasaron por “intentar reducir tokens/latency”
En cambio, codex (gpt-5.4-xhigh) casi no se movió en el mismo período. La pass rate se mantuvo fija cerca del 56%, y los tokens/runtime/tool calls siguieron en un nivel que es el doble del de claude code
¿No será más bien un post mortem de reducción de costos en lugar de un post mortem de una caída del servicio?
Obligar al personal interno a usar la compilación pública real reduce la discrepancia con las compilaciones para pruebas internas.
jajajaja
Creo que le enseñaron YAGNI a Opus 4.7. Como en cada decisión de arquitectura le ponían de justificación que eran cambios graduales siguiendo YAGNI, pensé que por eso era así, pero al final terminó causando un incidente. Encima, como no tiene una memoria muy larga, le agarró la costumbre de dejar las cosas para después, y eso sí que es un problema grande.
¿Soy el único que piensa que al principio insistieron en que no había ningún problema, y ahora que el tema se hizo demasiado grande como para taparlo, decidieron hacerlo público?
También sentí que la usabilidad de la web de claude.ai se degradó un poco en varios detalles... hasta apagué la memoria para ahorrar tokens.
Siento que, después de ver este anuncio, confío todavía menos en Anthropic.
Arriba hay dos publicaciones relacionadas, y son dos textos con 7 meses de diferencia. Los problemas son exactamente los mismos, tres en cada caso.
Postmortem de tres problemas recientes de degradación de calidad en Claude 2025-09-19
Actualización sobre reportes recientes de calidad de Claude Code 2026-04-24
¡¡Estoy enojado hasta por $5 de crédito!!
Qué lengua tan larga..