Antes de una tarea larga en Claude Code: cuándo hacer compact y cómo controlar los subagentes y el consumo

Antes de pedirle a Claude Code que pase un buen rato leyendo código, haciendo cambios y ejecutando pruebas, no te apresures a vaciar el contexto. Tampoco necesitas conservar todas las conversaciones anteriores solo para «aprovechar todo el 1M».

Conviene resolver primero otras preguntas: ¿qué detalles originales seguirá necesitando el siguiente paso? ¿El trabajo que vas a delegar puede completarse de forma independiente? Cuando termine la tarea, ¿cómo sabrás si el cambio ha servido, en vez de limitarte a ver una cifra de consumo más baja?

El 19 de septiembre, ZryMiller contó cómo había cambiado su manera de trabajar. Antes compactaba con frecuencia; después volvió a lo que él llamó la ventana predeterminada de 1M. Según su experiencia, la mejora fue notable, y dijo que se estaba preparando para publicar su primera aplicación. Pero la publicación no incluía tareas comparables, cifras de consumo antes y después ni el resultado final del lanzamiento. Es una experiencia personal útil, no una demostración de que «no compactar mejora todas las tareas largas».

En lugar de elegir entre «compactar a menudo» y «no compactar nunca», toma la decisión al cerrar una etapa concreta del trabajo.

Primero, confirma qué estás utilizando

Ejecuta claude --version en el terminal y anota la versión del cliente. Dentro de la sesión, usa /status para comprobar la cuenta y el modelo actual, /model para ver los modelos disponibles y sus ajustes, y /context para consultar la ocupación del contexto. Cuando necesites información de consumo, ejecuta /usage. Estos comandos muestran cosas distintas; no son medidas intercambiables. Referencia oficial de comandos · Documentación sobre consumo

El nombre oficial del modelo de esta discusión es Claude Fable 5.1. Su ID en Claude API es claude-fable-5-1, y la especificación oficial indica una ventana de contexto de 1M de tokens. El modelo, la versión de Claude Code y el ajuste effort son datos diferentes. No los resumas en «usé Fable» o «usé Ultra». Especificación oficial del modelo

Que un modelo admita 1M no significa que todas las cuentas, modelos y vías de acceso tengan automáticamente las mismas condiciones. Por ejemplo, la documentación oficial distingue entre el acceso a 1M de Opus incluido en Max, Team y Enterprise, y el acceso en Pro, que requiere usage credits. La ventana de 1M de Sonnet 4.6 también requiere usage credits en los planes de suscripción. No traslades estas reglas directamente a otros modelos. También hay que comprobar la configuración del cliente, el mapeo de modelos y la compatibilidad de la pasarela: añadir [1m] en el selector no amplía por sí solo las capacidades del modelo en el servidor. Condiciones de 1M y configuración de modelos

Distingue también tres cifras que se confunden fácilmente: la ocupación del contexto indica cuánto contenido debe caber en la solicitud actual; el consumo acumulado de tokens registra cuánta entrada, salida y contenido en caché han procesado las solicitudes; la cuota de la suscripción es el límite de la cuenta dentro de la ventana de uso correspondiente. Cinco horas o una semana describen ventanas de cuota, no una garantía de que la tarea pueda ejecutarse sin interrupción durante cinco horas o una semana. El contenido recuperado de la caché sigue ocupando contexto, aunque la facturación de la API pueda aplicar tarifas específicas de caché. Por eso, «30% del contexto ocupado» no se puede convertir en «30% de la cuota de cinco horas consumida», y 1M tampoco es una asignación de tokens que puedas procesar una y otra vez gratis. Contexto y caché · Estructura de precios de la API

Antes de compactar, revisa de qué depende el siguiente paso

Imagina que investigas un error que afecta al frontend, a una API y a la base de datos. Acabas de leer varios fragmentos de código, examinar una solicitud fallida y detectar un caso límite, pero aún no has llegado a conclusiones verificables. Compactar solo porque «el chat ya es muy largo» podría eliminar justo los detalles que necesitas contrastar a continuación.

En cambio, si la causa ya está clara, has registrado los archivos relevantes y dónde están las pruebas, y solo queda hacer un pequeño cambio siguiendo un plan acordado, puede que gran parte de las búsquedas anteriores ya no tenga que permanecer en la ventana actual.

El momento adecuado para compactar no lo marca un porcentaje universal, sino el cierre de una etapa desde la que puedas continuar con registros fiables. Es una recomendación de trabajo, no un umbral fijo del modelo.

