Actualización sobre los informes recientes de calidad de Claude Code

• La disminución de calidad percibida de Claude durante el último mes provino de tres cambios distintos en Claude Code, Claude Agent SDK y Claude Cowork, y la API no se vio afectada
• Después de bajar la intensidad de razonamiento predeterminada a medium, se redujeron la latencia y los límites de uso, pero dio la impresión de que Claude Code era menos inteligente, así que el valor predeterminado se revirtió el 7 de abril
• Un bug en una optimización de caché desplegada el 26 de marzo creó un estado en el que el historial de razonamiento se borraba en cada turno en sesiones que superaban el umbral de inactividad, lo que llevó a olvidos, repeticiones, elecciones extrañas de herramientas y un consumo más rápido de los usage limits
• Una línea del system prompt introducida el 16 de abril junto con Opus 4.7 era una restricción pensada para reducir la verbosidad de la salida, pero en evaluaciones más amplias redujo en 3% el rendimiento de algunos modelos, por lo que se revirtió el 20 de abril
• Los tres problemas ya fueron corregidos y se reflejaron en la v2.1.116 lanzada el 20 de abril; reducir la diferencia entre builds internas y públicas, reforzar el control sobre los system prompts y usar evaluaciones más amplias con despliegues graduales quedaron definidos como claves para evitar que vuelva a pasar

---

Alcance de la reciente degradación de calidad y estado de recuperación

• La disminución de calidad de Claude que algunos usuarios percibieron durante el último mes se originó en tres cambios separados en Claude Code, Claude Agent SDK y Claude Cowork, y la API no se vio afectada
• Los tres problemas ya fueron resueltos y se incluyeron en la v2.1.116 lanzada el 20 de abril
• Como cada cambio afectó calendarios distintos y segmentos de tráfico diferentes, en conjunto dio la impresión de una degradación amplia pero inconsistente del rendimiento
• Se investigaron estos reportes desde comienzos de marzo, pero al principio fue difícil distinguirlos de la variación normal en el feedback de usuarios, y al inicio tampoco se reprodujo el mismo problema en uso interno ni en evaluaciones
• Al 23 de abril, se restablecieron los usage limits de todos los suscriptores

Cambio en la intensidad de razonamiento predeterminada de Claude Code

• Cuando se lanzó Opus 4.6 en Claude Code en febrero, la intensidad de razonamiento predeterminada se configuró en high
• Poco después, en el modo high comenzaron a aparecer de forma intermitente tiempos de pensamiento excesivamente largos, haciendo que la UI pareciera congelada, y para algunos usuarios la latencia y el uso de tokens crecieron demasiado
• El nivel de effort de Claude Code se usa como una forma de ajustar si debe pensar por más tiempo o priorizar menor latencia y menor consumo de límites de uso
  • En la capa de producto, se elige un valor predeterminado dentro de la curva de cómputo en tiempo de prueba y se pasa como parámetro de effort a la Messages API
  • Otras opciones se ofrecen mediante /effort
• En evaluaciones y pruebas internas, medium mostró una ligera baja de inteligencia y una gran reducción de latencia en la mayoría de las tareas
  • medium también reducía los problemas de latencia extrema en la cola larga
  • Y ayudaba a maximizar los usage limits de los usuarios
• Con base en esos resultados, se cambió el effort predeterminado a medium y también se informó el motivo mediante un diálogo dentro del producto
• Justo después del despliegue, los usuarios empezaron a sentir que Claude Code parecía menos inteligente
  • Se introdujeron varios cambios de diseño para hacer más visible la configuración actual de effort, como un aviso al iniciar, un selector de effort en línea y la recuperación de ultrathink
  • Pero la mayoría de los usuarios siguió quedándose en el valor predeterminado medium
• Tras incorporar feedback adicional de clientes, esa decisión se revirtió el 7 de abril
  • Ahora todos los usuarios tienen xhigh como valor predeterminado en Opus 4.7
  • Y high como valor predeterminado en todos los demás modelos
• Este cambio afectó a Sonnet 4.6 y Opus 4.6

