Caída de cuota de Claude Code: ¿Están los agentes creando nuevas 'montañas de código heredado'?

La extensión de la cuota semanal de Claude Code llama la atención; el artículo analiza el mecanismo de consumo de tokens de los agentes. La ejecución prolongada de un agente provoca una expansión constante del conjunto de trabajo, acumulando estado histórico en cada paso, y dado que incluso tras un acierto en caché sigue ocupando contexto, el costo de cálculo crece de forma acumulativa. Limpiar en exceso provoca “fallas semánticas”, obligando al agente a recuperar información nuevamente. El artículo señala que esta inconsistencia entre el estado del código y la precisión de almacenamiento del estado de diseño puede llevar a que la IA genere “código heredado”: agentes posteriores no comprenden las causas y efectos del diseño del código inicial, terminando por formar código complejo con colas, contornos y reintentos que se compensan mutuamente.

Autor y fuente del artículo: Leifeng.com

El código fue escrito realmente por un agente, pero los agentes posteriores ya no saben por qué el agente anterior lo escribió así.

La bonificación del 50 % en el cupo semanal de Claude Code, originalmente programada para finalizar el 19 de agosto, ha sido extendida por Anthropic hasta el 31 de agosto. Justo alrededor de la fecha límite original, en Hacker News surgió una discusión sobre el costo de uso de Claude Code: muchos descubrieron que una tarea no muy compleja, tras varias ejecuciones del Agente, agota rápidamente el cupo.

El problema es que Claude Code no solo consume las pocas líneas de código generadas al final. Leer archivos, buscar cadenas de llamadas, ejecutar pruebas y procesar registros, cada paso continúa agregando al contexto posterior. Cuanto más larga sea la tarea, más pesado será el historial que lleva el agente, y más dependiente será el sistema de la limpieza y la compresión.

El código puede permanecer completamente en el repositorio, pero las razones originales de diseño pueden volverse cada vez más difusas durante la compresión. Así, el consumo de tokens y el código caótico comienzan a converger en el mismo lugar.

Los límites de cálculo del Chat coding normal son claros. Se ingresa un fragmento de código, el modelo lo lee y proporciona una explicación o una propuesta de modificación, y ese ciclo termina básicamente.

La unidad básica de Claude Code se ha cambiado por un ciclo de agente. El modelo primero observa el estado actual, decide qué archivo leer o qué comando ejecutar a continuación; después de que la herramienta devuelva el resultado, el modelo realiza otra ronda de evaluación.

Leer el código fuente, buscar referencias, ejecutar pruebas, revisar el Git diff y modificar archivos parece un solo proceso continuo, pero en el lado del modelo en realidad es una serie de solicitudes de inferencia independientes. La documentación oficial de Claude Code también presenta este ciclo de “el modelo evalúa — llama a una herramienta — y basado en el resultado continúa evaluando” como el núcleo del funcionamiento del agente.

Por ejemplo, un problema ocasional de pérdida de sesión. El agente primero encuentra el punto de entrada, descubre que el estado proviene del servicio, por lo que continúa revisando el servicio; al ver la caché, busca quién la escribe; luego ejecuta pruebas, las cuales revelan otra anomalía, así que revisa el fixture; tras solucionarlo, vuelve a verificar y la prueba antigua vuelve a revelar un problema de compatibilidad.

Quizás hasta entonces comenzó realmente a escribir esas líneas de código. Por lo tanto,diff no existe una proporción estable entre el tamaño y la cantidad de cálculo. Detrás de 5 líneas de parche podrían haber solo 3 inferencias, o bien ya haber pasado por 30 interacciones con herramientas.

Si se desglosa una tarea de Agent, se pueden obtener dos variables: una es el recuento de pasos, es decir, cuántos pasos dio el Agent para completar la tarea; la otra es el conjunto de trabajo, es decir, cuántos elementos del estado aún necesita conocer el modelo al llegar a este paso.

