La compactación inactiva de Claude Code ahorra caché, pero se reanuda desde un resumen
La compactación inactiva de Claude Code ahora puede resumir una sesión grande antes de que expire su caché de prompts, incluso cuando la ventana de contexto no está llena. La función se dirige, de forma predeterminada, a sesiones que contienen al menos 200.000 tokens. Su principal contraprestación es clara: Claude vuelve a un contexto más económico y breve, pero continúa desde un resumen generado en vez de cada turno original.
La ingeniera de Anthropic Lydia Hallie describió este comportamiento en una publicación sobre compactación inactiva de octubre de 2026. Los usuarios pueden desactivar la función añadiendo "idleCompaction": false a un archivo de configuración de Claude Code. También pueden cambiar el umbral mínimo de contexto con CLAUDE_CODE_IDLE_COMPACT_MIN_TOKENS.
Ese control llegó después de que desarrolladores informaran de compactaciones inesperadas en sesiones de larga duración. Su preocupación no era que existiera la compactación. Claude Code ya resumía conversaciones cerca de sus límites de contexto. El conflicto era si un temporizador de inactividad debía sustituir una transcripción todavía utilizable para reducir el coste de volver después de que expirara la caché.
La compactación inactiva de Claude Code cambia el significado de reanudar
Una sesión reanudada puede conservar su identidad mientras pierde el historial literal que la estableció originalmente.
Claude Code almacena los mensajes de las sesiones localmente y permite reabrirlas con --continue o --resume. Esa persistencia puede hacer que una sesión parezca un espacio de trabajo duradero. Sin embargo, el modelo solo razona sobre el contexto enviado en su solicitud actual, no sobre cada artefacto almacenado en disco.
La guía sobre la ventana de contexto de Anthropic explica que el contexto activo contiene el historial de conversación, contenidos de archivos, salida de comandos, instrucciones del proyecto, memorias, habilidades e instrucciones del sistema. A medida que esos materiales se acumulan, Claude Code elimina la salida más antigua de las herramientas y finalmente resume la conversación.
La compactación es el acto de sustituir material conversacional antiguo por un resumen más breve. La sesión sigue estando disponible y Claude puede continuar trabajando. Sin embargo, el modelo ya no recibe palabra por palabra cada turno sustituido.
La nueva vía inactiva cambia cuándo puede producirse esa sustitución. La compactación automática tradicional responde a un presupuesto de contexto cada vez menor. En cambio, la compactación inactiva responde a la inactividad y al momento de la caché de prompts, siempre que la sesión sea lo suficientemente grande.
Los usuarios empezaron a informar del mensaje «Compacted while idle, before the prompt cache expired» después de dejar sesiones sin supervisión. Los informes asociaron el despliegue con Claude Code 2.1.286, aunque el comportamiento estaba controlado en parte mediante una puerta de activación del lado del servidor. Eso significa que instalar una versión concreta del cliente por sí solo no revelaba necesariamente el estado completo del despliegue.
El mínimo predeterminado informado por Hallie y discutido en el repositorio público de Anthropic es de 200.000 tokens. Esa cifra es un umbral de elegibilidad, no una promesa de que la compactación ocurra exactamente cuando la conversación alcance los 200.000 tokens.
Una sesión elegible también necesita las condiciones de caché pertinentes y suficiente tiempo de inactividad. La investigación de la comunidad en el problema sobre compactación inactiva encontró que el temporizador se acercaba al final de un periodo de caché de prompts de una hora. Los usuarios observaron el evento visible alrededor de 54 a 56 minutos después de la última actividad.
Esos detalles de temporización procedían de participantes del problema que examinaban el comportamiento del cliente y realizaban pruebas locales. La documentación pública de Claude Code de Anthropic no proporcionó inicialmente una especificación completa de la compactación inactiva. Por ello, los lectores deberían distinguir tres niveles de evidencia: la descripción de Anthropic sobre la compactación, el anuncio de la ingeniera y el análisis comunitario de los detalles de implementación.
La consecuencia verificada para el producto sigue siendo clara en todas esas fuentes. Tras la compactación inactiva, Claude se reanuda desde un estado conversacional comprimido. La transcripción original puede seguir existiendo localmente, pero su contenido completo deja de estar presente automáticamente en el contexto de trabajo del modelo.
Esa distinción importa porque la persistencia local y la atención del modelo resuelven problemas diferentes. Una transcripción almacenada permite auditoría y recuperación. El contexto activo determina qué puede considerar Claude durante su siguiente respuesta.
La función intercambia fidelidad de contexto por eficiencia de caché
La compactación inactiva desplaza el trabajo de un regreso potencialmente frío a una última ventana de caché activa, aceptando la pérdida del resumen para reducir el procesamiento repetido de contexto.
La caché de prompts permite que las solicitudes repetidas reutilicen prefijos de entrada coincidentes. Un acierto de caché generalmente requiere menos procesamiento de entrada que reconstruir el mismo prefijo grande después de que expire su entrada de caché. Las sesiones largas de Claude Code crean prefijos reutilizables inusualmente grandes porque cada turno puede incluir mensajes previos, actividad de herramientas y material del proyecto.
La documentación sobre caché de prompts de Anthropic describe la duración de la caché y el tratamiento diferente de las escrituras y lecturas de caché. Una sesión larga que se enfría puede requerir que Claude Code procese de nuevo un prefijo considerable cuando el usuario regresa.
La compactación inactiva intenta intervenir antes de ese momento. Mientras el prefijo grande sigue en caché, Claude Code puede pedir al modelo que lo resuma. Una solicitud posterior comienza con el resumen más breve y las instrucciones o el material del proyecto que Claude Code restaure.
Este mecanismo favorece la eficiencia cuando un usuario pretende reanudar una sesión grande después de una pausa. En vez de regresar con todo el contexto anterior, el usuario vuelve con una representación comprimida que requiere menos tokens para procesarse.
El coste es la fidelidad de la información. Los resúmenes preservan hechos y decisiones seleccionados, pero no garantizan la retención exacta de cada restricción, opción descartada, observación de pruebas o corrección conversacional.
Anthropic reconoce la limitación general en su documentación sobre contexto. Indica que las solicitudes y los fragmentos de código clave se preservan durante la compactación, mientras que las instrucciones detalladas de conversaciones anteriores pueden perderse.
Esa advertencia se vuelve más relevante en una sesión de programación basada en agentes. Una instrucción sutil puede regir qué ruta de migración está permitida. Una hipótesis rechazada puede impedir que Claude repita una investigación costosa. Una pequeña anomalía de prueba puede explicar por qué una corrección aparentemente obvia no es segura.
Estos detalles pueden parecer secundarios para un resumidor y, aun así, seguir siendo decisivos para el siguiente paso de programación. Un resumen puede describir con precisión el objetivo general del proyecto y aun así omitir la evidencia que limitaba su implementación.
El riesgo aumenta con sesiones largas y exploratorias. Un desarrollador podría pedir a Claude que inspeccione varios módulos, compare diseños competidores, ejecute pruebas y abandone dos enfoques. La dirección final podría depender de resultados negativos dispersos entre salidas de comandos y correcciones breves.
Después de la compactación, Claude podría recordar que se seleccionó un enfoque sin conservar todos los motivos por los que fallaron las alternativas. Entonces puede reconstruir una explicación plausible que difiera de la investigación real.
Esto no hace que la compactación sea inherentemente defectuosa. Ningún sistema finito de gestión de contexto puede conservar de forma literal un historial ilimitado. La disputa se refiere al momento y a la intención del usuario.
Cerca de un límite estricto de contexto, la resumición evita que la sesión se detenga. Antes de que expire la caché, el producto está eligiendo eficiencia aunque la sesión todavía pueda tener una capacidad de contexto restante considerable.
Ese es el principal antagonista de esta historia: la eficiencia de caché frente a la fidelidad de contexto. No es Claude Code frente a otro asistente de programación. Todo agente de larga duración debe gestionar tarde o temprano un contexto finito, pero el desencadenante por inactividad hace que el equilibrio elegido por Anthropic resulte inusualmente visible.
Por qué los desarrolladores objetaron a un resumen automático
La reacción se centró en un cambio de estado no anunciado, no en la existencia de la compresión de contexto en sí.
Un desarrollador que introduce manualmente /compact sabe que Claude resumirá la conversación previa. El comando puede incluir un enfoque, como preservar decisiones de API o fallos de pruebas sin resolver. Ese momento crea un límite natural de revisión.
La compactación inactiva elimina esa elección inmediata. Un usuario puede irse a almorzar, asistir a una reunión o esperar comentarios externos, y luego regresar a una sesión cuyo historial activo ha cambiado.
El informe original de GitHub describía varias sesiones de trabajo que se compactaban mientras estaban inactivas. La persona que lo reportó dijo que los resúmenes omitían instrucciones exactas, el razonamiento de las decisiones y métodos acordados previamente. Otros usuarios informaron de haber visto la misma notificación pese a no estar cerca de su umbral de contexto configurado.
Se trata de informes de usuarios, no de mediciones controladas de la precisión de los resúmenes. Sin embargo, identifican un riesgo de producto creíble porque la documentación de Anthropic ya indica que pueden perderse detalles tempranos durante la compactación.
La implementación inicial también complicó la supervisión. Según pruebas documentadas en el problema, las primeras compactaciones inactivas aparecían en los metadatos de hooks como manual, pese a que ningún usuario había introducido /compact.
Los hooks de Claude Code permiten a los equipos ejecutar automatizaciones antes o después de eventos definidos. Una etiqueta de desencadenante engañosa dificulta distinguir una acción deliberada del usuario de una transición impulsada por temporizador.
Claude Code 2.1.290 cambió ese desencadenante a auto, según un colaborador de Anthropic en el repositorio. Eso separa la compactación inactiva de /compact invocado explícitamente, pero no distingue por completo la compactación inactiva de la compactación automática ordinaria basada en umbrales.
Esta ambigüedad importa para los equipos que usan hooks para preservar el estado de trabajo. Un hook podría querer aplicar una política antes de una compactación de emergencia por límite de contexto y otra antes de una compactación inactiva impulsada por la caché.
La discusión del problema solicitó un desencadenante idle distinto. Según el comportamiento informado en 2.1.290, tanto los eventos de inactividad como los de umbral de contexto podían aparecer como auto. La notificación de terminal identificaba el evento inactivo para la persona, pero ese aviso no se incluía necesariamente en la entrada del hook.
La lección más amplia para el producto se refiere a la optimización invisible. Los desarrolladores suelen aceptar una optimización cuando cambia la latencia o el uso de recursos sin alterar la semántica. La resumición puede cambiar la semántica porque la siguiente solicitud del modelo recibe evidencia diferente.
Eso hace que la compactación inactiva se parezca más a una migración automática de estado que a una tarea de limpieza en segundo plano. El identificador de sesión permanece estable, mientras cambia el sustrato de razonamiento.
Los equipos que realizan migraciones de alto riesgo, respuesta a incidentes o revisiones de código extensas tienen motivos para tratar esa transición con cautela. Sus sesiones suelen acumular restricciones que individualmente son pequeñas, pero colectivamente importantes.
Las sesiones más cortas están menos expuestas porque permanecen por debajo del umbral mínimo. Los flujos de trabajo ya construidos en torno a traspasos explícitos también reducen el coste porque el estado crítico existe fuera de la transcripción del chat.
Por tanto, la presión recae con mayor fuerza sobre los desarrolladores que tratan una única sesión larga de Claude Code como un socio persistente del proyecto. Son quienes más ganan con la continuidad, pero también quienes más pierden cuando la continuidad pasa a depender de un resumen sin un límite intencional.
La configuración idleCompaction separa dos salvaguardas diferentes
Los usuarios pueden desactivar la compactación inactiva sin desactivar la compactación automática que protege las sesiones cerca de su límite de contexto.
Claude Code 2.1.290 introdujo una configuración específica, según un colaborador de Anthropic que respondió en el problema público. Posteriormente, un usuario confirmó que la opción funcionaba en la versión 2.1.291.
La configuración básica es la siguiente:
Claude Code admite ajustes en varios ámbitos, incluidos el nivel de usuario, proyecto, proyecto local y políticas administradas. La referencia de configuración de Anthropic explica sus ubicaciones y prioridad.
Una preferencia para todo el usuario puede incluirse en el archivo de configuración personal. Un equipo de repositorio puede colocar la configuración del proyecto bajo control de versiones cuando todos deban compartir el mismo comportamiento. Una configuración de proyecto local puede modificar el comportamiento sin alterar la configuración compartida del repositorio.
La distinción importante está entre idleCompaction y autoCompactEnabled. El primero se dirige a la nueva ruta basada en temporizador. El segundo controla un comportamiento más amplio de compactación automática.
Desactivar "idleCompaction": false conserva la compactación normal por umbral, basada en el comportamiento descrito para la versión 2.1.290. Esto resulta útil para desarrolladores que desean protección cerca de una ventana de contexto llena, pero rechazan la generación de resúmenes impulsada por la caché durante las pausas.
Esa separación respondió directamente a la petición más contundente de los usuarios. Antes de que apareciera el interruptor específico, desactivar la compactación automática de forma más amplia también podía eliminar la protección que evita que una sesión alcance su límite de contexto.
Los usuarios deben verificar su versión instalada antes de asumir que la clave funciona. Ejecute:
La incidencia pública sitúa la configuración en la versión 2.1.290, mientras que un usuario confirmó explícitamente su funcionamiento en la 2.1.291. Las organizaciones con instalaciones administradas también pueden recibir actualizaciones según un calendario controlado.
La activación del lado del servidor añade otra razón para actuar con cautela. Establecer idleCompaction en true no obliga necesariamente a Anthropic a habilitar la función para todas las cuentas o entornos. Permite el comportamiento del cliente cuando se cumplen otras condiciones de elegibilidad.
Establecerlo en false es el control relevante para los usuarios que necesitan excluirse. Los equipos deben seguir probando el comportamiento con su propia instalación, tipo de cuenta y jerarquía de políticas.
Una configuración administrada puede tener prioridad sobre la elección de un usuario. Esto resulta adecuado para organizaciones con configuración centralizada, pero significa que editar un archivo local podría no producir el resultado esperado.
El método de verificación más seguro es observar el comportamiento. Confirme la versión del cliente, revise la configuración efectiva y pruebe con una sesión no crítica antes de depender de la opción durante un trabajo importante.
Los usuarios también deberían preservar instrucciones duraderas fuera del historial conversacional. Anthropic recomienda colocar las reglas persistentes en CLAUDE.md, que Claude Code carga como contexto del proyecto. Ese consejo se aplica tanto si la compactación inactiva está habilitada como si no, porque la compactación normal cerca del límite aún puede producirse.
Una base de conocimiento de ingeniería con capacidad de búsqueda puede cumplir una función relacionada para los equipos humanos. Las decisiones, restricciones y resultados de investigaciones se convierten en artefactos recuperables, en lugar de depender por completo de una única sesión de agente.
El umbral de 200K es ajustable, pero no es un límite de contexto
`CLAUDE_CODE_IDLE_COMPACT_MIN_TOKENS` cambia cuándo una sesión cumple los requisitos para la compactación inactiva, no el tamaño de la ventana de contexto del modelo.
Hallie indicó que el mínimo predeterminado es de 200.000 tokens. Los usuarios pueden proporcionar un valor entero diferente mediante la configuración de entorno en los ajustes de Claude Code.
Por ejemplo:
Este ejemplo eleva el umbral de elegibilidad a 400.000 tokens. No otorga una ventana de contexto mayor, no reserva 400.000 tokens para el historial de conversación ni garantiza que la compactación se active inmediatamente en ese punto.
El análisis de la incidencia pública informó de un límite inferior de 100.000 tokens. Se describió que los valores por debajo de ese mínimo se elevaban a 100.000. Anthropic no había documentado por completo la variable de entorno en la referencia pública de configuración cuando se desarrolló la discusión, por lo que los usuarios deberían considerar los detalles de implementación como sensibles a la versión.
Elevar el umbral favorece la fidelidad. Más sesiones extensas pueden permanecer inactivas sin resumirse, aunque volver tras la expiración de la caché puede requerir más procesamiento de entrada.
Reducir el umbral favorece la eficiencia de la caché. Más sesiones pasan a ser elegibles para compactación antes de la expiración, lo que aumenta la probabilidad de que los usuarios regresen a resúmenes en lugar de al historial conversacional completo.
El valor adecuado depende de la forma del flujo de trabajo, no simplemente de la capacidad del modelo. Una sesión larga con resultados repetitivos de herramientas puede resumirse bien. Una discusión de arquitectura más corta puede contener decisiones densas e interdependientes que se resisten a la compresión.
El recuento de tokens mide el tamaño, no la importancia semántica. Una sesión de depuración de 300.000 tokens podría incluir miles de líneas de registro prescindibles. Una revisión de seguridad de 120.000 tokens podría contener numerosas hipótesis de amenaza precisas que deberían conservarse literalmente.
Por eso un mínimo configurable ayuda sin resolver la tensión central. Permite a los equipos elegir dónde comienza la compensación, pero un umbral numérico no puede reconocer si la conversación actual es segura de resumir.
Los desarrolladores pueden reducir el riesgo creando puntos de control explícitos antes de abandonar una sesión. Pida a Claude que registre el objetivo activo, los hallazgos confirmados, los enfoques descartados, los archivos modificados, el estado de las pruebas y el siguiente comando en una nota del repositorio.
Esa nota no debería limitarse a reformular la tarea. Debe recoger la evidencia necesaria para retomar el trabajo sin reconstruir toda la conversación.
Las restricciones persistentes deben estar en CLAUDE.md o en otro archivo de proyecto autorizado. Los descubrimientos temporales deben incluirse en una incidencia, un registro de trabajo o un documento de relevo. Los resúmenes generados pueden entonces contribuir a la continuidad sin convertirse en el único registro.
Los equipos también pueden usar /context para inspeccionar qué está consumiendo la ventana activa. Si predominan resultados voluminosos de comandos, eliminar o reestructurar ese material puede ser más seguro que permitir que un resumen general decida qué importa.
La opción manual /compact sigue siendo útil en límites naturales. Anthropic afirma que los usuarios pueden añadir instrucciones de enfoque, lo que ofrece al resumidor un objetivo de conservación mejor que un evento de inactividad sin supervisión.
El principio más amplio es sencillo: elija la compactación en torno a los límites de las tareas cuando sea posible. Los umbrales de tokens evitan fallos, pero los límites definidos por humanos reflejan mejor la estructura del trabajo de ingeniería.
Qué preserva la compactación de Claude Code y qué no puede prometer
La compactación conserva una representación de trabajo de la sesión, no una copia sin pérdidas de su historial de razonamiento.
La documentación de Claude Platform de Anthropic define la compactación como la sustitución de turnos de conversación antiguos por un resumen escrito por el modelo. Su descripción general de la compactación explica que las aplicaciones continúan colocando el bloque compactado devuelto donde aparecían antes los mensajes resumidos.
Claude Code gestiona ese flujo de trabajo dentro del producto. La implementación precisa difiere de la de una aplicación que usa directamente la API de Claude, pero el resultado conceptual es similar: la entrada antigua se representa mediante texto generado.
Un buen resumen puede conservar la solicitud del usuario, el estado actual de la implementación, rutas de archivos importantes, resultados de pruebas y tareas pendientes. Puede reducir drásticamente la cantidad de material previo enviado en turnos posteriores.
No puede garantizar la conservación literal de cada intercambio. El resumidor debe seleccionar información, organizarla y expresarla dentro de un presupuesto de tokens menor.
El historial de razonamiento plantea un reto particular. Una sesión de programación suele contener una cadena de descartes. Claude examina un archivo, formula una hipótesis, observa resultados contradictorios y cambia de dirección.
El resumen final puede registrar la explicación aceptada mientras comprime el camino que la validó. A menudo eso es suficiente, pero debilita la capacidad del siguiente modelo para auditar la conclusión.
Los resultados de herramientas crean otro problema. Los registros, errores de compilación, planes de bases de datos y trazas de pruebas pueden contener pequeños detalles cuya importancia solo se hace evidente más tarde. Un resumen generado antes de ese descubrimiento posterior no puede saber qué línea será relevante.
Las correcciones de los usuarios también pueden perder fuerza. «No cambies el esquema» puede aparecer una vez, seguido de cientos de turnos. Si no se eleva a instrucciones persistentes, la compactación puede reducir u omitir su relevancia.
La documentación de Claude Code recomienda explícitamente CLAUDE.md para las reglas que deben perdurar. También admite una sección de “Compact Instructions”, que indica al resumidor qué debe retener durante la compactación.
Estos mecanismos reducen el riesgo, pero no convierten los resúmenes en copias sin pérdidas. Una instrucción de compactación sigue siendo una guía para un modelo que realiza una selección. Un archivo de instrucciones del proyecto es más sólido porque Claude Code puede cargarlo de nuevo como contexto autorizado.
Por lo tanto, los desarrolladores deberían dividir el conocimiento de la sesión en tres clases. Las reglas operativas permanentes pertenecen a las instrucciones del proyecto. El estado de ingeniería verificado pertenece a archivos o registros de trabajo rastreados. La exploración conversacional puede permanecer en la transcripción y aceptar una compresión eventual.
Este enfoque también mejora la colaboración. Otro ingeniero no puede heredar de forma fiable los matices no documentados de una conversación privada con un agente. Un archivo de relevo conciso proporciona a humanos y agentes un punto de recuperación compartido.
La cuestión práctica no es si los resúmenes son buenos o malos. Es si un hecho concreto puede existir de forma segura solo dentro de un resumen.
Si perder un detalle provocaría una migración insegura, un incidente repetido o un resultado no válido, regístrelo fuera de la conversación antes de abandonar la sesión.
Tres señales mostrarán si la compactación inactiva se gana la confianza
La siguiente prueba es si Anthropic puede hacer observable el beneficio de eficiencia sin volver impredecible la continuidad de las sesiones.
La primera señal es la documentación oficial. Los usuarios necesitan una descripción estable de la elegibilidad, la temporización, las versiones compatibles, los límites de umbral, la prioridad de configuración y las interacciones con las políticas de caché de prompts.
La documentación también aclararía si el valor predeterminado de 200.000 tokens se aplica de forma coherente entre modelos y cuentas. Si Anthropic documenta la variable de entorno y su límite inferior, los equipos podrán configurarla sin depender de la arqueología de incidencias.
Ese resultado reforzaría la confianza en la función. Seguir dependiendo de publicaciones sociales e inspección de binarios la debilitaría, porque los controles no documentados pueden cambiar sin una ruta de migración evidente.
La segunda señal son metadatos de hook diferenciados. Un activador idle específico permitiría a los equipos tratar la compactación impulsada por temporizador de forma distinta tanto de los comandos manuales /compact como de la compactación automática cerca del límite.
Las organizaciones podrían capturar una instantánea del estado antes de un evento inactivo, adjuntar instrucciones de compactación adaptadas o registrar telemetría sobre la frecuencia con que se activa la función. Una identidad clara del evento también facilitaría la investigación de incidentes.
Si Anthropic mantiene ambas rutas automáticas bajo la misma etiqueta auto, los administradores tendrán una visibilidad limitada sobre por qué cambió una sesión. Eso mantendría una brecha entre la experiencia en terminal y las interfaces de automatización.
La tercera señal es la evidencia sobre la calidad de los resúmenes en sesiones largas de programación. Los informes de usuarios identifican matices perdidos, pero la discusión pública no establece una tasa general de fallos.
Una evaluación útil mediría si los resúmenes conservan restricciones explícitas, hipótesis descartadas, tareas pendientes, fallos de pruebas, referencias a archivos y reglas de seguridad. También debería probar la compactación repetida, ya que los errores pueden acumularse cuando un estado comprimido se convierte en entrada para otro.
Un resultado positivo respaldaría el argumento de eficiencia de Anthropic. Mostraría que la mayoría de las sesiones que cumplen los requisitos se reanudan con suficiente precisión como para justificar la compresión automática antes de la expiración de la caché.
Un resultado negativo reforzaría el argumento a favor de un comportamiento de inclusión voluntaria o de umbrales predeterminados más altos. También podría llevar a Claude Code hacia una compactación parcial que mantenga los turnos recientes literalmente mientras resume el material más antiguo.
Por ahora, los desarrolladores tienen una opción viable. Mantengan activada la compactación por inactividad de Claude Code cuando reducir la sobrecarga al reanudar importe más que conservar una continuidad literal. Eleven el umbral de tokens cuando solo las sesiones muy extensas justifiquen esa concesión.
Desactívenla con "idleCompaction": false cuando una sesión pausada deba volver con su historial activo existente intacto. La compactación normal por límite de contexto puede mantenerse activada como medida de protección independiente.
Sea cual sea la política elegida, no conviertan un chat largo en el único registro del estado crítico de ingeniería. Incluyan las restricciones duraderas en las instrucciones del proyecto, conserven los hallazgos verificados en archivos y preparen un relevo antes de alejarse.
La compactación por inactividad de Claude Code revela una verdad fundamental sobre los agentes de programación: la continuidad de una sesión no equivale a una memoria perfecta. Antes de su próxima pausa larga, decidan cuál de las dos necesita realmente su flujo de trabajo.
