Obsesión con 200k tokens: por qué mi status line es lo más importante de mi terminal

Hay un número que miro más que cualquier otro en mi pantalla: el uso de contexto del modelo. No las líneas de código, no los tests pasando, no el consumo de la VM. Los tokens. Porque cuando pasas de cierto umbral, para mí está alrededor de los 200k, todo empieza a degradar. No explota. No tira error. Se vuelve impreciso, repite cosas que ya decidiste, pierde el hilo de conversaciones que tuviste hace veinte turnos. Es sutil, y por eso es peligroso.

Mi metodología entera gira alrededor de esto. Divide y conquistarás. Cada tarea grande se parte en chunks chicos. Cada agente especializado, developer, architect, tester, corre en su propio contexto, aislado. El orquestador coordina pero no acumula todo el trabajo en un solo contexto gigante. Y la pregunta obvia es: ¿cómo sé cuánto contexto estoy usando en cada momento?

El status line.

Qué muestra mi status line

Claude Code tiene una opción que casi nadie configura: el status line. Es una línea en la parte inferior de la terminal que puede mostrar lo que quieras. La mía se ve así:

[mi-proyecto@dev-vm] [opus 111k/105k/1000k] [development]

Tres bloques de información. El primero es el proyecto y la máquina donde estoy. El segundo es el modelo activo con tres números de contexto: tokens totales en uso, tokens en caché, y ventana máxima. El tercero es la rama de git.

Los tres números del medio son lo que más miro. Es un medidor de combustible. Tokens en uso es cuánto lleva consumido la sesión. Tokens en caché es lo que persiste entre turnos, lo que el modelo "recuerda" eficientemente. Ventana máxima es el techo. Cuando el primero se acerca demasiado al tercero, es hora de parar.

Claude Code no te muestra el nombre del proyecto por defecto. Cuando tienes diez proyectos abiertos en distintas terminales, eso importa. Más de una vez confundí en qué proyecto estaba y le pedí al modelo algo que no tenía sentido en ese contexto. El nombre del proyecto en el status line eliminó ese error.

Divide y conquistarás: por qué el contexto es todo

El principio es simple y lo repito hasta el cansancio: cada token que el modelo tiene cargado es un token menos para pensar en tu problema. Si le metes el proyecto entero, toda la documentación, todo el historial de la conversación, el modelo tiene menos espacio mental para razonar sobre lo que le estás pidiendo.

Mi enfoque: agentes especializados, cada uno con su propio contexto. El developer solo ve el código que necesita. El architect solo ve la estructura. El tester solo ve los tests y el código bajo prueba. Ninguno arrastra el contexto de los demás. El orquestador los coordina sin acumular su trabajo, delega, recibe resultados, y sigue.

Cuando una sesión empieza a acercarse a 200k, paro. Empiezo sesión nueva. El status line me avisa antes de que sea tarde, veo los números subir y tomo la decisión de cortar antes de que el modelo degrade. A veces es frustrante, porque estás en medio de algo y no quieres perder el momentum. Pero aprendí por las malas: las peores decisiones que vi tomar al modelo fueron en sesiones donde el contexto estaba al límite y nadie se dio cuenta. Bugs sutiles, archivos editados que no debían tocarse, instrucciones que se "olvidaron" a mitad de camino.

No es paranoia. Es algo que aprendí a fuerza de experiencia: la degradación del contexto es el error más caro y más invisible que existe cuando trabajas con LLMs.

La rama de git no es decoración

La rama de git en el status line parece información obvia. Pero cuando tienes deploy automatizado, deja de ser un dato pasivo y se convierte en una declaración de intención.

Mi flujo funciona así: development tiene push directo y deploy automático a staging. Cada push a esa rama actualiza el ambiente de pruebas en segundos. production requiere pull request, no puedo hacer push directo, tengo que parar, revisar, y mergear conscientemente. Cuando el merge ocurre, producción se actualiza automáticamente. main es para releases estables.

Si estás en production y haces push de algo que no debías, los usuarios lo ven en segundos. No hay margen. De hecho, tengo un hook que bloquea pushes directos a production, si el modelo o yo intentamos hacer push a esa rama, el sistema lo rechaza. Solo se puede llegar a production vía pull request. Es otra capa de enforcement determinístico, como los hooks que mencioné en posts anteriores: no dependo de recordar la regla, el código la ejecuta por mí.

La palabra "development" o "production" en mi status line no es solo un nombre de rama, es literalmente qué ambiente estoy afectando con cada cambio. Esa diferencia visual constante cambia cómo tomas decisiones.

