El modelo Claude de Anthropic enfrenta desafíos técnicos en la generación de código y la confiabilidad de agentes

Anthropic recientemente ha enfrentado múltiples desafíos técnicos con los modelos Claude. La generación de código ha visto reducida su libertad debido a restricciones de inserción de marcas de agua; el mecanismo de pensamiento adaptativo de Sonnet 5 permite ajustar diferentes niveles de inversión computacional dentro del mismo modelo, difuminando los límites de capacidad entre líneas de productos; aunque el contexto de 1M parece abundante, en sesiones largas de Agentes, el modelo solo puede utilizar eficazmente alrededor del 20%-30% del contexto, tras lo cual ocurren confusión de estado y omisiones; durante la compresión del contexto, es difícil distinguir qué información sigue siendo válida, y las suposiciones temporales pueden ser malinterpretadas como hechos; tras que el Agente modifique activamente el entorno, el modelo comienza a analizar los nuevos errores que él mismo creó en lugar del problema original. El artículo señala que la confiabilidad de los Agentes largos depende cada vez más de la claridad del estado, la verificabilidad de las acciones y la capacidad de reversión de errores, en lugar del rendimiento individual del modelo en un solo paso.

Autor y fuente del artículo: Leiphone

Lo que es más problemático que una caída en la puntuación del modelo es que el modelo aún esté en actualización, pero los usuarios comiencen a sentir que se vuelve cada vez menos útil.

Anthropic últimamente tiene un poco de ese sabor.

En estos días, un publicación en X reunió varias quejas típicas de Claude durante este período: los textos y el código comienzan a incluir marcas legibles por máquina, la experiencia real con Sonnet 5 no ha seguido el ritmo del entusiasmo generado por la actualización del modelo, Fable 5 se vende a un precio más alto, pero es difícil percibir claramente en qué supera a Opus 5; además, hay un comentario aún más preocupante: el contexto de Fable 5 solo se utiliza alrededor del 20%–30%, y después su capacidad comienza a disminuir.

Estas cuatro cosas parecen no tener relación aparente: una parece un problema de mecanismo de generación, otra un problema de capacidad del modelo, una tercera un problema de fijación de precios, y la última parece un fallo en el contexto largo.

Pero desde la perspectiva de la pila tecnológica actual de Claude, en realidad se atascan en 5 posiciones muy específicas: cómo genera el modelo, cuánto cálculo está dispuesto a gastar durante la inferencia, por qué los modelos diferentes se vuelven cada vez más difíciles de jerarquizar, por qué el contexto largo empieza a fallar antes de llenarse, y por qué las capacidades en los experimentos a menudo se reducen en tareas reales de Agentes.

Entonces, el problema reciente de Anthropic probablemente no es simplemente un “retroceso del modelo”. Es más bien que, a medida que Claude se vuelve más potente, la generación, el cálculo, el contexto y el tiempo de ejecución del Agente comienzan a obstaculizarse mutuamente.

01

Las marcas legibles por máquina se colocan dentro del texto normal; el desafío técnico consiste en mantener señales estables sin alterar significativamente la calidad de generación. Al pasar al código, este problema se vuelve notablemente más difícil, ya que la distribución de tokens en lenguaje natural y en código no es la misma.

Paper: https://arxiv.org/pdf/2301.10226

El lenguaje natural a menudo presenta múltiples candidatos con significados similares. La misma idea puede expresarse con palabras diferentes o con un orden modificado, y el modelo tiene cierta redundancia de generación en muchas posiciones. Una de las ideas comunes en el marcado de texto consiste en aprovechar esta redundancia, alterando ligeramente la probabilidad de muestreo entre varios tokens aceptables, hasta acumular suficientemente una regularidad estadística.

El código tiene numerosas posiciones de baja entropía. Después de la declaración de variables, las referencias posteriores solo pueden usar el mismo nombre; los campos, comillas y paréntesis de JSON están sujetos a restricciones estructurales estrictas; los parámetros de función deben cumplir con la interfaz; en rutas, expresiones regulares, SQL y comandos Shell, un solo token que cambie puede alterar directamente el comportamiento.

