Cuándo usar /clear en lugar de /compact en Claude Code

Respuesta corta: usa /clear cuando quieras empezar de cero y /compact cuando necesites continuidad, porque la propia documentación de Anthropic afirma que "/compact reads the conversation it summarizes, so compacting a large context is itself a large request", es decir, que /compact lee la conversación que resume, y que "when you want a fresh start instead of continuity, /clear costs nothing", o sea, que /clear no cuesta nada. La regla práctica que sale de ahí: si lo próximo que vas a hacer es otra tarea, limpia; si es la misma tarea y tendrías que explicarlo todo de nuevo, compacta.

¿Cuál es la diferencia entre /clear y /compact en Claude Code?

Los dos comandos resuelven problemas opuestos. /compact le pide a Claude Code que resuma la conversación hasta ese punto y siga desde ese resumen, manteniendo el hilo de lo que estabas haciendo. /clear termina la sesión y abre una vacía, sin guardar nada. La asimetría de coste es la parte que casi todo el mundo pasa por alto, y está documentada en la página de gestión de costes de Claude Code de Anthropic, leída el 11 de agosto de 2026: la compactación tiene que leer todo lo que está resumiendo, así que cuanto mayor sea el desorden que compactas, más caro sale ese único comando. Limpiar no lee nada.

Dos comportamientos menores conviene conocerlos antes de elegir. Se puede dirigir la compactación, porque la misma página documenta que /compact seguido de una instrucción, en su ejemplo "Focus on code samples and API usage", le dice a Claude qué preservar en el resumen. Y la compactación tiene un suelo: en una sesión nueva, /compact imprime "Not enough messages to compact.", porque todavía no hay historial que resumir.

¿Cuándo empezar una sesión nueva en lugar de continuar?

La respuesta honesta es que la mayoría de los desarrolladores no tiene una regla fundamentada, y lo dice abiertamente. Una pregunta publicada en la comunidad r/ClaudeCode y reproducida en r/ClaudeCoding el 10 de agosto de 2026 lo plantea sin rodeos. El desarrollador que la hizo describe su propio criterio como "vibes: when it starts re-reading files it already read, or repeats a fix I rejected two turns ago, I bail and start over with a summary", esto es, abandona la sesión cuando el agente relee archivos que ya había leído o repite una corrección que él rechazó dos turnos atrás; añade que "compaction helps but the session is usually already degraded by the time it kicks in", que la compactación ayuda pero la sesión suele estar ya degradada cuando entra; y entonces hace la pregunta que no tiene respuesta publicada: si una sesión larga es peor de verdad, o si se ha acostumbrado a culpar a la sesión cuando la tarea estaba mal especificada desde el principio.

Esa última duda merece tomarse en serio, en vez de responderse con una seguridad que nadie tiene. Una forma útil de separar las dos causas: antes de limpiar, escribe en una línea qué intentas lograr y qué demuestra que terminaste. Si no consigues escribirlo, el problema no era la sesión, y la sesión nueva reproducirá el mismo deambular con contexto limpio. Si lo escribes con facilidad, el contexto cargaba peso que ya no sirve a la tarea, y limpiar es la corrección barata.

¿Por qué una sesión larga consume tanto aunque escribas poco?

Porque el tamaño de tu mensaje no es lo que se envía. Claude Code manda la conversación entera en cada petición y, en palabras de la propia documentación, "each time Claude uses tools it sends another request carrying that batch of tool results", cada uso de herramienta genera otra petición que carga ese lote de resultados, y por eso "a one-line question in a session that has been open all day still draws usage for the whole conversation", una pregunta de una línea en una sesión abierta todo el día sigue consumiendo por la conversación completa. Tu esfuerzo al teclear y tu consumo dejaron de tener relación hace horas.

Hay un segundo efecto que castiga justamente la forma en que la gente trabaja, que es a ratos con pausas de por medio. La misma página documenta que el primer mensaje tras una pausa mayor que la vida de la caché de prompt pierde la caché y reprocesa el contexto entero, y que esa vida es de una hora en suscripción, y baja a cinco minutos cuando pasas a usar créditos de uso, siendo cinco minutos también el valor por defecto con clave de API o proveedor de nube. Volver a una sesión grande después de comer sale, por tanto, más caro que continuarla antes de comer, y la documentación registra que definir ENABLE_PROMPT_CACHING_1H=1 mantiene la vida de una hora mientras usas créditos.

¿Un aviso de contexto es lo mismo que un aviso de límite de uso?