Solo aumentar el recuento de pasos ya mejora el consumo. Si el conjunto de trabajo sigue creciendo en sincronización, la situación es completamente diferente. El paso 3 quizás solo necesite procesar miles de tokens, pero el paso 30 ya podría estar cargando las reglas del proyecto, el código fuente relacionado, los resultados de prueba, el historial de modificaciones y las herramientas para continuar razonando.

Este es también el punto de partida en el que la estructura de costos del Coding Agent cambia: la cantidad de cálculo comienza a depender de “cuántos pasos se dan × cuánto peso lleva cada paso”, y ya no de cuántas líneas de código se escriben.

Dividir una solicitud de modelo del Agente puede verse aproximadamente como tres partes. Las partes relativamente estables incluyen el prompt del sistema, CLAUDE.md, las definiciones de herramientas y las reglas del proyecto; las partes en constante cambio incluyen archivos de código, resultados de búsqueda, registros de pruebas, Git diff y la trayectoria de tareas anteriores; finalmente, hay el razonamiento, el texto y el código generados en este ciclo del modelo.

Aquí surge un malentendido común: si ya se ha leído el contenido anterior, no debería generarse un costo excesivo nuevamente. El problema es que entre dos solicitudes de LLM no existe una memoria interna accesible en todo momento, como en un programa tradicional. Si la información conocida en el ciclo anterior sigue siendo necesaria para la decisión del ciclo siguiente, su estado debe seguir estando presente en el contexto disponible.

La caché de prompt puede aliviar este problema. La documentación oficial de Claude Code especifica claramente que, sin caché de prompt, cada solicitud requiere procesar nuevamente todo el historial; tras un acierto en la caché, los prefijos estables ya procesados pueden reutilizarse, reduciendo así los cálculos repetitivos y los costos.

Pero el cache resuelve “si se puede reutilizar el mismo historial a un costo menor”, pero no resuelve “si este historial aún debe seguir existiendo”. Después de que el estado anterior de 100K Token dé un acierto en el cache y se vuelva más económico, sigue ocupando contexto y sigue siendo el estado sobre el cual se construye la inferencia actual.

Entonces, se puede escribir aproximadamente una tarea larga como: la escala de entrada en el paso t es aproximadamente igual al prefijo estable S, más el conjunto de trabajo activo actual W_t, más la nueva información generada en este ciclo Δ_t.

Lo realmente problemático es W_t. Si en cada paso, el agente lee un poco más de código fuente, obtiene un poco más de registro y deja una decisión más, y la información antigua no se elimina a tiempo, entonces W_t aumentará continuamente a medida que avance la tarea.

En un modelo extremadamente simplificado, sin caché ni limpieza alguna, si cada ronda agrega aproximadamente la misma cantidad de estados válidos, el volumen total procesado presentará una estructura acumulativa cercana a 1 + 2 + 3 + … + n. Es decir, si el recuento de pasos se duplica, el historial de estados procesados por toda la tarea podría aumentar más rápidamente.

El sistema real tiene cache, edición de contexto y compactación, y no sigue mecánicamente esta curva de crecimiento, pero la forma del problema no cambia: cuanto más tiempo ejecute el agente, más probable es que cada nuevo movimiento se base en un historial más pesado.

Por lo tanto, el breve prompt del usuario dentro de la tarea larga perderá rápidamente su relevancia. Lo que realmente comenzará a dominar los costos es el conjunto de trabajo que el modelo lleva constantemente para mantener la continuidad de la tarea.

¿Por qué se infla tanto el conjunto de trabajo? La salida de la herramienta es una fuente importante. El código fuente al menos tiene estructura, pero los registros a menudo no la tienen.

Una grep puede devolver cientos de referencias, una compilación puede generar grandes cantidades de advertencias, un fallo en la prueba puede incluir un rastro completo, y Docker, los compiladores y los gestores de paquetes también generan grandes cantidades de texto sin valor a largo plazo para la tarea.

Supongamos que la prueba en el paso 10 generó un registro de 8K tokens. Cuando entró por primera vez en el contexto, era solo de 8K tokens. Sin embargo, el agente aún debe continuar verificando el código fuente, realizando modificaciones y volviendo a probar; siempre que este registro permanezca en el historial válido, aumentará el peso base de muchas solicitudes posteriores.