Desde la distribución de probabilidad, estas posiciones suelen ser muy afiladas. El token correcto ocupa una alta probabilidad, mientras que los otros candidatos no son simplemente otra expresión, sino que podrían ser errores. Por lo tanto, la limitación principal que enfrenta el agua de código es realmente la capacidad de codificación.

Si una posición solo tiene una salida razonable, casi no tiene espacio para cargar señales adicionales; si el sistema solo incrusta marcas en posiciones de alta entropía, enfrenta problemas de códigos cortos, alta proporción de tokens estructurados y insuficiencia de posiciones utilizables.

Por lo tanto, se establece un compromiso directo entre la intensidad de la detección, la calidad de generación y la resistencia a la modificación: una señal demasiado débil es difícil de detectar, restricciones demasiado fuertes pueden afectar la generación correcta, y conservar la capacidad de detección tras la formateación o reescritura parcial requiere una mayor redundancia de la señal.

Anthropic no ha revelado cómo cambian exactamente las marcas de texto de Claude el muestreo, por lo que no se puede atribuir directamente el cambio en la calidad de Claude Code a un algoritmo de marca de agua específico.

Lo que se puede determinar aquí es otro cambio: la generación de código está asumiendo simultáneamente cada vez más restricciones. Además de la corrección semántica y de ejecución, puede necesitar cumplir con protocolos de herramientas, formatos estructurados, reglas de seguridad y marcas de origen, y la libertad que el propio código tiene para absorber estas restricciones adicionales es mucho menor que la del lenguaje natural.

02

Los cambios traídos por el pensamiento adaptativo de Sonnet 5 no solo hacen que el modelo piense un poco más.

Anteriormente, al hablar de Sonnet, Opus y Fable, era fácil entenderlos como unos pocos puntos de capacidad fijos. Ahora, con la incorporación de effort, el mismo modelo puede caer dentro de diferentes intervalos de cómputo en tiempo de prueba, y el propio modelo ya no puede representar completamente cuánta capacidad se invirtió en una solicitud.

Enlace de referencia: https://platform.claude.com/docs/en/build-with-claude/effort

Este cambio es especialmente evidente en el Coding Agent. Cuando Claude se enfrenta a un bug, no solo necesita generar una solución de modificación, sino también decidir qué archivos leer, qué cadena de llamadas seguir, cuántas hipótesis candidatas mantener, si ejecutar pruebas, si continuar verificando dependencias y cuándo considerar que la evidencia es suficiente.

Estas acciones pueden verse como un árbol de búsqueda. Una menor inversión computacional implica cortar ramas más temprano y formar juicios más rápidamente; una mayor inversión permite que el modelo continúe buscando y verificando, reduciendo la probabilidad de ejecutar acciones directamente cuando la evidencia es insuficiente.

Enlace de referencia: https://platform.claude.com/docs/en/build-with-claude/effort

Por lo tanto effort no regula simplemente la longitud del thinking, sino el alcance de búsqueda permitido para una tarea de Agent. Esto cambiará directamente la jerarquía del modelo de Anthropic.

If a regular coding task is already easy for Opus, increasing effort will likely cause Opus to quickly enter the performance plateau. Fable, even with a stronger base model, has little remaining difficulty to convert into a noticeable experience gap.

El usuario debe pagar la diferencia de precio desde el inicio de la solicitud. Por lo tanto, Fable es más fácil de valorar cuando se trata de tareas como código desconocido, planificación en múltiples etapas, operaciones entre herramientas, ejecución autónoma prolongada y tareas que requieren recuperación después de un error.

Enlace de referencia: https://www.anthropic.com/news/claude-opus-5

Esto significa que lo que venden los modelos avanzados está cambiando. Ya no solo venden “la respuesta más fuerte en esta ronda”, sino una confiabilidad adicional dentro de una trayectoria más compleja.

El problema es que esta ventaja requiere que la tarea sea lo suficientemente larga para desarrollarse, y una vez que la tarea se alarga, la capacidad del modelo ya no es el único factor determinante, comenzando a ocupar un lugar central el estado del contexto.

03

Ver un contexto de 1M puede hacer que lo interpretes fácilmente como una gran memoria de trabajo, por lo que resulta muy contraintuitivo que Claude comience a omitir, repetir o incluso mostrar confusión de estado al usar solo 200K o 300K tokens.