Primero, pide a Claude que escriba el estado necesario en el registro de la tarea que le indiques: hechos confirmados y ubicación de las pruebas, archivos realmente modificados, comprobaciones ejecutadas y sus resultados reales, asuntos pendientes y siguiente paso. No hace falta copiar toda la conversación, ni convertir conjeturas sin verificar en conclusiones.

Después puedes usar el comando nativo /compact, indicando qué quieres conservar: Cómo funciona la compactación

/compact Conserva el objetivo actual, las conclusiones confirmadas y la ubicación de las pruebas, los archivos modificados, las comprobaciones ejecutadas y sus resultados reales, los asuntos pendientes y el siguiente paso. Elimina las búsquedas repetidas y las discusiones sobre opciones ya descartadas.

Este texto expresa requisitos para el resumen, no garantiza que no se pierda información. Antes de seguir modificando código, pide a Claude que explique el siguiente paso a partir del contexto compactado y contrasta las restricciones principales con los archivos reales y el registro de la tarea. Si falta algún caso límite, reincorpóralo antes de que la implementación se desvíe y haya que rehacerla.

Si el siguiente trabajo ya no guarda relación con el anterior, suele ser más directo guardar los resultados y la información necesaria para retomarlo, y empezar una sesión nueva con /clear. Usa /resume cuando necesites volver a la conversación original. Vaciar una sesión no devuelve el consumo ya realizado ni reinicia la cuota de la suscripción. Comandos de sesión · Qué se reinicia en la visualización del consumo

Claude Code ya dispone de compactación automática, así que no necesitas instalar un complemento para seguir este enfoque. Las versiones v2.1.221 y posteriores también ofrecen /autocompact: sin argumentos, muestra la ventana actual de compactación automática; /autocompact auto restaura el ajuste de ventana adaptado al modelo. Este último guarda una configuración, no se limita a expresar una preferencia al modelo. La ventana máxima de contexto del modelo y la ventana de compactación automática no son lo mismo. Comando de compactación automática

HKTECH_AI estimó que una sola compactación podría consumir alrededor del 15% de una cuota de cinco horas. La publicación no aportaba una factura ni un método de cálculo, de modo que ese porcentaje no debería convertirse en una regla de uso. Lo que hay que comparar es si la compactación redujo el contenido arrastrado repetidamente a las siguientes solicitudes y si, a cambio, obligó a releer, volver a explicar o corregir.

Los subagentes pueden repartirse el trabajo, pero importa cómo se aplica «uno a la vez»

SHCH compartió un reparto de funciones: Fable planifica y toma decisiones, un Scout con Sonnet realiza búsquedas y un Builder con Opus ejecuta tareas bien definidas. Recomendó expresamente invocar solo un subagente a la vez.

Su captura del Builder insiste en seguir el plan existente, detenerse e informar si hay problemas en ese plan, no lanzar más subagentes y comunicar los resultados de las comprobaciones. El valor de esas instrucciones está en delimitar responsabilidades. Pero «no lances más subagentes» en una imagen sigue siendo una restricción del prompt, no un límite impuesto por el software. El autor también habló de ejecutar varias sesiones principales y no publicó consumo verificable antes y después. Por tanto, esta configuración no equivale a «un solo agente en toda la cuenta», y mucho menos permite prometer un porcentaje fijo de ahorro.

Un subagente normal comienza con un contexto independiente: recibe la tarea delegada y la configuración correspondiente, pero no obtiene automáticamente todo el historial de la sesión principal. Un subagente fork sí hereda la conversación existente. Trasladar una investigación llena de detalles intermedios a un subagente puede reducir la información de proceso que debe contener la sesión principal, pero sus solicitudes siguen procesando tokens y su resultado también entra en la sesión principal. Límites del contexto de los subagentes

Así que pregunta primero «¿Merece la pena delegar esta tarea?» y después «¿Cuántos deberían ejecutarse a la vez?». Una búsqueda sencilla no necesita una cadena completa de planificador, investigador y ejecutor. Dos tareas que modificarán repetidamente el mismo archivo tampoco tienen por qué ser buenas candidatas al trabajo simultáneo. Las investigaciones realmente independientes, con entregables claros, se prestan mejor a una comparación en paralelo.

Puedes concretar las instrucciones de trabajo así:

Objetivo: Completar los cambios acordados y superar las comprobaciones directamente relacionadas.
Alcance permitido: La implementación y las pruebas correspondientes a esta solicitud.
Ejecución: Realiza directamente las búsquedas sencillas. Si es necesario delegar, proporciona solo el contexto y los requisitos del entregable que necesita esa subtarea, y asigna un subagente a la vez. No consultes repetidamente el mismo estado mientras esperas.
Criterios de finalización: Entrega según los requisitos de aceptación y detente cuando pasen las comprobaciones pertinentes. Si hay un bloqueo, informa de lo completado y del motivo; no vuelvas a iniciar la misma tarea.

Siguen siendo instrucciones de comportamiento. Para restringir realmente la creación de subagentes nativos, utiliza los controles del cliente. Claude Code v2.1.217 y posteriores permiten limitar la concurrencia y la profundidad de delegación. Este ejemplo de inicio en Bash/Zsh para macOS y Linux es un punto de partida conservador para investigar paralelismo innecesario: Referencia de variables de entorno

CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS=1 \
CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH=1 \
claude

La primera variable establece una comprobación de concurrencia por sesión al crear nuevos subagentes mediante la herramienta Agent. La segunda limita los subagentes a un nivel, evitando que sigan delegando de forma anidada. No son prompts ni cambian retroactivamente otras sesiones que ya estén en marcha. Referencia de variables de entorno

Sin embargo, esto no es un bloqueo global que garantice «como máximo un agente, siempre y en todas partes». La documentación oficial enumera excepciones: las sesiones ultracode no aplican este límite de concurrencia; las llamadas manuales a /subtask y la reanudación de subagentes ya completados no quedan bloqueadas por la misma comprobación de nueva creación; los flujos de trabajo y los agent teams tienen sus propios límites. Este único ajuste tampoco controla conjuntamente varias sesiones principales ni procesos iniciados externamente. Límites de concurrencia y excepciones

Si tu propio planificador necesita un límite global real, una cola o un bloqueo de concurrencia debe coordinar los inicios, las reanudaciones y los reintentos. No basta con escribir «uno a la vez» en el prompt. Eso forma parte de tu implementación del planificador, no de otra configuración de Claude Code sin documentar.

Esperar un resultado no significa hacer que el modelo pregunte continuamente por el progreso

LeeLeepenkman no se quejaba simplemente de «usar subagentes». Describió cómo Fable 5.1 enviaba un prompt grande a muse y después consultaba su estado aproximadamente cada cinco segundos, lo que hacía crecer el contexto con rapidez. La publicación original no explicaba la implementación de muse ni aportaba registros de solicitudes o resultados tras resolver el problema. Por eso, cinco segundos no se puede presentar como el intervalo fijo de sondeo de Claude Code.

Los subagentes nativos en segundo plano disponen actualmente de notificaciones de finalización y devuelven sus resultados a la sesión principal en turnos posteriores. Puedes consultar el trabajo en ejecución con /tasks. Eso no es lo mismo que hacer que el modelo emita una y otra vez nuevas solicitudes de «¿Ya terminó?». Subagentes en segundo plano y notificaciones de resultados

Al investigar, despliega los registros de herramientas de la sesión y sigue una misma tarea: ¿las consultas repetidas aportan información nueva? ¿Se ha vuelto a iniciar algo que ya estaba terminado? ¿La consulta de estado provocó realmente otra llamada al modelo? Ctrl+O abre una vista más detallada de la conversación, pero el número de actualizaciones de la interfaz no equivale directamente al número de solicitudes al modelo. Si necesitas consumo por solicitud, contrasta también los registros del proveedor que estés utilizando. Interacción y vistas de la sesión

Con las notificaciones nativas, normalmente no hace falta añadir un bucle de comprobación frecuente ejecutado por el modelo. Si una herramienta externa solo permite sondeo, deja que el programa compruebe los cambios de estado a intervalos razonables, establezca un tiempo de espera máximo y pase información al modelo solo cuando haya un resultado nuevo o una incidencia. La propuesta es reducir las llamadas al modelo que no aportan información, no impedir el seguimiento necesario del progreso.

Cuando se restablezca la cuota, comprueba primero qué queda pendiente

intwerpret relató un caso más drástico. Tras alcanzar un límite de uso, eligió esperar y continuar automáticamente. Después afirmó que aparecieron 39 agentes, que volvieron a agotar la cuota, y acabó regresando a Codex. Los materiales no incluyen la versión del cliente, el contenido de la tarea, la configuración completa ni el origen del mecanismo de reanudación. Tampoco se sabe si la tarea terminó completándose.