Es similar al write amplification en los sistemas de almacenamiento: una escritura lógica genera más procesamiento subyacente posterior. En el caso del agente, una salida de herramienta se escribe en el historial de ejecución y luego se mueve junto con la inferencia posterior.

Por lo tanto, el mismo token de 8K, cuando se coloca en el último ciclo antes del final de la tarea o al inicio de la tarea, produce un impacto total completamente diferente. Claude Code ahora también reduce activamente esta contaminación. La recomendación oficial es utilizar sub-agentes para aislar tareas de alta salida y menciona explícitamente que los resultados de búsqueda, los registros y el contenido de muchos archivos consumen el contexto de la sesión principal; la definición de las herramientas también ocupa espacio, por lo que un conjunto de herramientas demasiado grande aumenta la carga de estado.

Pero aquí surge otro problema en dirección opuesta: no se pueden eliminar todos los registros solo porque son costosos. En un registro de 3000 líneas, solo 20 líneas podrían estar relacionadas con la causa raíz. El sistema no sabe de antemano cuáles son esas 20 líneas. Si se limpia demasiado pronto, el agente podría necesitar más adelante uno de esos detalles y solo podría volver a ejecutar la prueba o volver a abrir el archivo.

Esto puede llamarse fallo de página semántica. En la memoria virtual tradicional, cuando un programa accede a una página que ya no está en memoria, el sistema vuelve a cargarla desde el disco; después de descartar ciertas pruebas tempranas, el Agente de Codificación también experimenta un fenómeno similar, aunque se manifiesta como una nueva búsqueda en el repositorio, lectura repetida de archivos, ejecución nuevamente de comandos, e incluso la rederivación de un problema ya analizado anteriormente.

Entonces, la tarea larga cae en un dilema: dejar demasiado historial hace que cada paso posterior se vuelva cada vez más pesado; limpiar demasiado agresivamente hace que el agente vuelva a obtener constantemente información que ya ha visto antes.

Esto también explica por qué la gestión del contexto no se puede simplificar como “insertar menos tokens”. Lo que realmente necesita resolverse es la selección del conjunto de trabajo: ¿qué información debe permanecer en el área de trabajo en este momento y qué es solo un producto intermedio que ya cumplió su función?

Aquí es donde compaction, memory y sub-agent adquieren realmente su razón de ser.

Cuando Claude Code se acerca al límite de contexto, comprime automáticamente la sesión y también limpia algunos resultados de herramientas más antiguos. La oficial también advierte que las conversaciones irrelevantes, el contenido de archivos y los resultados de comandos dentro de sesiones largas pueden llenar la ventana e interferir con el rendimiento del modelo.

Desde el punto de vista del sistema, la compactación es muy similar a una recolección de basura semántica. El problema radica en que la recolección de basura normal determina si “este objeto aún tiene referencias”, mientras que el Agente debe determinar si “esta información tendrá algún significado en el futuro”.

El segundo es mucho más difícil. Por ejemplo, en las etapas iniciales se llegó a la siguiente conclusión de diseño: un módulo no puede almacenar en caché el estado del usuario por sí mismo, ya que el sistema requiere que el estado tenga un único propietario y que todos los cambios deban pasar por el servicio.

Después de varios pasos, si esta información se resumen como: "El problema de estado se resolvió previamente mediante el servicio." El hecho no es incorrecto, pero la información ha cambiado. El contenido original contenía una restricción, mientras que el resumen posterior solo conserva el evento.

La próxima vez que el agente encuentre un problema de rendimiento y vea que las llamadas al servicio son lentas, probablemente agregue otra caché en el módulo. No está violando la información que actualmente posee; la relación causal que prohibía la caché ya no está vigente.

El documento de contexto de Claude Code indica explícitamente que algunas reglas con alcance de ruta y los CLAUDE.md anidados se resumen y comprimen junto con la sesión, y deben volver a leerse para volver a cargar los archivos coincidentes.