Optimización de caché que descartó historial de razonamiento previo

• Cuando Claude razona una tarea, ese historial de razonamiento permanece en el historial de conversación, lo que le permite seguir consultando en turnos posteriores los motivos de cambios anteriores y llamadas a herramientas
• El 26 de marzo se desplegó un cambio para mejorar la eficiencia de esta función
  • Anthropic usa prompt caching para hacer que llamadas consecutivas a la API sean más baratas y rápidas
  • Claude escribe los tokens de entrada en caché durante una solicitud a la API y, tras cierto tiempo de inactividad, ese prompt se elimina de la caché para liberar espacio para otros prompts
  • El uso de la caché se gestiona con cuidado, y el enfoque relacionado está resumido en approach
• Por diseño, si una sesión llevaba más de una hora inactiva, se buscaba vaciar una vez los bloques de thinking previos para reducir el costo de reanudar la sesión
  • Esa solicitud de todos modos sería un cache miss, por lo que se intentó reducir la cantidad de tokens sin caché enviados a la API recortando mensajes innecesarios de la solicitud
  • Después de eso, el diseño contemplaba volver a enviar el historial completo de razonamiento
  • Para ello se usaban el header de API clear_thinking_20251015 y keep:1
• En la implementación real hubo un bug: el historial de thinking debía borrarse una sola vez, pero terminó borrándose en cada turno hasta que acababa la sesión
• Una vez que la sesión superaba el umbral de inactividad, todas las solicitudes posteriores de ese proceso se enviaban a la API de forma que se descartaba todo salvo el bloque de razonamiento más reciente
• El problema empeoraba de forma acumulativa
  • Si Claude enviaba un mensaje de seguimiento mientras usaba herramientas, eso mismo se convertía en un turno nuevo bajo el flag roto
  • Como resultado, incluso el razonamiento del turno actual podía terminar descartándose
• Claude seguía funcionando, pero cada vez más sin memoria de por qué había elegido ese comportamiento
  • Para los usuarios esto se manifestaba como olvidos, repetición y elecciones extrañas de herramientas
• Como los bloques de thinking seguían desapareciendo también en solicitudes posteriores, esas solicitudes terminaban siendo cache misses
  • Se cree que reportes separados sobre un consumo más rápido de los usage limits se originaron en este fenómeno
• Hubo dos experimentos no relacionados que hicieron difícil reproducirlo al principio
  • Un experimento interno del lado del servidor relacionado con message queuing
  • Y otro cambio en cómo se mostraba thinking, que ocultó este bug en la mayoría de las sesiones de CLI
• Este bug estaba en la intersección entre la gestión de contexto de Claude Code, la API de Anthropic y el thinking extendido
  • Pasó por revisiones de código hechas por varias personas y por revisión de código automatizada
  • Pruebas unitarias y pruebas end-to-end
  • Verificación automatizada e incluso dogfooding
• Como este problema solo ocurría en el caso límite de sesiones antiguas y además era difícil de reproducir, tomó más de una semana encontrar y confirmar la causa raíz
• Durante la investigación, se hizo backtesting con Opus 4.7 sobre los pull requests que causaron el problema usando Code Review
  • Cuando se le proporcionó junto con el repositorio de código necesario para reunir todo el contexto, Opus 4.7 sí encontró el bug
  • Opus 4.6 no lo encontró
• Para evitar que se repita, se está incorporando soporte para incluir repositorios adicionales como contexto en code review
• Este bug fue corregido en la v2.1.101 del 10 de abril
• Este cambio afectó a Sonnet 4.6 y Opus 4.6

Cambio en el system prompt que buscaba reducir la verbosidad

• El modelo más reciente, Claude Opus 4.7, tiene la característica de producir una salida muy verbosa en comparación con modelos anteriores
  • Esta característica ya se mencionó en el anuncio de lanzamiento y se puede consultar más detalle en wrote about