Esta experiencia invita a revisar el proceso de reanudación, pero no demuestra que «la reanudación automática de Claude Code siempre lance 39 agentes». Que el autor utilizara la palabra «Ultra» tampoco basta para afirmar que estaba ejecutando el modo ultracode mencionado antes.

Por otra parte, ya no se puede atribuir toda continuación automática a scripts de terceros. La documentación oficial del modo interactivo recoge una función nativa para continuar cuando se restablece el límite de uso: desde v2.1.234, las sesiones interactivas de suscripción que cumplen las condiciones pueden esperar a que la cuota se restablezca y seguir trabajando. Esto no equivale al comportamiento con una clave API, con -p ni en todos los modos en segundo plano. Reanudar tampoco consiste simplemente en reenviar la última tarea original del usuario. Espera nativa y continuación automática

Si no quieres que la tarea se reanude sin supervisión, desactiva Continue automatically at usage limit (continuar automáticamente cuando se restablezca el límite de uso) en /config. En las versiones compatibles con este ajuste también puedes ejecutar:

/config autoContinueAtUsageLimit=false

Si la sesión ya está esperando, cancela también esa espera concreta: pulsa Esc con el cuadro de entrada vacío o selecciona Don’t continue automatically (no continuar automáticamente) en /rate-limit-options. Cambiar el ajuste predeterminado y cancelar una espera ya elegida son acciones distintas. Cancelación y configuración de la continuación automática

Después comprueba /tasks y el estado real de los archivos. ¿Qué tareas siguen ejecutándose, cuáles están completas y cuáles solo necesitan una comprobación más? Reutiliza los resultados existentes y concreta qué trabajo pendiente debe continuar, en vez de reenviar toda la solicitud para que vuelva a dividirse en tareas.

Antes de hacer commits, desplegar, enviar mensajes o realizar otras acciones con efectos externos, comprueba especialmente si el intento anterior ya tuvo éxito. El restablecimiento de la cuota solo resuelve «¿Se pueden seguir enviando solicitudes?». No garantiza que las siguientes acciones no repitan algo ya ejecutado.

Mira el resultado antes de decidir si el consumo ha mejorado

chasemdev explicó que no hacía que Fable escribiera todo el código por sí mismo, sino que lo utilizaba para coordinar subagentes Opus. Aun así, esperaba alcanzar pronto el límite semanal. Ese «pronto» era una previsión del autor en aquel momento, no un resultado final de consumo verificado. Pero recuerda un aspecto fácil de dejar fuera del registro: cuenta también los modelos y el trabajo de los subagentes, no solo el modelo principal.

Actualmente, la sección Session de /usage muestra el consumo de tokens de la sesión y una estimación del coste calculada localmente. Los usuarios de suscripción también ven el uso del plan en la misma interfaz. La cifra en dólares de Session no es una factura de la suscripción, ni tiene por qué coincidir con el cargo final del proveedor de API. Si pagas por uso, toma como referencia la factura de tu proveedor real. Qué significa actualmente /usage

La atribución local del consumo de la suscripción es solo una pista. El desglose por subagentes, complementos, skills y otros componentes procede del historial reciente de esta máquina. No incluye todo el consumo de otros dispositivos o de la web, y tampoco prueba causalmente «cuánto desperdicio produjo un complemento». Si ves Showing last-known usage, anota la fecha y hora de los datos mostrados y actualiza antes de comparar. Alcance de la atribución y lecturas en caché

No necesitas montar un sistema de evaluación complejo. Elige una tarea con un alcance claro que puedas reproducir de forma segura, escribe sus criterios de aceptación y registra lo siguiente al principio y al final:

Qué registrar	Qué preguntas responder
Tarea, versión inicial del código, modelo, effort y versión del cliente	¿Estás comparando el mismo tipo de trabajo y configuración antes y después?
/context y el proceso de compactación	¿Se perdieron restricciones, hubo que releer o volver a explicar?
Subagentes y comportamiento durante la espera	¿Qué tareas se crearon o reanudaron, cuántas llegaron a ejecutarse a la vez y hubo consultas repetidas sin información nueva?
Lecturas de consumo, momentos de registro y puntos de restablecimiento	¿Se restableció la cuota durante la comparación, hubo actividad de otras sesiones y se contabilizaron todos los modelos relacionados en la API?
Entregables reales y resultados de las comprobaciones	¿Se cumplieron los requisitos, pasaron las comprobaciones pertinentes y cuánto trabajo manual de corrección queda?