Pero la ventana de contexto mide capacidad, no coherencia de estado. Una sesión larga del agente no es un documento estático, sino un historial de ejecución en constante expansión.

Enlace de referencia: https://platform.claude.com/docs/en/build-with-claude/context-windows

Un archivo puede ser modificado varias veces en secuencia; un error inicialmente se atribuyó a un problema de caché, pero más tarde se descubrió que provenía de la concurrencia; una prueba puede fallar inicialmente, luego pasar, y volver a fallar debido a nuevos cambios. El contenido antiguo no se elimina automáticamente con los cambios de estado; el nuevo contenido simplemente se agrega al final.

El problema aquí ya no es solo la recuperación. El modelo debe no solo encontrar información relevante para la tarea actual, sino también determinar si dicha información sigue siendo válida en este momento.

Las funciones antiguas y las nuevas son muy similares, y los registros de prueba antiguos y nuevos contienen muchos mismos tokens; los análisis ya descartados también podrían estar semanticamente muy relacionados con el problema actual. El Attention no tiene dificultad para encontrar este contenido, pero sí lo tiene para determinar las relaciones de cobertura entre ellos.

La base de datos puede mantener el estado actual mediante números de versión, tiempos de actualización, transacciones y campos explícitos; el contexto en lenguaje natural generalmente carece de esta estructura. Es más parecido a un registro solo de adición, y el modelo debe reconstruir por sí mismo cómo es el mundo actual a partir del orden de los eventos.

Enlace de referencia: https://platform.claude.com/docs/en/build-with-claude/context-windows

Por lo tanto, la complejidad del contexto largo no corresponde simplemente al porcentaje de tokens ocupados. Un documento estático de 250K tokens puede ser mucho más fácil de procesar que 250K tokens de historial de Agentes, ya que este último contiene una gran cantidad de objetos modificados, juicios provisionales, resultados de herramientas y estados ya inválidos.

El historial de pensamiento aún aumentará esta complejidad. Lo que se guarda en la conversación no solo es “qué sucedió”, sino también posiblemente “por qué se hizo esa evaluación en ese momento”. Si un razonamiento temprano se basó en una suposición que más tarde se refutó, ese razonamiento aún podría participar en juicios posteriores debido a su alta relevancia con la pregunta actual.

Entonces, la verdadera limitación de un contexto de 1M no es solo cuánta información se puede almacenar, sino si el modelo puede seguir recuperando de forma estable la versión actual a medida que aparecen más versiones históricas del mismo objeto.

04

A medida que el contexto continúa creciendo, la compactación parece un enfoque natural: acortar el historial antiguo y continuar ejecutando. Sin embargo, la compactación en escenarios de Agentes no es lo mismo que un resumen común.

Al resumir un artículo, omitir un ejemplo solo afecta la integridad de la información; al comprimir la trayectoria del agente, omitir una restricción aún válida puede cambiar directamente la ruta de ejecución posterior.

Enlace de referencia: https://platform.claude.com/cookbook/tool-use-context-engineering-context-engineering-tools

Debido a que la compactación debe resolver no “qué contenido es importante”, sino “qué contenido aún es válido en este momento”. En un historial pueden coexistir tareas completadas, juicios posteriormente revocados, restricciones de interfaz aún vigentes, resultados de pruebas caducados y soluciones temporales. El compactor necesita reorganizar estos estados temporales en una representación que permita continuar el trabajo en la siguiente ronda.

Si "actualmente se sospecha que el problema proviene de la caché" se reduce a "el problema proviene de la caché", la suposición temporal se convierte en hecho; si una solución ya descartada sigue apareciendo en el resumen, los Agentes posteriores podrían volver a seguir la antigua ruta; si una restricción clave no se incluye en el resumen, el modelo ni siquiera la volverá a ver.

Por lo tanto, el indicador clave de la compactación no es la tasa de compresión, sino la fidelidad del estado. Esta es la razón por la que Git, pruebas, archivos de tareas, memoria y handoff estructurado se vuelven cada vez más importantes en agentes de largo plazo.

No simplemente aumentan la información que el modelo puede ver, sino que transfieren ciertos estados que deben mantenerse a largo plazo desde el historial en lenguaje natural a sistemas externos. Git especifica la versión actual del código, las pruebas proporcionan resultados verificables, los archivos de tareas registran el progreso y el estado estructurado distingue entre conclusiones actuales y intentos históricos.