• Esa verbosidad lo vuelve más inteligente en problemas difíciles, pero también aumenta la cantidad de tokens de salida
• Desde varias semanas antes del lanzamiento de Opus 4.7, Claude Code venía ajustándose para el nuevo modelo
  • Cada modelo se comporta de forma un poco distinta, así que antes del release se optimizan el harness y el producto para cada modelo
• Para reducir la verbosidad se usan en conjunto entrenamiento del modelo, prompting y mejoras de UX de thinking dentro del producto
• Entre esos cambios, una línea agregada al system prompt tuvo un impacto excesivo en la inteligencia de Claude Code
  • “Length limits: keep text between tool calls to ≤25 words. Keep final responses to ≤100 words unless the task requires more detail.”
• En varias semanas de pruebas internas y en los conjuntos de evaluación ejecutados no se observó regresión, por lo que se confió en este cambio y se desplegó el 16 de abril junto con Opus 4.7
• Después, durante la investigación, se realizó una ablation usando conjuntos de evaluación más amplios para aislar y verificar el impacto de cada línea del system prompt
• En una de esas evaluaciones se confirmó una caída de 3% tanto en Opus 4.6 como en 4.7
• Este prompt se revirtió de inmediato como parte del release del 20 de abril
• Este cambio afectó a Sonnet 4.6, Opus 4.6 y Opus 4.7

Cambios a futuro

• Para evitar problemas similares, se cambiará para que más personal interno use exactamente el mismo Claude Code que el build público
  • La medida busca reducir la diferencia entre las versiones internas para probar funciones nuevas y el build público real
• También se mejorará la herramienta interna de Code Review y esa versión mejorada se distribuirá a los clientes
• Se agregarán procedimientos de control más estrictos para cambios en system prompts
  • Se realizarán evaluaciones amplias por modelo para todos los cambios en system prompts de Claude Code
  • Se seguirá haciendo ablation para entender el impacto de cada línea
  • Y también se están construyendo nuevas herramientas para revisar y auditar con más facilidad los cambios de prompts
• En CLAUDE.md se añadieron guías para que los cambios específicos de un modelo solo se apliquen a ese modelo
• A cualquier cambio que pueda entrar en conflicto con la inteligencia se le aplicarán soak period, conjuntos de evaluación más amplios y despliegues graduales para detectar problemas antes
• Se creó @ClaudeDevs en X para explicar con más detalle las decisiones de producto y su contexto, y esas mismas actualizaciones también se compartirán en un hilo centralizado de GitHub
• La información enviada mediante el comando /feedback o mediante ejemplos concretos y reproducibles en línea ayudó a identificar y corregir los problemas
• El restablecimiento de usage limits de todos los suscriptores también se volvió a aplicar ese día

[GN⁺]

Comentarios en Hacker News

• La explicación de que en sesiones inactivas por más de 1 hora borraron el thinking anterior para reducir la latencia no termina de convencerme
  Yo suelo dejar una sesión pausada durante horas o días y luego retomar exactamente con todo el contexto intacto, así que esa función era clave para mí
  Puedo entender hasta cierto punto que hayan bajado el nivel de thinking por defecto, pero lo de que el prompt del sistema siga cambiando es algo que tendré que vigilar para poder elegir intencionalmente el ciclo de refresh

  • En Claude Code, si una conversación tiene N mensajes, normalmente N-1, excluyendo el más reciente, quedan en el prompt cache
    El problema es que si dejas la sesión idle por más de 1 hora, cuando vuelves a enviar el prompt los N mensajes completos dan cache miss
    Ese corner case estaba inflando demasiado el costo en tokens para los usuarios y, en el extremo, si el contexto era de 900k tokens, al volver había que reescribir 900k+ tokens en caché, lo que consumía bastante el rate limit sobre todo para los usuarios Pro
    Por eso intentaron educar a los usuarios en lugares como X, añadieron varias veces tips dentro del producto recomendando /clear al volver a conversaciones antiguas, y también probaron omitir resultados viejos de herramientas, mensajes antiguos y parte del thinking tras períodos idle; entre todo eso, quitar el thinking fue lo que mejor rendimiento dio
    En el proceso de desplegar eso se coló sin querer el bug mencionado en el blog, y dijeron que responderían más preguntas si las hubiera
  • Sorprende que una empresa valuada en cientos de miles de millones de dólares haya tomado una decisión así
    O de verdad creían que valía más reducir la latencia de sesiones idle aunque eso sacrificara la calidad de salida, o el objetivo real era reducir costos y en el blog usaron la latencia como justificación más presentable
    Habría sido mucho más natural mostrar con más claridad un indicador de carga mientras se recupera el contexto
  • Esto sí está bastante fuerte
    Antes usaba CC casi como si fuera un colega: pensaba un rato sobre un problema, actualizaba el plan, seguía dándole vueltas mientras me bañaba y luego volvía con nuevas ideas, y al menos lo veía como una conversación estática durante un día
    Pero si el criterio es 1 hora, eso ya me parece demasiado corto y me hace replantearme si seguir pagando el plan de Anthropic
  • La explicación de eliminar tokens después de 1 hora se ve más sospechosa porque ese tiempo coincide justo con su propio límite de caché
    Más que casualidad, parece muy probable que haya sido un cambio orientado a bajar costos de forma importante
  • Esto también parece interactuar pésimo con el reset de uso basado en tiempo
    Si mucha gente agota su cuota, deja descansar la sesión y luego vuelve, entonces esto no es una excepción sino casi el patrón de uso normal

