Gestión de contexto: No dejes que tenga amnesia ni que gaste todos tus tokens
📚 Navegación de la serie: El artículo anterior 18 Guía de uso de CLAUDE.md te enseñó a escribir las normas del proyecto en ese "manual de bienvenida". Este artículo va un nivel más arriba: ese manual, junto con tus conversaciones y los archivos leídos, se amontonan en un espacio de trabajo llamado "ventana de contexto". Cómo gestionar ese espacio y evitar llenarlo es de lo que hablaremos hoy.
Al empezar con Claude Code es muy fácil cometer un error bastante tonto.
Llegas a un proyecto mediano que no conoces y piensas "que se lea todo el repositorio primero para que entienda el panorama general", así que le sueltas: "Lee todos los archivos de este proyecto y luego explícame la arquitectura."
¿El resultado? Se pone a leer archivo tras archivo, la terminal no para de scrollear, y tras leer unos veinte archivos, se vuelve notablemente lento y torpe. Cuando le pides que arregle un bug en el login, va y te pregunta "¿En qué archivo está el módulo auth que mencionas?"... ¡un archivo que leyó hace diez minutos! Antes de terminar el trabajo, ya tiene "amnesia", y por el camino quemó un montón de tokens.
Cuando entiendes cómo funciona te das cuenta: la ventana de contexto no es "cuanto más llena, mejor"; si se llena, se vuelve más tonto. Hoy explicaremos a fondo esta "mesa de trabajo": qué es, qué pasa cuando se llena, cómo limpiarla con /compact y /clear, cómo ver su uso en tiempo real, y cómo ahorrar tokens desde la raíz.
Al terminar este artículo, sabrás:
- Una analogía que te hará entender perfectamente la "ventana de contexto", y qué ocurre exactamente cuando se llena.
- Cuándo usar
/compact(comprimir),/clear(limpiar) o abrir una nueva sesión (una tabla lo explica claramente). - Cómo usar
/contexty/usagepara vigilar las acciones que consumen contexto + resultados esperados. - Cinco hábitos diarios para ahorrar tokens (basados en errores reales).
- Entender qué hace por detrás el "auto-compact" (compresión automática), para que no te asuste cuando te interrumpa de repente.
01 La ventana de contexto: ¿De qué tamaño es la "mesa de trabajo" de Claude?
Primero, vamos a dejar claro el concepto más importante.
La ventana de contexto (context window) es la capacidad total de todo lo que Claude puede "ver" a la vez en esta sesión, medido en tokens (la unidad mínima de procesamiento de texto facturable).
No solo contiene lo que tú escribes, sino un montón de cosas. El documento oficial context-window.md lo detalla muy bien; aquí te lo traduzco a lenguaje cotidiano:
| Qué se pone en la mesa | Cuándo entra | Cuánto ocupa |
|---|---|---|
| Prompt del sistema (normas de comportamiento) | Al inicio, tú no lo ves | Un bloque fijo |
| Tu CLAUDE.md (global + proyecto) | Se carga todo al inicio | Depende del tamaño del archivo |
| Memoria automática (auto memory) | Se carga al inicio (con límite) | Medio |
| Cada frase que escribes | Entra conforme la envías | Suele ser poco |
| Cada archivo que lee | Se añade al leerlo | Lo más grande, lo que más gasta |
| Salida de comandos, resultados de herramientas | Se añade tras cada uso | Los logs/archivos grandes ocupan muchísimo |
¿Lo ves? Crees que la conversación es sobre todo "lo que tú dices", pero en realidad el grueso son los archivos que lee y la salida de los comandos. En la anécdota del principio, hacerle leer veinte archivos fue como llenar de golpe la mesa con otros planos, sin dejar apenas espacio libre para "trabajar".
Analogía: El tamaño de la mesa de trabajo. Piensa en Claude como en un carpintero trabajando en su banco de trabajo. La mesa tiene un tamaño fijo, y los planos, las herramientas, las piezas a medio hacer y las notas que le pasas tienen que caber todos encima de la mesa. Si la mesa es grande, puede atender muchas cosas a la vez; si se llena, tendrá que empujar y tirar los primeros planos para hacer sitio, y esa información "se le olvidará".
¿De qué tamaño es la mesa? Depende del modelo que uses. La mayoría rondan los 200k tokens, algunos (los marcados con [1m]) llegan al millón. Pero recordar esta frase es más útil que recordar números:
Por muy grande que sea la mesa, tiene límites, y cuanto más se llena, más tonto se vuelve.
💡 Resumen en una frase: La ventana de contexto es la mesa de trabajo de Claude; el bulto mayor no es lo que hablas, sino los archivos que lee; la mesa tiene límites, y al llenarse, la información más antigua se "cae" y se olvida.
02 Qué pasa cuando se llena: se ralentiza, se vuelve torpe e incluso tiene "amnesia"
Este es el juicio más importante de este artículo: el contexto no es "cuanto más mejor", cuando alcanza cierto nivel, el rendimiento de Claude cae a la vista.
¿Por qué? Porque cuantas más cosas hay en la mesa, más se dispersa la "atención" del modelo; cosas que se dijeron antes y que no tienen relación empiezan a interferir en la tarea actual. En la industria, a esto se le llama "degradación del contexto" (context rot).
¿Cómo saber que se ha degradado? He resumido los síntomas de primera línea, si ves alguno, ponte alerta:
- Empieza a contradecirse, olvida el plan que ya habíais acordado antes.
- Las respuestas se vuelven difusas y generales, pierde detalles y empieza a soltar obviedades.
- Te pregunta cosas que ya le has contestado repetidas veces (como el "¿en qué archivo está auth?" del inicio).
- Para una misma pregunta, lo corriges más de dos veces y sigue dando vueltas en círculo.
Por ejemplo, escribiendo un script de migración de datos, tras más de una hora de charla y pruebas, de repente volvió a proponer un enfoque erróneo que habíamos descartado en la primera media hora. No es que perdiera capacidad, es que su contexto estaba contaminado por una hora de basura de depuración.
¿Qué hace Claude si la mesa se llena de verdad? Hace una compresión automática (auto-compact, hablaremos en la sección 05). Aquí basta con saber esto: es un acto de autoprotección, no decides tú cuándo lo hace, y puede interrumpirte de repente en medio de una tarea importante.
Por eso la postura correcta es: No esperes a que comprima solo, gestiónalo tú proactivamente. ¿Cómo? Sigue leyendo.
💡 Resumen en una frase: Llenar el contexto provoca "degradación" (contradicciones, respuestas vagas, repeticiones); en vez de pelear corrigiendo en un contexto contaminado, es mejor que limpies tú proactivamente.
03 Las dos escobas: comprimir con /compact vs vaciar con /clear
Para limpiar la mesa, Claude Code te da dos escobas, con usos totalmente distintos, no las mezcles.
/compact: "empaqueta y aplasta" lo que hay, pero guárdalo
Lo que hace /compact (comprimir) es: coger esa larga charla de historial, resumirla en puntos clave, y reemplazar la charla literal por ese resumen, para luego seguir trabajando en la misma tarea.
Analogía: Recoger una mesa llena de bocetos y hacer una lista de viñetas en un folio. Has debatido con tu equipo durante dos horas, la mesa está llena de bocetos descartados. /compact convierte esos bocetos en un folio de "Decidimos A, descartamos B, paso siguiente C", liberando la mesa pero conservando las conclusiones.
Un punto clave: puedes darle instrucciones sobre qué quieres que priorice al conservar:
/compact conserva las decisiones de arquitectura del login y el formato de la API acordado, descarta los intentos fallidos de depuraciónEl ejemplo oficial en costs.md es /compact Focus on code samples and API usage (Céntrate en ejemplos de código y uso de la API). Es la misma idea.
Cuándo usar /compact: Cuando la tarea no está terminada y el contexto se va llenando, pero lo que se ha hablado antes se necesitará luego. Por ejemplo, estás a mitad de una funcionalidad, las decisiones arquitectónicas del principio no se pueden perder, pero puedes tirar todos los outputs de comandos fallidos de en medio.
/clear: vacía por completo, empieza de cero
/clear (limpiar) es mucho más bestia: borra todo el historial de la charla, como si empezaras una sesión totalmente nueva.
Pero no te asustes: /clear no toca tu CLAUDE.md ni la memoria automática. Esas cosas se recargan solas en la nueva sesión. Lo que pierdes es solo "lo que has charlado en esta vez"; las normas del proyecto y los recuerdos a largo plazo siguen ahí.
Analogía: Cambiar a una tarea totalmente distinta, recoges todo y dejas la mesa vacía antes de empezar. La tarea anterior ya está, la nueva no tiene nada que ver; vaciar la mesa es mucho más limpio que arrastrar el ruido de la anterior.
La documentación oficial en costs.md recomienda textualmente: al cambiar a tareas no relacionadas, usa /clear para empezar de nuevo, porque "el contexto viejo gasta tokens inútilmente en cada mensaje nuevo".
Aquí te dejo una regla de oro: si corriges el mismo fallo dos veces y sigue sin entenderlo, no pierdas el tiempo en esta sesión, haz /clear directamente, y usando lo que has aprendido en los dos intentos fallidos, escribe un prompt mejor y empieza de cero. Mesa limpia + mejor prompt gana casi siempre a seguir discutiendo en un contexto contaminado. Es la lección más valiosa tras horas de pruebas.
💡 Resumen en una frase:
/compactes "aplastar pero conservar",/cleares "vaciar todo para otra tarea"; si corriges algo dos veces sin éxito, no lo dudes: haz/clear.
04 Control del uso: usa /context y /usage para ver cuánto sitio queda
Intentar adivinar "si ya casi está lleno" es magia negra. Claude Code tiene dos comandos para ver los números reales, no te confundas entre ellos.
/context: para ver de qué está llena la mesa
/context/context te muestra una gráfica de barras de colores con el uso en tiempo real del contexto, desglosado por categorías: cuánto ocupa el prompt del sistema, cuánto el CLAUDE.md, cuánto cada servicio MCP, cuánto el historial... y da consejos para optimizarlo. El context-window.md oficial es claro: si quieres saber cuánto contexto estás gastando en cualquier momento, ejecuta /context.
Un hábito muy recomendable: antes de empezar una tarea grande, ejecuta /context para ver la base. Si ves que un servicio MCP ocupa muchísimo o que tu CLAUDE.md está gordísimo, límpialo antes de empezar.
También existe el comando
/memory, que sirve para comprobar qué CLAUDE.md y archivos de memoria automática se cargaron al inicio; úsalo cuando sospeches que ha "recordado mal" algo.
/usage: para ver cuántos tokens/dinero llevas quemados
/usageEl bloque "Session" de /usage te da estadísticas de tokens consumidos en la sesión actual, junto con una estimación de dólares (calculada localmente). El aspecto oficial según costs.md es algo así:
Total cost: $0.55
Total duration (API): 6m 19.7s
Total duration (wall): 6h 33m 10.2s
Total code changes: 0 lines added, 0 lines removedExplicación de la salida: Total cost es el coste estimado (el real te lo da la Claude Console); Total duration (API) es el tiempo que el modelo ha estado calculando; Total duration (wall) es el tiempo que llevas con esta sesión abierta.
⚠️ Nota: Para usuarios con suscripción Pro / Max, el coste está incluido, así que esa cifra en dólares no afectará a tu factura, solo mírala para hacerte una idea de la magnitud. De precios hablamos en el capítulo 06; hoy miramos los tokens desde el punto de vista del "contexto".
¿Te da pereza escribirlo cada vez? El sistema permite dejar este dato fijo en la barra de estado (statusline) para verlo siempre. La forma de hacerlo viene en la documentación oficial de statusline, no la detallamos aquí.
💡 Resumen en una frase:
/contextte dice "qué ocupa la mesa",/usagete dice "cuántos tokens/dólares llevas"; antes de una tarea grande, lanza un/contextpara revisar.
05 Compresión automática (auto-compact): te salvará la vida, pero no confíes en ella
He mencionado varias veces la "compresión automática", vamos a ver qué es exactamente.
El auto-compact (compresión automática) es un mecanismo de autoprotección de Claude Code: cuando el contexto está a punto de llegar al límite, automáticamente resume el historial de chat para hacer espacio y evitar que te salte un error y el programa se cuelgue. El documento oficial costs.md lo pone junto al prompt caching como una de las dos formas de "optimización automática de costes".
Analogía: Descarga automática en una cadena de montaje. La cinta casi está llena, así que el sistema empaca la basura para que no se atasque todo. Tú no haces nada, salta solo.
Suena muy bien, pero te aconsejo que no dependas de él por dos razones:
Primera: no decides cuándo salta. Puede que estés en medio de un paso crítico, la mesa se llene y de pronto ¡zas!, se detiene a comprimir; te rompe todo el ritmo.
Segunda: es una compresión "a ciegas". Se lanza en el momento en que el contexto está más lleno y el modelo más tonto. El sistema decide qué tirar y qué guardar, y es muy posible que tire datos que tú considerabas cruciales.
Así que lo correcto es ser proactivo: cuando notes que la charla se alarga y /context marca un uso alto, lanza tú mismo un /compact y dale instrucciones de qué mantener. La compresión proactiva tiene dos ventajas: decides cuándo y decides qué.
Todavía mejor: escribe tus preferencias de compresión directamente en tu CLAUDE.md. El costs.md oficial recomienda añadir este bloque en tu CLAUDE.md:
# Compact instructions
When you are using compact, please focus on test output and code changes(Cuando uses compact, céntrate en los resultados de las pruebas y en los cambios de código)
Así, en cada compresión (ya sea manual o automática), priorizará lo que le has dicho, es como ponerle un seguro a la compresión automática. Si en los proyectos que más usas pones "al comprimir, mantén las decisiones arquitectónicas acordadas y los contratos de la API", te ahorrarás tener que repetirlo a mano cada vez.
💡 Resumen en una frase: El auto-compact te salva la vida, pero te interrumpe y puede borrar cosas importantes; es mejor hacer un
/compacta mano o dejar las preferencias escritas en CLAUDE.md.
06 Cinco trucos para ahorrar tokens: evita que la mesa se llene rápido
Limpiar la mesa es poner un parche; evitar que se llene tan rápido es la solución real. Aquí tienes cinco trucos de uso diario, pensados para proteger el contexto (no importan los precios, sirven igual).
Truco 1: Usa proyectos pequeños para practicar. Como decíamos en el artículo 07, en la fase de aprendizaje, crea un proyecto "de juguete" con tres o cinco archivos. Son pocos archivos, leerlos ocupa poco, la mesa está limpia y ves bien qué hace. El error del principio ("leer 20 archivos y volverse amnésico") viene de coger un repositorio grande sin conocer la herramienta.
Truco 2: Usa @ para apuntar a un archivo, no lo mandes a buscar por todo el proyecto. En vez de "arregla el bug del login" y que él busque dónde está, dile @src/api/auth.ts arregla el problema del 401. El costs.md oficial es rotundo: las peticiones ambiguas provocan escaneos amplios, las peticiones precisas lo hacen trabajar de forma eficiente tocando pocos archivos. El @ clava su atención en ese archivo exacto.
Truco 3: No le tires cien cosas a la vez. Darle cinco tareas sin relación de golpe hará que lea demasiados archivos y que sus respuestas inunden la mesa. Divide en cinco peticiones pequeñas, hazlas una a una, y la mesa seguirá limpia.
Truco 4: Divide las tareas largas, y comprime por partes. No pretendas que aguante toda una gran funcionalidad en la misma sesión. Acabas una parte lógica, /compact; pasas a una zona totalmente distinta, /clear y empiezas otra vez.
Truco 5: Pasa las tareas muy verborreicas a los Subagents (subagentes). Correr tests, leer miles de logs, consultar documentación... este tipo de cosas que devuelven salidas gigantes, delégalas a un subagente: él trasteará en su propia mesa de trabajo (contexto independiente), y solo se traerá un resumen a tu sesión principal. El documento context-window.md cuenta cómo un subagente leyó 6100 tokens, pero al volver al contexto principal solo ocupó 420. Hablaremos a fondo de los subagentes en su artículo correspondiente.
Para ver dónde debes esforzarte, mira la diferencia entre "parchear" y "prevenir":
| Acción | Tipo | Cuándo |
|---|---|---|
/compact | Parche: comprimir pero conservar | Tarea sin acabar, contexto alto, necesitas lo anterior |
/clear | Parche: limpiar y empezar de 0 | Tarea sin relación, o mucha contaminación |
| Nueva sesión directa (salir y volver a entrar) | Prevención: mesa inmaculada | Quieres limpieza absoluta, ni rastro de esta vez |
@ para apuntar archivos | Prevención: lee menos archivos | Debes hacerlo CADA vez que pides algo |
| Proyectos pequeños para probar | Prevención: menos origen | Fase de aprendizaje o experimentación |
| Subagentes para tareas sucias | Prevención: aísla los outputs | Tests / lectura de logs / documentación |
💡 Resumen en una frase: Limpiar es un parche, lo que cuenta es prevenir leyendo menos archivos, partiendo tareas y usando subagentes; el hábito más importante que puedes coger es usar
@para apuntar a los archivos al hacer tu petición.
07 Manos a la obra: experimenta el ciclo de contexto en tres pasos
Leer no sirve para memorizar. Vamos a hacer un proceso muy simple para que veas con tus ojos cómo sube el uso y cómo /compact lo aplasta. Abre claude en cualquier proyecto y haz esto.
Paso 1: Mira la línea base al empezar
Al abrir Claude, lo primero que debes escribir es:
/contextResultado esperado: La terminal te mostrará el uso desglosado. Verás que el prompt del sistema, el CLAUDE.md y algo de memoria ya ocupan una parte (es normal tener uso antes incluso de hablar). También te dará el uso total y algunos consejos. Apunta este número inicial.
Paso 2: Métele a propósito mucho texto y vuelve a mirar
Pídele que lea cosas y conteste, por ejemplo:
Lee los archivos principales de este proyecto y explícame la arquitectura generalCuando termine de leer y hablar, vuelve a poner:
/contextResultado esperado: Verás que el uso se ha disparado, las barras de "historial de conversación" y de "archivos leídos" serán enormes. Esto es el "llenar la mesa de trabajo" en tiempo real.
Paso 3: Usa /compact para aplastar ese consumo
/compact mantén las conclusiones sobre la arquitectura general del proyecto, y descarta el contenido crudo archivo por archivoResultado esperado: La terminal te dirá algo como "Conversation compacted" (Conversación comprimida), se hace en segundo plano, no te soltará el resumen en la cara. Vuelve a escribir /context para verlo. El bloque del "historial de conversación" debería haber bajado radicalmente: recuerda las conclusiones, pero todo el volumen de los bytes crudos de los archivos se ha esfumado a favor del resumen.
Comprobación cruzada: Has comprobado el antes y el después con /context. Si quieres verificar que no tiene "amnesia", pregúntale: "¿Cuál me dijiste que era la estructura del proyecto?"; verás que sabe contestarte.
⚠️ Detalle importante: Comprimir es una operación con pérdida. Se queda con lo importante y el hilo, pero los outputs literales de las herramientas que usó se tiran a la basura. Así que las conclusiones realmente valiosas, es mejor que las metas en CLAUDE.md siguiendo las prácticas del capítulo 18: pídele "añade esto a CLAUDE.md" o hazlo tú con
/memory. Es más seguro que dejar que las "aplaste" el compact.
💡 Resumen en una frase: Haz un ciclo
/context→ meter texto →/compact→/context, para que experimentes en primera persona cómo sube el contexto y cómo/compactlo reduce; comparando los tokens antes y después, sabrás que funciona.
08 Resumen
En este artículo hemos destripado la mesa de trabajo de Claude, la "ventana de contexto":
| Lo que has aprendido | En una frase |
|---|---|
| Qué es la ventana de contexto | La mesa de Claude, el volumen principal son los archivos que lee, no lo que hablas |
| Qué pasa si se llena | Sufre degradación: se vuelve lento, general, se contradice y se olvida de cosas |
/compact | Empaqueta y aplasta para seguir usándolo, puedes indicarle qué guardar |
/clear | Limpia por completo para una tarea nueva, no afecta al CLAUDE.md ni a la memoria a largo plazo |
/context y /usage | El primero para ver "qué ocupa sitio", el segundo para ver "cuántos tokens van" |
| Auto-compact | Mecanismo salvavidas automático, pero te interrumpe y puede borrar lo clave; mejor adelantarte tú |
| Ahorrar tokens | Proyectos chicos, apuntar con @, no agobiarle, dividir tareas, usar subagentes |
A partir de ahora podrás: Entender qué tiene Claude encima de la mesa, saber por qué se vuelve tonto si la llena; comprimir con /compact cuando debas, hacer /clear cuando toque; mirar el /context y el /usage; y desde la primera palabra que escribas, aplicar hábitos que ahorran tokens para que su mesa de trabajo esté siempre lista para las cosas importantes.
A fin de cuentas, la esencia de la gestión del contexto es una sola: usar la atención limitada de Claude en las cosas que realmente valen la pena.

Esta imagen compara la ventana con una mesa: si se llena (al 92%), usas /compact para aplastar la charla en unos puntos clave (para seguir trabajando), o /clear para barrer toda la mesa (para empezar de cero); uno salva la información y el otro te da limpieza.
El próximo artículo será 20 "Configuración de permisos": En este artículo hemos gestionado "lo que recuerda", en el próximo gestionaremos "lo que se atreve a hacer". A la hora de leer, modificar código o ejecutar comandos, ¿qué debe preguntarte y qué puede hacer solo? ¿Cómo hacer unas reglas que sean cómodas y seguras? Te dejo una pregunta para pensar: ¿Estarías dispuesto a dejar que haga un git push sin tu permiso?