Memory busca resolver el problema de la conservación a largo plazo del conocimiento. Los archivos CLAUDE.md y auto memory en el directorio raíz pueden extraer contenidos como comandos de construcción, especificaciones del proyecto y experiencias de depuración de las conversaciones a corto plazo y volver a cargarlos al inicio de la sesión. Sin embargo, Anthropic también especifica claramente: estos memory siguen siendo contextos, no configuraciones obligatorias.

Esta diferencia es fundamental. Si "no se puede acceder directamente a la base de datos aquí" solo se escribe en la memoria, sigue siendo un lenguaje natural que el modelo debe comprender y seguir. Solo cuando esta misma regla se implementa como una verificación de dependencias, una restricción de tipo o una comprobación de CI, se convierte en un invariant de software que no se puede eludir fácilmente.

El sub-agente aborda otro aspecto: la isolación del conjunto de trabajo. Delegar a un agente independiente la tarea de escanear un repositorio o analizar registros largos, y luego devolver al agente principal un resultado comprimido, evita que el ruido original ingrese al hilo principal. Uno de los usos oficiales del sub-agente en Claude Code es la isolación de contexto.

Su costo también es interesante: el agente principal obtuvo un estado más limpio, pero perdió parte de la evidencia original; al ejecutarse múltiples agentes simultáneamente, se establecen sus propios contextos. Por lo tanto, al ver juntos compaction, memory y sub-agent, ya se parecen mucho a una jerarquía de memoria de la era de los agentes:

El contexto actual es memoria de trabajo costosa, la compactación se encarga de comprimir, la memoria guarda el estado entre sesiones y los sub-agentes utilizan espacios de dirección independientes para aislar el ruido. El problema también ha pasado de “si el contexto es lo suficientemente grande” a otro nivel:

¿Qué estados requieren conservación de alta fidelidad y qué estados solo necesitan un resumen? Esta pregunta afectará directamente la calidad del código posterior.

Después de comprender la estructura de ejecución anterior, al revisar el límite semanal de Claude Code, se observa que es difícil para la plataforma continuar midiendo el Agente por "número de mensajes", ya que un mensaje ha perdido su significado estable.

Cambiar el nombre de una variable es un mensaje; reestructurar todo el módulo de autenticación también es un mensaje. El primero puede terminar en unos pocos pasos, mientras que el segundo puede ejecutarse durante decenas de rondas, leer decenas de archivos y arrancar múltiples Agentes. El mismo request puede tener necesidades de recursos completamente desiguales detrás.

Claude Code empaqueta esto con límites de desplazamiento y cuotas semanales; Codex ahora calcula los créditos claramente según tokens de entrada, tokens de entrada en caché y tokens de salida; los planes de Cursor proporcionan diferentes grupos de uso para el Agente, y el consumo de modelos de terceros está sujeto al precio de la API del modelo.

Los idiomas de las interfaces de tres productos son diferentes, pero los problemas subyacentes que necesitan resolverse son muy similares: cómo asignar recursos de razonamiento a un programa inteligente cuya ruta de ejecución no se puede determinar de antemano. Es difícil saber cuánto tiempo tardará un Coding Agent en completarse al inicio de la tarea.

El modelo puede encontrar rápidamente la causa raíz o plantear varias suposiciones erróneas consecutivas; puede aprobarse en una sola prueba o entrar en un bucle de depuración prolongado; puede necesitar solo un agente o dividirse en múltiples sub-agentes.

Las API tradicionales prefieren cobrar por solicitud, porque la fluctuación de recursos de una sola solicitud aún puede controlarse dentro de un rango determinado. El agente dispersa esta estabilidad. Por eso, el token aquí comienza a tener un matiz de tiempo de CPU.

Esta analogía no puede equipararse. Los distintos modelos tienen diferentes costos de cálculo para procesar la misma cantidad de tokens, y los costos varían entre input, input en caché y output. Pero desde el punto de vista del desarrollador, sus funciones se vuelven cada vez más similares: todas describen cuántos recursos de cómputo se consumen para continuar ejecutando una tarea.