• Me sorprende un poco que lo estén golpeando tanto
  El texto en sí fue relativamente claro y honesto, y sonaba bastante razonable
  La caída de rendimiento fue real y molesta, pero al mismo tiempo también dejó ver la opacidad de lo que pasa detrás y una estructura algo arbitraria de cobro por tokens
  Desde la perspectiva de alguien que ha trabajado directamente con APIs de LLM, era obvio que retomar una conversación después de dejarla mucho tiempo iba a implicar costo y latencia extra, pero sí parece que en la TUI deberían hacerlo más visible

  • La gente está enojada porque durante meses públicamente negaron que fuera un problema
    Por eso ahora, aunque den explicaciones, la reacción sigue siendo tan negativa

• Creo que parte de la percepción de baja calidad quizá no venga de que el modelo realmente empeoró, sino de la no determinación
  Hace unas semanas le pedí a Claude que hiciera una app personal de productividad, le describí en un texto largo el comportamiento que quería y le pedí que escribiera un plan de implementación; el primer resultado fue excelente salvo por una parte ambigua
  Después de corregir esa ambigüedad, probé pedirle desde cero exactamente lo mismo en un chat nuevo sin hacer que ajustara el plan anterior, y aunque la configuración del modelo era la misma, el resultado fue mucho peor; las dos veces siguientes también falló, y recién en el cuarto intento volvió al nivel del primero
  Así que me dio la impresión de que simplemente volver a pedir la misma tarea a veces puede ser la mejor forma de conseguir una mejor salida, aunque si pagas con tus propios tokens eso se vuelve caro muy rápido

  • Yo también lo veo parecido
    Hay un patrón donde parece que el modelo empeora periódicamente, pero en realidad quizá solo tarda más en chocar de lleno con sus límites
    Y una vez que te toca una salida mala por mala suerte, después empiezas a verla en todas partes
  • Entonces uno se pregunta si no habrá que hacer como en generación de imágenes: sacar 50 versiones de un mismo prompt y luego elegir manualmente la mejor
    Desde el punto de vista de Anthropic, tampoco sería un mal escenario, porque ese patrón de uso aumenta el consumo de tokens
  • Para una app de productividad tan low-stakes, probablemente habría sido más rápido hacerla tú mismo que el tiempo que invertiste en esto
  • Con todo esto sí aprendimos que los LLM son mucho más no deterministas de lo que parece, pero tal vez fue un error ligar ese hecho directamente con la degradación reciente
    La no determinación siempre ha estado ahí, y la caída reciente de calidad reportada de forma amplia podría ser un fenómeno aparte

