Anthropic publicó un post-mortem detallado de ingeniería explicando las seis semanas de quejas sobre la calidad de Claude Code que corrieron de marzo a mediados de abril. Tres cambios de capa de producto no relacionados se enviaron entre el 4 de marzo y el 16 de abril, cada uno afectando una porción diferente de tráfico en su propio calendario — por eso los usuarios reportaron síntomas salvajemente diferentes según cuándo usaban Claude Code y qué funcionalidades usaban. Críticamente, la API y los pesos del modelo subyacente no fueron afectados. Los tres problemas están resueltos a partir de Claude Code v2.1.116 el 20 de abril, y Anthropic ha reseteado los límites de uso para todos los suscriptores. La divulgación honesta es la parte que distingue esto del comunicado típico de "estamos mejorando el producto": fechas específicas, commits específicos, números de calidad específicos, y responsabilidad nombrada del equipo de Claude Code.
Los tres cambios se desglosan limpiamente. Primero, el 4 de marzo, el esfuerzo de razonamiento por defecto pasó de high a medium para arreglar congelamientos de UI durante períodos largos de razonamiento — Anthropic reconoce que fue "el tradeoff equivocado" y revirtió el 7 de abril. Todos los modelos ahora default a high o xhigh. Segundo, el 26 de marzo, una optimización para limpiar viejas secciones de pensamiento de sesiones inactivas (sesiones inactivas por 1h+, donde un cache miss completo era inevitable de todos modos) tuvo un bug que disparaba la limpieza en cada turno en lugar de solo una vez. Claude seguía ejecutando pero cada vez más sin memoria de por qué eligió su enfoque actual. Boris Cherny en Hacker News nombró el caso extremo: un usuario con 900K tokens en contexto inactivo por una hora enfrentaría un cache miss completo en el siguiente mensaje, consumiendo un porcentaje significativo de los rate limits — especialmente para usuarios Pro. Arreglado el 10 de abril. Tercero, el 16 de abril junto con Opus 4.7, Anthropic agregó un límite de verbosidad al system prompt instruyendo al modelo a "mantener el texto entre llamadas de herramientas a 25 palabras o menos" y "mantener respuestas finales a 100 palabras o menos". Las pruebas internas no encontraron regresiones. Ablaciones más amplias corridas durante la investigación revelaron una caída de calidad del 3% en Opus 4.6 y 4.7. Revertido el 20 de abril. Como meta-hallazgo, la propia herramienta de Code Review de Anthropic fue back-testeada contra los PRs ofensores: Opus 4.7 encontró el bug de cache cuando se le dio suficiente contexto de repo; Opus 4.6 no.
La crítica comunitaria vale la pena ponderarse junto al post-mortem. Los comentaristas de Hacker News cuestionaron si la reducción de latencia era el verdadero motor del pruning de sesión inactiva, o si la reducción de costo era el objetivo real con la latencia como cobertura. Varios señalaron que publicar benchmarks contra un system prompt más viejo y luego enviar uno nuevo sin divulgación "se siente engañoso". Fortune reportó que los usuarios se sintieron "gaslighted" por las negaciones iniciales de Anthropic. La respuesta de Anthropic a Fortune incluyó la línea "compute es una restricción a través de toda la industria" junto con el pitch de partnership de scaling. Dos problemas que el post-mortem no aborda también valen la pena rastrear: usuarios de Reddit reportan que Claude Code delega más a menudo de lo esperado al modelo Haiku más barato — visible solo en logging verbose — lo cual es una clase de riesgo de calidad silenciosa en pipelines automatizados pero obvia en uso interactivo. Y al menos un usuario de Reddit confirmó independientemente que las instrucciones de verbosidad permanecieron en el system prompt después del revert anunciado del 20 de abril, construyendo un script de pre-tool hook que contrarrestaba cinco modos de falla específicos alrededor de re-lectura de fuente saltada y salida confiable-pero-mismatch. El hecho de que el workaround construido por el usuario mejoró la calidad es en sí mismo una validación del diagnóstico del post-mortem de que el límite de verbosidad degrada la calidad.
Para builders corriendo Claude Code en producción: los fixes canónicos son v2.1.116. Si tienes flujos CI o automatizados que corrieron durante marzo-abril, audita cualquier salida por la huella de los tres cambios — especialmente sesiones largas inactivas (bug de cache) y cualquier salida alrededor del 16-20 de abril (prompt de verbosidad). Para builders enviando productos backed-LLM en general, la lección de ingeniería levantada directamente: las evaluaciones internas fallaron en atrapar cualquiera de los tres problemas porque el personal interno usaba builds diferentes a la release pública, el bug de cache solo se manifestó en un estado específico (sesiones rancias) no ejercitado en eval, y la suite de eval fue demasiado estrecha para detectar una caída de calidad del 3% en cambios de system prompt. La remediación declarada de Anthropic — personal interno en builds públicos exactos, suites de eval per-modelo más amplias para cada cambio de system prompt, períodos de remojo y rollouts graduales, versionado cuidadoso de cambios de system prompt — es una baseline industrial razonable. La admisión "compute es una restricción" también importa: si Anthropic está haciendo tradeoffs de costo/latencia que degradan visiblemente la calidad, la misma lógica aplica a cada vendor, y los equipos de procurement de producto deberían preguntar explícitamente sobre decisiones latencia-vs-calidad en SLAs de vendor.