Cuando Anthropic aumentó el límite de uso de Claude Code este año, también vinculó directamente el aumento de cuota con la adición de capacidad de cómputo. Esto generará un cambio interesante en un indicador. Anteriormente, al evaluar a los Agentes de Codificación, era común comparar “¿quién resuelve mejor un problema en un solo intento?”. En el futuro, puede ser más significativo: ¿quién consume menos cómputo efectivo para lograr el mismo cambio de estado del proyecto?

Si un agente gasta una gran cantidad de tokens solo para abrir archivos repetidamente, volver a ejecutar pruebas y recuperar contextos ya perdidos, esos tokens no se traducen en un avance de ingeniería proporcional.

Y este tipo de recuperación ineficiente恰好与技术债务在下一层相遇。

Here, software maintained by a Coding Agent can be abstracted into two simultaneously evolving states. One is the code state R_t. Files, types, interfaces, tests, and Git commits all belong to this layer. A line added by the Agent at step 20, retry, remains fully intact when opening the file at step 100, as long as it hasn't been deleted. The code preserves historical modifications with very high precision.

Otro conjunto es el estado de diseño M_t. ¿Por qué se necesita aquí retry, ¿por qué esa caché solo puede estar en el servicio, ¿por qué este estado no puede tener dos propietarios, ¿por qué esta aparente verificación redundante no se puede eliminar temporalmente? Estos detalles pertenecen a la causalidad del diseño.

M_t No hay un almacenamiento intrínsecamente sin pérdidas como Git. Está distribuido en conversaciones, razonamiento, respuestas de herramientas, memoria, archivos de reglas y resúmenes de compactación. A medida que avanzan las tareas, parte del contenido se elimina, parte se resumen y parte necesita ser recuperada nuevamente.

Por lo tanto, se genera una asimetría muy crítica: los resultados alcanzados pueden acumularse con alta fidelidad, pero las relaciones causales que generan estos resultados se muestrean continuamente a menor resolución. Esto es mucho más grave que simplemente decir que “el agente olvida cosas”.

En caso de un problema de concurrencia, tras el análisis del agente, se añadió una cola. En ese momento, la conclusión completa que poseía era: solo la ruta de escritura A presentaba competencia, por lo que la cola solo podía abarcar A; la ruta de escritura B requiere baja latencia y no puede ingresar a esta cola.

El código guardó completamente la cola. Después de una larga ejecución, el estado del diseño podría reducirse solo a “aquí se usa la cola para resolver la condición de carrera”.

Luego, B también presentó un error ocasional. Cuando el agente volvió a leer el código, integró naturalmente B en la cola existente.

Luego, el retraso aumentó, así que se añadió un bypass. El bypass generó inconsistencias de estado ocasionales, por lo que se agregó un retry externo. En este punto, ninguna de las modificaciones era necesariamente absurda; cada parche, en el contexto local visible en ese momento, incluso podía parecer razonable. Sin embargo, el código ya había pasado de ser “un modelo de concurrencia claro” a convertirse en una red de queue, bypass y retry que se compensan entre sí.

El montón de código de IA probablemente se forma así. No necesariamente se manifiesta como que el modelo de repente escriba un montón de basura, sino más bien como la acumulación continua de partes correctas, mientras que el modelo global poco a poco desaparece.

En los software tradicionales, este tipo de problemas suelen surgir gradualmente a través de la transferencia de personal. Cuando el autor original se va, los nuevos desarrolladores ven el código antiguo pero no saben por qué existe, por lo que añaden una capa adicional de lógica de compatibilidad.

El agente de codificación convirtió "transferencia de personal" en "transferencia de contexto". Los pasos 20 y 100 parecen seguir siendo la misma sesión de Claude Code, pero los estados de diseño que obtuvieron ya no son completamente iguales. Desde el punto de vista de la información, es más como dos ingenieros que mantienen el mismo repositorio a través de un documento de transferencia que se reduce constantemente.

Las pruebas solo pueden abordar una parte de esto. Las pruebas son buenas para proteger el comportamiento: la interfaz debería devolver qué, ciertas entradas no deben provocar un fallo, y los errores pasados no deben reaparecer. Muchas restricciones de arquitectura no se expresan naturalmente como entradas y salidas.