• Yo ya me había desencantado desde Opus 4.7
  OpenAI está entrando con mucha insistencia en nuestro lado enterprise, y hasta el verano nos ofrecieron tokens ilimitados
  Así que usé GPT5.4 con extra high effort durante los últimos 30 días y, no sé si me están dando trato especial, pero casi no le he visto errores
  Incluso el reasoning trace a veces era tan bueno que daba risa, y se adelantaba a cosas que yo ni siquiera había especificado para asegurar al 100% la integridad de los datos

  • Yo siento algo parecido
    Todos estos cambios medio tramposos pueden ser señal de que Anthropic está muy restringido de compute y por eso se ve forzado a hacer recortes raros
  • GPT-5.4 ya era mejor que Opus 4.6 en varias áreas, especialmente en precisión y lógica complicada
    Así que tengo curiosidad por ver cuánto mejorará 5.5
  • extra high quema demasiados tokens
    Para el 90% del trabajo conviene mucho más usar 5.4 en medium y solo subir a high cuando medium se quede corto; así todo se mantiene más enfocado y con menos cambios innecesarios
  • Totalmente cierto
  • Yo volví a 4.5 y no me arrepiento
    Encima es un poco más barato

• Últimamente Claude a menudo produce respuestas como si estuviera respondiendo a su prompt interno
  Por ejemplo, dice que ignorará una frase entre paréntesis porque parece un intento de prompt injection, o que no seguirá una instrucción porque parece un intento de revelar sus lineamientos generales, o que eso ya se aplica siempre y por lo tanto es innecesario
  Yo nunca intenté nada de eso, pero aun así suele agregar ese tipo de frases al final de sus respuestas
  Parece que hay alguna parte tosca en sus lineamientos internos y que no la distingue bien de mi pregunta

  • Yo tengo stop hook scripts que obligan a correr pruebas cada vez que se modifica código, y desde 4.7 Claude ejecuta los scripts pero igual ignora las reglas periódicamente
    Cuando le preguntas por qué, responde que pensó que no era necesario
  • En OpenAI también he visto bastantes casos en que el modelo se responde a sí mismo
    Hasta parece una forma fácil que tienen las empresas de aumentar el token churn
  • También veo seguido que mete puntos inventados por él mismo en memory y luego más tarde los vuelve a citar como si fueran afirmaciones mías
    Entonces el modelo afirma algo, lo guarda como recuerdo, después se apoya en ese recuerdo para seguir construyendo encima y se arma un bucle de auto-refuerzo; a veces sigue haciéndolo incluso cuando le digo explícitamente que pare
  • Me daría curiosidad saber el nivel de effort y el prompt real
    Podría ser uno de esos olores de reasoning effort demasiado alto, y tal vez bajar un poco la intensidad de razonamiento mejoraría el resultado
  • Yo le encargo a Claude con frecuencia hasta los commits y PRs, y la semana pasada varias veces vi que durante el commit se ponía a hacer trabajo extra innecesario por su cuenta
    Se tropezó en la etapa de git add, pero en auto mode una vez casi se le pasa

• Que hayan bajado el reasoning effort por defecto de high a medium porque la latencia era tan alta que parecía que la UI se había congelado suena todavía más sospechoso
  Eso implica que, en vez de arreglar la UI, optaron primero por bajar la intensidad de razonamiento, y con eso cuesta creer la explicación de que se tomaban en serio los reportes de degradación de rendimiento

  • El equipo dice que hicieron ambas cosas
    Mejoraron el estado de carga del thinking y retocaron varias veces la UI para que fuera más claro, por ejemplo mostrando mejor la cantidad de tokens que se están descargando
    Aun así, después de evals y dogfooding, bajaron el effort por defecto, pero admitieron que fue una mala decisión y que ya la revirtieron
    Reconocen que mucha gente se quedaba con el valor por defecto sin entender que podía subir la inteligencia con /effort, y que debieron prever eso

