![Imagen de portada de [Contexto de IA #3] Criterios para elegir /clear o /compact](/assets/images/posts/dbbbbbf4-c659-46d5-8a59-05ef8e331a0d/1.jpg)
Los dos artículos anteriores completaron el diagnóstico. La ventana de contexto es finita (parte 1), y llenarla no significa que todo se utilice; cuanto más crece, más disminuye el rendimiento (parte 2). La solución es clara: hay que gestionar el contexto. Las herramientas más básicas que ofrecen los agentes de código, incluido Claude Code, son /clear y /compact.
Ambos comandos reducen el contexto. Por eso mucha gente usa cualquiera de los dos sin criterio, o espera hasta que aparece el aviso de poco contexto. Pero funcionan de forma completamente distinta: usarlos en la situación equivocada puede borrar todo el contexto de trabajo o, al contrario, hacer que arrastres un contexto desordenado. En esta parte veremos qué hace exactamente cada comando internamente y estableceremos cuándo conviene usar cada uno.
/clear: borrar el historial y empezar de cero
/clear es sencillo: descarta todo el historial de conversación acumulado. En el siguiente turno, el modelo empieza solo con el prompt del sistema, los archivos cargados siempre, como CLAUDE.md, y el nuevo mensaje que acabas de introducir. Si recuerdas la estructura de la parte 1, el significado es claro: como la conversación consiste en reenviar todo el historial en cada turno, borrar el historial equivale a reiniciar el paquete que se envía al modelo.
Lo que pierdes es todo el contexto de la conversación; lo que ganas es un contexto limpio. El efecto lost in the middle de la parte 2 y la confusión causada por versiones antiguas de archivos y logs fallidos también desaparecen al eliminar el historial. El margen de tokens se recupera por completo y se reenvía menos entrada en cada turno, así que las respuestas son más rápidas y el coste disminuye.
Por eso /clear corresponde a los límites entre tareas. Si ya has corregido un bug y completado el commit, la siguiente funcionalidad no necesita el stack trace ni los intentos fallidos del bug anterior. Mezclarlos solo perjudica. Separar cada tarea con /clear evita buena parte de la pérdida de calidad durante la segunda mitad de una sesión.
/compact: sustituir el historial por un resumen
/compact adopta otro enfoque. En lugar de descartar el historial, pide al modelo que resuma la conversación y sustituye el historial original por ese resumen. Un historial de decenas de miles de tokens se reduce a un resumen de unos pocos miles, recuperando margen y conservando la línea principal del trabajo.
La clave es que se trata de compresión con pérdida. Resumir implica que el modelo elige lo que parece importante, y el usuario no puede controlar qué sobrevive. Detalles concretos como rutas de archivos, enfoques probados y abandonados o el texto exacto de un mensaje de error se pueden difuminar durante el resumen. Que el agente vuelva a leer los archivos justo después de compact se debe a que el resumen no revela su estado exacto.
Por suerte, existe cierto control. /compact de Claude Code permite añadir instrucciones al final. Por ejemplo, «/compact conserva sobre todo los cambios de esquema confirmados en esta migración y la lista de archivos pendientes» permite dirigir el foco del resumen. El usuario sabe mejor qué es importante, así que, aunque delegue la compresión, debe marcar la dirección.
Criterio de elección: ¿hay contexto que deba continuar?
El criterio se reduce a una pregunta: ¿el agente del siguiente turno necesita conocer el contexto acumulado?
- La tarea terminó y la siguiente es independiente → /clear. Es el valor predeterminado, sin darle más vueltas.
- La misma tarea continúa, pero queda poco margen → /compact. Eso sí, indica en la instrucción qué debe conservarse.
- Es la misma tarea, pero el agente empieza a dar vueltas → sorprendentemente, /clear es mejor. Resumir un contexto contaminado por intentos fallidos solo concentra la contaminación. Haz que organice el estado actual y los siguientes pasos en un archivo, y después reinicia con /clear usando ese archivo.
El tercer caso da una pista. Entre clear y compact hay una tercera vía: sacar del contexto a un archivo lo que quieras conservar. Pide «organiza en PLAN.md las decisiones tomadas hasta ahora y el trabajo pendiente», ejecuta /clear y haz que la nueva sesión lea PLAN.md. Así pasas únicamente el contexto necesario, con precisión y sin la incertidumbre del resumen. A diferencia de /compact, donde el modelo decide qué conservar, aquí el contenido existe en un archivo visible que puedes verificar y modificar. Este patrón de «externalización» se analiza con más profundidad al tratar la memoria en la parte 6.
Por qué no debes esperar a auto-compact
Claude Code ejecuta compact automáticamente cuando el margen alcanza un umbral. Es una buena medida de seguridad, pero depender de ella es otra cuestión.
El saldo de tokens determina cuándo se activa auto-compact, sin relación con el flujo de trabajo. Puede comprimir en el peor momento: con una refactorización a medias, cinco archivos modificándose y las pruebas rotas. El resumen agrupa un estado intermedio y confuso, y el agente continúa con una comprensión sutilmente desalineada. El context poisoning de la parte 2 ocurre así a través del resumen.
Por eso los usuarios con experiencia gestionan el saldo restante como un indicador. En cada hito lógico—commit, pruebas superadas o decisión confirmada—guardan el estado en un archivo y cierran el hito cuando queda un 20–30 %, eligiendo por sí mismos cuándo usar /clear o /compact. Aunque la compresión sea inevitable, puedes controlar cuándo y cómo ocurre.
Resumen
- /clear elimina el historial; /compact lo sustituye por un resumen. El primero descarta el contexto y recupera al máximo el margen, mientras que el segundo conserva la línea principal a costa de perder detalles.
- El valor predeterminado es usar /clear en cada límite de tarea. Usa /compact solo cuando haya contexto que continuar y especifica en la instrucción qué debe conservarse.
- Si el agente da vueltas, es más limpio hacer que guarde el estado en un archivo y reiniciar con /clear en lugar de resumir.
- auto-compact es solo una medida de seguridad; conviene decidir el momento de comprimir según los hitos de la tarea.
Hasta aquí llega la gestión del historial de conversación. Sin embargo, existe contexto que no desaparece con /clear y se envía en cada turno: las áreas cargadas siempre, como el prompt del sistema, CLAUDE.md y las definiciones de herramientas. En la siguiente parte veremos cómo diseñar este coste fijo. La cuestión central es qué incluir en CLAUDE.md y qué dejar fuera.