Durante el último mes, continuaron los reportes de algunos usuarios que indicaban una disminución 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 2025 (v2.1.116). Este postmortem describe la causa de los problemas, las correcciones aplicadas y las medidas para evitar que vuelvan a ocurrir.
Las causas y la evolución de las tres fallas
- Reducción del valor predeterminado del esfuerzo de razonamiento (4 de marzo): Se cambió el nivel predeterminado de esfuerzo de razonamiento de Claude Code de
highamedium. La medida buscaba reducir tiempos de espera tan largos que hacían parecer que la UI se había congelado, pero los usuarios percibieron una baja en la calidad de las respuestas, por lo que finalmente se revirtió el 7 de abril. Actualmente, el valor predeterminado esxhighpara Opus 4.7 yhighpara los demás modelos. - Eliminación del historial de razonamiento por un bug en una optimización de caché (26 de marzo): Al reanudar sesiones que habían estado inactivas durante más de 1 hora, una función diseñada para limpiar el historial previo de razonamiento (
thinking) solo una vez terminó, por un bug, eliminándolo repetidamente en cada turno posterior de la conversación. Como resultado, Claude dejó de recordar por qué había realizado ciertas acciones, lo que causó la “mala memoria”, las respuestas repetitivas y la selección anómala de herramientas que experimentaron los usuarios. Como efecto secundario, también se producían repetidos cache misses (cuando no se encuentran los datos almacenados), lo que hacía que los límites de uso se agotaran más rápido de lo esperado. Se corrigió el 10 de abril. - Instrucción excesiva de concisión en el system prompt (16 de abril): Para reducir las salidas verbosas de Opus 4.7, se añadió al system prompt la instrucción “entre llamadas a herramientas, el texto debe tener 25 palabras o menos; la respuesta final, 100 palabras o menos”. En las pruebas internas no hubo problemas, pero se confirmó que afectaba negativamente la calidad real del código, por lo que se eliminó el 20 de abril.
Por qué se tardó en detectar el problema
- 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 cada causa por separado.
- Había diferencias entre el entorno de pruebas interno y el entorno real de los usuarios. En el caso del bug de caché, por un experimento separado que estaba en curso internamente y por diferencias en cómo se mostraba en la UI, ni siquiera era fácil reproducirlo.
- El sistema de evaluación existente (eval suite) no era lo bastante amplio. El impacto del cambio en el system prompt solo mostró una caída de rendimiento del 3% después de ejecutar evaluaciones más variadas.
Medidas para evitar recurrencias
- Se exigirá que el personal interno use las compilaciones públicas reales para reducir la brecha con las compilaciones de prueba internas.
- Se reforzará el control sobre los cambios al system prompt. Ante cada cambio, se realizarán evaluaciones amplias por modelo, se analizará de forma individual el impacto de cada línea (ablation) y se aplicarán despliegues graduales junto con un periodo suficiente de validación (soak period).
- Se mejorará la herramienta de Code Review. Dado que efectivamente fue posible detectar el bug de caché cuando se le proporcionó a Opus 4.7 como contexto todo el repositorio de código relacionado, se ampliará el alcance de los repositorios que pueden consultarse 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 de 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 capa de inferencia (inference layer) se vieron afectadas. Aun así, sí es cierto que los cambios de configuración y los bugs en la capa de producto (Claude Code) actuaron en conjunto para reducir la calidad percibida por los usuarios. Junto con esto, la empresa anunció una medida para restablecer 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..