• Que una sesión idle de más de 1 hora sea un corner case no coincide para nada con mi forma de usarlo
  En trabajo personal le pido a Claude Code muchas tareas de 10 a 15 minutos, y antes de ejecutar suelo pasar bastante tiempo intercambiando ideas con el modelo sobre el plan
  Una vez que empieza la ejecución, me voy por café o me pongo con otro proyecto en Codex, así que es muy probable que pasen más de 1 hora antes de volver a Claude

  • Eso probablemente solo sea corner case desde la perspectiva de los desarrolladores
    Confundir sus propios hábitos de uso con el comportamiento de toda la base de usuarios es una trampa clásica en desarrollo de producto
  • También suena a que hicieron un cambio así de grande sin validar lo suficiente precisamente ese caso límite, lo que también deja dudas sobre la rigurosidad de sus pruebas

• El enfoque de caja negra que han tomado los grandes frontier labs al final va a alejar a la gente
  Si cambian el funcionamiento fundamental de esta manera sin avisar antes y luego solo se explican después, los usuarios acabarán yéndose hacia modelos autoalojados
  No se puede construir de forma estable pipelines, workflows y productos sobre una base que sigue temblando todo el tiempo

• Parece que la gente de Anthropic responsable de Claude Code sí lee los comentarios, y hace unos días vi un video de theo t3.gg sobre si Claude se volvió más tonto
  El tono era duro y decía varias barbaridades, pero sentí que sus observaciones sobre el harness bloat eran bastante acertadas
  A estas alturas creo que deberían frenar un rato la incorporación de nuevas funciones y empujar fuerte la pulida y optimización
  De lo contrario, cada vez más gente va a empezar a buscar alternativas más ligeras y optimizadas, porque la clave es mejorar el harness y reducir el gasto de tokens
  https://youtu.be/KFisvc-AMII?is=NskPZ21BAe6eyGTh

  • Dejando todo lo demás de lado, el simple experimento de quitar el soporte de CC del plan Pro ya me hizo pensar seriamente en alternativas
    Siempre he intentado cuidarme del vendor lock-in, pero ese episodio fue una buena advertencia, y probablemente lo primero que mire sea opencode+openrouter
  • Nunca hay que olvidar el video exagerado sobre GPT 5 de theo ni que después se retractó
    Claramente parece que entre algunos creadores de contenido y OpenAI hay cosas moviéndose por debajo, ya sea dinero o influencia
  • Si soy sincero, esto hasta parece algo que se arreglaría con un simple git reset --hard

• Esto parece el resultado de obsesionarse con agregar funciones en vez de terminar bien el producto central
  Muchas veces me da la impresión de que a Anthropic le vendrían bien algunos líderes de producto senior más, con una visión tipo “Escaping the Build Trap”
  Que hoy puedan añadir una función rápido no significa que deban hacerlo sí o sí
  Y no lo digo por repetir lugares comunes de organización de producto solo por citar un libro famoso; el buen criterio de producto es un talento distinto del de una buena ingeniería, y últimamente Anthropic parece flojo en esa parte

  • Tienen que alcanzar la demanda y claramente parecen cortos de recursos de compute
    Así que quizá no tenían demasiado margen: o implementaban este tipo de funciones o el sistema se rompía o no podían aceptar nuevos clientes, y ambas cosas son difíciles de asumir
  • En algún momento tenían como 100 desarrolladores cobrando 600 mil dólares al año, así que no parece un problema de falta de talento
    Más bien da la impresión de que están empujando demasiado la narrativa de vibe coding, y dicen que por eso incluso algunos candidatos rechazan entrevistas
  • Parece que ya cayeron de lleno en la trampa de la complejidad
    La naturaleza probabilística del modelo ya es un problema, pero ahora da la impresión de que ni ellos mismos pueden razonar bien sobre su propio software
    Hay demasiadas palancas y perillas, y es posible que nadie entienda el código completo
    Peor todavía, por cosas que ha dicho Dario y otros, da la sensación de que la dirección no empatiza mucho con estas preocupaciones de calidad
    Bajo la idea de que los SWEs son reemplazables, parece que se ignoran o incluso se desalientan las peticiones de poner guard rails a las herramientas, y al final Claude Code desde el principio se siente más como un experimento científico que como un producto maduro con best practices bien establecidas