Cambia una sola práctica, como esperar a terminar la investigación antes de compactar o limitar la concurrencia al crear subagentes nuevos. Conserva los criterios de aceptación originales; no reduzcas la tarea a escondidas para obtener una cifra menor. Indica también si el estado de la caché era distinto. Si las dos ejecuciones utilizaron modelos, versiones de código o tamaños de tarea diferentes, no atribuyas toda la diferencia a la compactación.

Consumir menos tokens dejando requisitos sin cumplir o la verificación en manos de una persona no es una mejora. Y si conservar más contexto permite terminar de una vez, sin repetir la investigación, una ventana más ocupada no basta para considerar que se han desperdiciado recursos.

Lleva por separado las cuentas de la API independiente y de la suscripción. Cambiar el origen de la facturación no restablece la cuota de la suscripción original ni modifica automáticamente cómo delega, espera o compacta el cliente. Para valorar si merece la pena, compara el consumo total y el trabajo que hay que rehacer para completar la misma tarea, no solo el precio unitario de un modelo. Diferencias entre formas de facturación · Estructura de facturación de tokens en la API

Antes de dejar que un complemento decida cuándo compactar, comprueba qué envía fuera

Kun Chen partió de una pregunta práctica: «when should i /compact my session», es decir, ¿cuándo conviene compactar la sesión actual? Su compact-adviser utiliza Jev de TypeSafe para valorar si el trabajo ha llegado a un punto adecuado para compactar. Ofrece un modo de sugerencias y un modo automático que requiere activación expresa. Descripción del proyecto

La comprobación para este artículo se fijó en el commit d1655faa16a22b68bff60c3d7deb0123e1e52a53, cuyo manifiesto del complemento de Claude Code indica la versión 0.1.4. El proyecto exige Node.js 22 o posterior y Claude Code 2.1.274 o posterior, y declara haberlo verificado con 2.1.275. La integración con Claude Code depende de hooks de función experimentales y requiere CLAUDE_CODE_ENABLE_FUNCTION_HOOKS=1. Son condiciones de compatibilidad declaradas por el proyecto, no resultados de una instalación probada para este artículo. Manifiesto de la versión fijada · Requisitos de versión e integración

Más importante aún: el modo hint solo significa que no se compacta automáticamente. No significa que la decisión se tome localmente ni que el contexto no salga del equipo. La documentación de seguridad explica que, tras la instalación, si hay una clave disponible en el entorno de inicio, en los ajustes guardados o en un archivo .env del directorio de trabajo, y se cumplen las condiciones de llamada, se envían a TypeSafe fragmentos seleccionados de la sesión. Incluyen restricciones del usuario, respuestas visibles recientes y resultados de herramientas, un resumen existente y nombres de los artefactos generados. No existe otro interruptor independiente para confirmar el envío. Los fragmentos pueden contener código o información del negocio; intentar ocultar los datos sensibles no garantiza que no quede ninguno. Límites del envío de contexto

Si ya lo tienes instalado, puedes desactivarlo con /compact-adviser off o iniciar así:

COMPACT_ADVISER_DISABLE=1 claude

Según el proyecto, esto detiene las solicitudes, las sugerencias y la compactación automática del complemento. Desactiva el complemento, no la compactación automática propia de Claude Code. Si no está permitido enviar contenido de trabajo adicionalmente a TypeSafe, desactívalo o desinstálalo; no te limites a cambiar de auto a hint. Cómo desactivarlo

La evaluación de 40 sesiones que menciona el autor es una evaluación del propio proyecto, y el conjunto de datos no es público. No garantiza que tus tareas conserven todos sus detalles. Incluso si el complemento considera que es un «buen momento para compactar», lo decisivo sigue siendo si el trabajo puede continuar correctamente después. Límites de la evaluación

Todo esto se puede hacer sin instalar un complemento: guardar el estado al cerrar etapas y conservar los detalles que necesitará el siguiente paso; asignar a los subagentes trabajo claro e independiente; evitar inicios duplicados al esperar o reanudar; y valorar los resultados junto con los registros de consumo.

El objetivo al gestionar una tarea larga no es llenar la ventana ni conseguir que cada solicitud parezca lo más barata posible. Es hacer menos trabajo que no aporta avance y terminar de forma fiable lo que ya has empezado.