El contexto puede conservar un historial rico, pero no puede asumir permanentemente la responsabilidad completa de la gestión de estado.

Enlace de referencia: https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents

05

Las preguntas anteriores aún pueden interpretarse como cómo el modelo procesa la entrada. El agente da un paso más allá, ya que modifica activamente el entorno.

En un chat normal, si el modelo se equivoca una vez, el error generalmente permanece en el texto de salida. El agente puede modificar el código, ejecutar comandos, instalar dependencias, ajustar configuraciones y leer los nuevos resultados generados por estas acciones.

Entonces, el error ya no es solo un error de juicio, sino que se convierte en un cambio de entorno. Supongamos que Claude malinterpreta un bug como un problema de caché, por lo que modifica la lógica de caché, el mecanismo de reintento y varios puntos de llamada. Luego, las pruebas generan una nueva serie de excepciones.

Estas anomalías son reales, pero no surgieron naturalmente del error original, sino que fueron generadas por el cambio anterior. Esto hace que el agente entre en un modo de fallo muy específico: el modelo comienza a analizar la distribución de datos que él mismo creó.

Enlace de referencia: https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents

Si puede identificar "estos nuevos errores surgieron después de la última modificación", aún puede revertir y volver a verificar la hipótesis original; si no se establece esta relación causal, es posible que siga tratando los nuevos errores como problemas independientes, reparándolos uno tras otro.

En este momento, cada operación local puede tener una base, pero la trayectoria completa de la tarea ya se ha desviado del problema original. Por lo tanto, la confiabilidad de un agente largo no puede evaluarse solo por la tasa de precisión por paso. Lo más importante es si el sistema puede detectar, atribuir y recuperarse después de que se produzca un error en el entorno.

Git diff puede informar al modelo qué cambios acaban de ocurrir, las pruebas pueden verificar si algún comportamiento se ha alterado, los checkpoint y rollback pueden limitar la propagación de errores, y el evaluator independiente puede proporcionar una validación adicional más allá de la explicación propia del modelo.

La función de estos componentes es, en esencia, dotar al agente de capacidad de corrección en bucle cerrado.

Enlace de referencia: https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents

06

Muchos benchmarks miden: dado un entorno inicializado, ¿puede el modelo completar la tarea? El agente real añade una capa adicional de dificultad: el entorno cambia constantemente según las propias acciones del modelo. Por lo tanto, dos modelos con tasas de finalización similares pueden ofrecer experiencias completamente diferentes en la práctica.

Un modelo puede hacer juicios muy precisos al principio, pero una vez que se equivoca, sigue reparando sobre la misma ruta errónea; otro modelo puede no ser claramente más fuerte en un solo paso, pero puede detectar más rápidamente que un cambio generó un nuevo problema, y luego revertir y elegir una nueva ruta.

Solo mirando el punto final, es difícil distinguir entre estos dos comportamientos. Si la tarea del agente se prolonga aún más, los indicadores más significativos serán cuánto estado clave se conserva después de la compactación, si se puede identificar el paso que introdujo el error después de una modificación errónea, si el estado interno de la tarea sigue siendo coherente con el entorno real a medida que aumentan las llamadas a herramientas, y cuánto costo se requiere para recuperarse tras una desviación.

Estos indicadores no miden cuán inteligente es una sola respuesta, sino si una trayectoria puede mantenerse bajo control.

En resumen, los varios problemas recientemente expuestos por Anthropic se ubican en diferentes niveles. Después de que estos problemas se hayan concentrado, las limitaciones técnicas de Claude también han comenzado a cambiar.

Antes era más una pregunta sobre si el modelo podía resolver un problema específico; ahora lo más difícil es otra cosa: después de que la tarea haya estado en ejecución durante varias horas, haya realizado decenas de llamadas a herramientas, varias compresiones de estado y múltiples modificaciones de código, ¿el sistema aún puede mantener una versión confiable del estado actual del mundo?

La capacidad del modelo sigue creciendo, lo que solo puede elevar el límite de cada juicio. La capacidad de un agente largo para funcionar de manera estable depende cada vez más de otra serie de capacidades: si el estado está claro, si las acciones son verificables y si los errores son reversibles.