Solo puede haber un propietario para el estado, la capa de dominio no puede depender en sentido inverso de la IU, un paquete determinado no puede conectarse directamente a la base de datos, y todas las operaciones de escritura deben pasar por un límite de transacción unificado; si estas restricciones solo existen en documentos o en la memoria del agente, es fácil que se pasen por alto durante reparaciones locales.

Resulta en un estado de ingeniería muy problemático: las pruebas aún están verdes, pero el código se vuelve cada vez más difícil de explicar. Lo aún más peligroso es que existe un bucle de retroalimentación.

La arquitectura comienza a volverse caótica; el próximo agente que entienda la función necesitará leer más archivos; cuanto más enredadas sean las dependencias, mayor será el conjunto de trabajo; cuanto más pesado sea el conjunto de trabajo, más necesario será limpiar y comprimir el sistema; cuanto más delgada sea la conservación de la causalidad del diseño, más fácil será que las modificaciones posteriores dependan del código actual y de pruebas locales.

Entonces, la complejidad del código comienza a aumentar el costo de los tokens, y la presión sobre los tokens a su vez fomenta la retención de estados más cortos y parches más locales. Este es el mecanismo más preocupante detrás de “cuanto más iteras, más problemas aparecen” en la programación de Agentes.

No es un problema de capacidad de un modelo individual, sino un problema del sistema debido a una inconsistencia en la precisión del estado del código y el estado del diseño.

El Agente de Codificación ya puede actuar durante períodos más largos, pero "poder ejecutarse durante varias horas" en sí mismo no necesariamente es un buen indicador de capacidad.

Si un agente trabaja durante 3 horas y luego necesita volver a leer un archivo que modificó hace 2 horas, volver a razonar por qué existe cierta abstracción y volver a ejecutar una prueba que ya había ejecutado anteriormente, entonces gran parte del cálculo durante esas 3 horas se dedica a la recuperación del estado.

La pregunta siguiente será: ¿cuánta información causal valiosa para las decisiones posteriores conservará un agente después de 50 pasos, 100 pasos?

Puedes llamarlo tasa de fidelidad del estado.

Porque no mide cuántos tokens caben en el contexto, sino cuánta información clave del diseño sigue existiendo en forma utilizable después de la invocación de herramientas, la compresión, la transmisión entre sesiones y la recuperación de memoria. Esto también significa que la memoria a largo plazo del agente no puede depender únicamente de un contexto más largo.

Algunos conocimientos son adecuados para almacenarse en la memoria, como la forma de construir proyectos y los hábitos de desarrollo; algunas decisiones deben registrarse en ADR estructurados o índices de código; y aquellas que, si se violan, romperían los límites arquitectónicos del sistema, son más adecuadas para escribirse directamente en tipos, pruebas, reglas de lint, dependencias y CI.

Si una regla se ha convertido en una restricción ejecutable por software, el agente no necesita "recordarla". En el siguiente turno, el agente puede olvidar un fragmento de la conversación, pero no puede saltar fácilmente el compilador y las pruebas.

Si la tasa de fidelidad es baja, cuanto más tiempo funcione el agente, más minas ocultas está colocando en el sistema.

Esto también podría ser la línea que el Coding Agent debe atravesar para pasar de “saber escribir código” a “poder mantener software a largo plazo”: migrar el conocimiento de diseño desde la memoria lingüística probabilística hacia un estado de software que sea recuperable, verificable y ejecutable.

De lo contrario, cuanto más tiempo funcione de forma autónoma, surgirá una escena muy absurda: el agente escribe código cada vez más rápido, y el proyecto cambia rápidamente, pero cada cierto tiempo, debe volver a comprender el mundo dejado por el período anterior.

Una frase común en el código heredado es: "No toques esto, no sé por qué explota."

El código heredado de IA podría ser aún más extraño: el código realmente fue escrito por un Agente, pero los Agentes posteriores ya no saben por qué el Agente anterior lo escribió así.