No, y confundirlos lleva a comprar un plan mayor cuando la solución era gratis. La orientación de Anthropic para desarrolladores es explícita al decir "a context or auto-compact warning: not a usage limit", un aviso de contexto o de compactación automática no es un aviso de límite de uso, y describe el caso como que la conversación se acercó a la ventana de compactación automática de la sesión, el punto donde Claude Code resume el historial antiguo para liberar espacio. Eso es una señal sobre la forma de una conversación, no sobre tu cuota restante del día.

El límite de uso es otro evento, con otras salidas, y escribimos sobre él aparte en qué hacer cuando llegas al límite de uso de tu agente de IA. La distinción corta que vale guardar: un aviso de contexto significa que esta conversación se puso pesada, y limpiar lo resuelve en un segundo; un límite de uso significa que tu ventana se agotó, y ningún comando arregla eso.

¿Qué se come tu contexto sin que te des cuenta?

Cuatro elementos de la misma documentación, y ninguno implica que tú escribas. Las tareas programadas se disparan en su intervalo aunque la sesión esté parada, enviando el contexto entero cada vez. Los mensajes entre sesiones se entregan como un turno nuevo cuando la sesión queda ociosa, mandando también el contexto completo, y pueden retenerse en su lugar definiendo crossSessionInbound como hold. Los compañeros de equipo de agentes siguen consumiendo tokens hasta que salen. Y los servidores MCP pesan por su listado de herramientas, motivo por el cual la documentación difiere las definiciones de herramienta MCP por defecto y recomienda preferir herramientas de línea de comandos como gh, aws, gcloud y sentry-cli, que no añaden ningún listado por herramienta.

Este es el argumento más fuerte para limpiar en vez de compactar cuando sueltas una tarea: una sesión ociosa no es una sesión gratis. Si otra cosa puede empujar turnos dentro de ella, dejarla abierta toda la tarde tiene un coste corriendo que ningún resumen elimina.

¿Cómo ver qué está llenando el contexto?

Claude Code responde a esto directamente con /context, que la documentación describe como mostrar qué está consumiendo espacio. En plan Pro, Max, Team o Enterprise, el desglose de /usage va más allá y señala comportamientos que representan el 10% o más de tu uso reciente, como contexto largo o pérdidas de caché, cada uno con un consejo para reducirlo. Entre los dos, se acaba la adivinanza: descubres si el peso es tu conversación, tu listado de skills o tus servidores MCP antes de decidir qué comando ejecutar.

Siendo precisos sobre lo que nuestra propia herramienta hace y lo que no hace aquí: CanvasCode, la app de Mac que ejecuta las CLIs oficiales de agente lado a lado en un solo canvas, muestra un anillo de uso por cuenta, una función presente en la aplicación desde CanvasCode versión 1.12, de junio de 2026, y eso responde cuánto queda de tu plan, no cuánto pesa la conversación actual. Para la segunda pregunta, /context dentro de Claude Code es el instrumento correcto, y nosotros no lo sustituimos.

¿Cómo limpiar sin perder el hilo?

Claude Code tiene un par documentado para esto: usa /rename antes de limpiar, para encontrar la sesión después, y /resume para volver a ella. Más allá de eso, el hábito que funciona es escribir tú mismo el traspaso, o pedírselo al agente, antes de limpiar: cuál es la tarea, qué se decidió, qué está hecho, qué viene después. Te quedas con las decisiones y sueltas el peso en tokens del camino hasta ellas.

Ejecutamos nuestra propia pipeline de contenido exactamente con esa forma, y eso es evidencia nuestra, no opinión. Se ejecuta tres veces al día en este sitio, y cada ejecución empieza sin ninguna memoria de la anterior. Lo que cruza entre ellas está escrito en vez de recordado, en dos lugares separados: un cuaderno de campo con las conclusiones curadas, limitado a 300 líneas y con 216 líneas el 11 de agosto de 2026, y un registro de las acciones que cada ejecución tomó, con el motivo de cada una. Tres arranques en frío al día funcionan porque el traspaso está escrito, no porque las sesiones sean largas. Una salvedad que no podemos resolver por ti: Anthropic no publica el umbral de tokens en el que se dispara la compactación automática, así que nadie, nosotros incluidos, puede decirte el tamaño exacto a partir del cual limpiar gana a compactar. Lo que sí puedes hacer es mirar /context y tratar los dos comandos como respuestas a preguntas distintas.