No es la estrategia de ramas que usaría un equipo de veinte personas con code review formal y pipelines complejos. Es pragmática, diseñada para un solo técnico manejando múltiples proyectos. Development es tu campo de pruebas con deploy instantáneo. Production es donde piensas dos veces.

El hostname: dónde estoy parado

Trabajo con varias máquinas. Una workstation donde programo, navego, uso el IDE. Una VM de desarrollo conectada por SSH donde corren los agentes de Claude Code. Y un servidor de producción donde viven los containers.

El hostname después del @ en mi status line me dice dónde estoy. Parece trivial hasta que llevas tres horas con cuatro terminales abiertas y tu cabeza ya no distingue cuál es cuál.

La VM de desarrollo tiene acceso controlado al entorno de producción, protegido con GPG y el comando pass de Linux. No puedo acceder a los containers de producción sin desbloquear la contraseña primero. Eso es intencional: una barrera deliberada para que no toque producción por accidente. Cuando necesito chequear logs de staging, accedo sin problemas. Cuando necesito tocar producción, el sistema me obliga a pensar un segundo extra. Ese segundo importa.

50 containers, 19 stacks, una persona

Manejo 50 containers corriendo en simultáneo, organizados en 19 stacks. Cada stack es un proyecto o servicio independiente. Todo con deploy automático desde git, reverse proxy con SSL automático, dominios por ambiente.

No necesitas un equipo de DevOps para esto. Lo que necesitas es estandarización: cada proyecto sigue el mismo patrón de ramas, el mismo flujo de deploy, la misma estructura de containers. Una vez que armas el patrón la primera vez, replicar es copiar y pegar. El stack número 19 se configura exactamente igual que el primero.

El status line cierra el loop. Cuando estoy en un proyecto específico, veo el nombre, la máquina, cuánto contexto queda, y qué rama, y por lo tanto qué ambiente, estoy afectando. Todo en una línea. Multiplicado por 19 stacks, es la diferencia entre operar con conciencia y operar a ciegas.

Cómo armar el tuyo

Claude Code tiene un comando que te resuelve esto directamente: /statusline. Lo escribes en la terminal, le describes lo que quieres ver, y te genera la configuración. Así de simple.

Lo que yo hice fue decirle algo como: "Quiero un status line que muestre el proyecto actual con el hostname, el modelo activo, uso de contexto en formato Xk/Yk/Zk, y la rama de git, todo con colores." Me generó un script bash que recibe JSON por stdin, extrae los campos que le pedí con jq, y los formatea con colores ANSI. Lo dejó funcionando en un intento.

Después fui iterando. Primero mostraba costos de billing, le pedí que los cambiara por tokens de contexto, que es lo que realmente me importa. Después agregué el hostname porque me di cuenta de que necesitaba saber en qué máquina estaba. Cada cambio fue una conversación: "Cámbiame esto por esto otro" y listo.

Lo que pasa por debajo es sencillo: en el settings.json de Claude Code defines statusLine.type: "command" y apuntas statusLine.command al script que te generó. Claude Code le pasa al script un JSON con todo, modelo activo, uso de contexto, workspace, costos. Tu script extrae lo que te interesa y devuelve la línea formateada. No necesitas entender cada campo del JSON; le dices a Claude qué quieres ver y él se encarga de parsearlo.

Si no te gusta cómo queda, le pides ajustes. Si quieres agregar algo nuevo, la hora, el estado de Docker, lo que sea, se lo describes y te lo agrega. Es una de esas cosas donde Claude Code se configura a sí mismo, y el resultado es exactamente lo que necesitas porque tú lo definiste en lenguaje natural.

Supervisión, no automatización ciega

El status line es una línea de texto. Pero representa algo más profundo: la diferencia entre automatizar y supervisar.

Tengo deploy automático, agentes que escriben código, hooks que validan reglas, scripts que formatean y bloquean operaciones peligrosas. Todo eso funciona sin que yo intervenga. Pero la decisión de cuándo parar una sesión, cuándo cambiar de rama, cuándo cortar y empezar de nuevo, esa sigue siendo mía.

Cuando manejas esta escala, decenas de proyectos, decenas de containers, múltiples máquinas, agentes de IA ejecutando tareas, la conciencia de dónde estás parado no es opcional. Es supervivencia. Y esa conciencia empieza con tener la información correcta visible todo el tiempo, sin tener que buscarla.

Si te sirvió, vuelve cuando publique algo nuevo. Sin calendario fijo, sin pretensiones. Solo lo que voy aprendiendo mientras construyo.