El problema no es que uses mucho Claude Code
Hay una sensación bastante común cuando empiezas a trabajar en serio con Claude o con Claude Code: miras el contador, ves que te has fundido media cuota y juras que no has hecho nada especial. Un par de preguntas, una corrección tonta, otra vuelta porque no ha entendido del todo lo anterior, y de repente ya estás pensando en límites, resets y en si de verdad compensa pagar por esto.
La frustración es lógica, porque desde fuera parece que has intercambiado diez mensajes sin más. El problema es que por dentro no está pasando eso. Lo que está pasando es bastante más caro.
La décima respuesta no cuesta como la primera
La idea clave de todo esto es muy simple: el modelo no ve solo tu último mensaje. Cada vez que le escribes, vuelve a leer el contexto relevante de la conversación entera. Eso significa que el mensaje número diez no suele costar como el primero. Puede costar muchísimo más. De hecho, en mediciones reales, una décima interacción puede salir aproximadamente once veces más cara que la primera.
Y esto no es una teoría sacada de la manga ni una exageración para hacer un vídeo más dramático. Sale de mirar uso real, consumo real y cómo crecen las sesiones cuando encadenas petición tras petición sin limpiar nada. El contador no sube porque sí. Sube porque cada nuevo turno arrastra todo lo anterior.
En cuanto entiendes esto, dejas de pensar en Claude Code como un chat normal y empiezas a verlo como una sesión con peso acumulativo. Y ahí cambia bastante la forma de trabajar.
El contexto no solo cuesta dinero, también empeora
Aquí entra otra idea importante: las sesiones largas no solo gastan más, también suelen rendir peor. Llega un punto en el que notas que el agente empieza a desviarse, mezcla decisiones antiguas con las nuevas, insiste en cosas ya corregidas o propone arreglos cada vez más torpes. Es lo que mucha gente llama context rot.
No es magia negra. Si tienes una conversación enorme, con pruebas, correcciones, intentos fallidos, instrucciones que ya no aplican y media docena de objetivos que han ido cambiando, el modelo tiene más ruido que señal. Y cuanto más ruido, peor calidad. Pagas más para obtener respuestas menos finas. Mala combinación.
Por eso una de las mejores costumbres que puedes coger no tiene nada de glamur: cerrar sesiones antes de que se pudran.
Trabaja por bloques, no por conversación infinita
Lo que mejor me está funcionando es tratar cada sesión como una unidad pequeña de trabajo. Se hace una tarea concreta, se valida, se deja un resumen limpio de lo importante y se empieza otra sesión cuando toca seguir. Ese resumen es clave porque te permite hacer un handoff sin cargar otra vez con todo el barro de la conversación anterior.
Si el objetivo cambia, si ya has arreglado una parte y vas a pasar a otra distinta, o si notas que Claude empieza a responder raro, no intentes rescatar una sesión moribunda durante veinte mensajes más. Sale más barato y suele salir mejor cortar, resumir y reabrir en limpio.
Esto además obliga a pensar mejor. En vez de improvisar cien microcorrecciones, preparas el siguiente bloque con algo más de intención.
Edita el prompt, no te pongas a regañarle
Esta es otra costumbre que ahorra mucho más de lo que parece. Si has escrito una instrucción y ves que estaba mal enfocada, no sigas encadenando mensajes del estilo “no, así no”, “me refería a esto”, “pero sin tocar lo otro”, “espera, mejor hazlo de esta manera”. Esa secuencia mata sesiones.
Sale bastante mejor editar la petición original o reformularla de forma limpia en el siguiente turno, con todo lo necesario bien explicado desde el principio. Corregir a base de coletillas consume contexto y además introduce contradicciones. Luego el agente tiene que decidir cuál de tus cinco versiones pesa más, y ahí empiezan los inventos.
Cuanto menos tengas que deshacer dentro de la propia conversación, menos tokens tiras y más consistencia mantienes.
Junta peticiones cuando tenga sentido
También ayuda mucho dejar de trabajar a golpe de mensaje impulsivo. Hay veces que hacemos tres o cuatro turnos seguidos para pedir cosas que podrían ir perfectamente juntas: “revisa esto”, luego “ten en cuenta tal archivo”, luego “ejecuta también los tests”, luego “y explícame el motivo”. Cada turno añade sobrecoste.
Si ya sabes lo que necesitas, compáctalo en una sola instrucción bien pensada. No por escribir más largo una vez vas a gastar más que repartiendo la misma información en cuatro idas y vueltas. Normalmente pasa justo lo contrario.
No todo necesita el modelo caro
Otro error bastante habitual es tirar siempre del modelo más potente para todo, como si estuviéramos compilando una tesis en cada prompt. Hay tareas que sí lo justifican: refactors delicados, debugging complejo, planificación de una feature grande o cambios que afectan a muchas piezas. Pero para consultas simples, pequeñas transformaciones, búsquedas o tareas mecánicas, usar un modelo más barato tiene todo el sentido del mundo.
La diferencia de coste se nota rápido, sobre todo cuando trabajas muchas horas al día. Y muchas veces la diferencia práctica en calidad para esas tareas menores es mínima. Reservar el modelo caro para lo difícil es de las decisiones más aburridas que puedes tomar, pero funciona.
/rewind y /btw no son adornos
Hay dos comandos que encajan muy bien con esta idea de higiene de sesión: /rewind y /btw.
/rewind es útil cuando ves que acabas de meter la conversación en un callejón raro y prefieres volver a un punto anterior antes de seguir acumulando basura. En vez de seguir parcheando encima del caos, vuelves atrás y rehaces desde un estado más limpio.
/btw, usado con cabeza, viene bien para dejar notas breves o aclaraciones que no deberían convertirse en una nueva maraña de instrucciones largas. No te salva una mala sesión por sí solo, pero sí ayuda a mantener un hilo más ordenado cuando ya entiendes que cada palabra arrastrada tiene coste.
Tu CLAUDE.md no debería ser un vertedero
Muchísima gente descubre CLAUDE.md, se emociona y acaba metiendo ahí medio manual de operaciones de la empresa. Resultado: contexto fijo inflado antes incluso de empezar a trabajar. Si el archivo está cargado de reglas duplicadas, ejemplos irrelevantes, preferencias antiguas o documentación que apenas aplica, estás pagando peaje desde el minuto uno.
Un CLAUDE.md bueno no es el más largo. Es el más útil por token. Tiene que contener reglas estables, convenciones realmente importantes, comandos frecuentes y contexto estructural del proyecto. Lo demás, fuera o en documentos aparte que solo se traigan cuando hagan falta.
Lo mismo aplica a la documentación auxiliar. Si puedes tener docs resumidas, cacheadas y en markdown, mejor. Un markdown limpio se integra mucho mejor en el flujo que un PDF enorme lleno de ruido visual y texto que el modelo va a digerir peor. Cuanto más directo sea el material que le das, menos desperdicio.
Patrocinador, pero con bastante sentido aquí
En este punto encaja bastante bien mencionar al patrocinador porque va relacionado con cómo trabajas el día a día. Si estás montando flujos con agentes y no quieres pelearte con infraestructura, MyClaw te deja levantar OpenClaw ya preparado en servidor y gestionarlo desde web, sin tener que dedicar tiempo a dejar una máquina encendida en casa o a montar todo a mano.
Lo interesante no es solo la comodidad. También encaja bien con esta idea de tener sesiones más ordenadas, automatizaciones más claras y un entorno donde separar mejor qué hace cada agente y con qué contexto trabaja. Si estás en esa fase de tomarte en serio herramientas tipo Claude Code, OpenClaw y automatización alrededor, es de esas cosas que tienen bastante más sentido práctico del que parece al principio.
No uses PDFs si puedes evitarlo
Esto parece una tontería, pero no lo es. Mucha gente le mete un PDF porque es “la documentación oficial” y se queda tan tranquila. Luego se sorprenden de que el contexto suba, de que tarde más y de que el modelo se agarre a fragmentos raros.
Si tienes la posibilidad de convertir esa documentación a markdown, resumirla o mantener una versión ya preparada para tus flujos habituales, hazlo. No solo por coste. También por calidad. Claude trabaja mejor cuando el material está limpio, segmentado y pensado para ser reutilizado.
Mira el uso, no trabajes a ciegas
La última parte es la menos sexy y probablemente la más útil: monitoriza. Mira qué sesiones se disparan, qué tipo de tareas te drenan más, en qué momento empieza a caer la calidad y qué hábitos te hacen gastar de más. Si no miras eso, es muy fácil pensar que el problema es “Anthropic me limita demasiado” cuando en realidad tu flujo está metiendo contexto innecesario por todos lados.
Cuando empiezas a observarlo de verdad, ves patrones enseguida. Las sesiones largas y caóticas son caras. Las correcciones encadenadas son caras. Los archivos de instrucciones hinchados son caros. Los documentos pesados son caros. Y casi siempre, todo eso además empeora la respuesta.
La conclusión importante
La mayoría de gente que siente que Claude Code le dura poquísimo no está imaginándolo. Muchas veces le dura poco de verdad. Pero no porque haya usado demasiado la herramienta, sino porque la ha usado con una mecánica que multiplica el coste en silencio.
En cuanto entiendes que cada turno relee contexto, que una sesión larga se pudre, y que la higiene de trabajo importa tanto como el prompt, empiezas a recuperar control. Editas en vez de corregir. Trabajas por bloques. Haces handoff con resúmenes. Eliges mejor el modelo. Recortas CLAUDE.md. Tiras de markdown en vez de PDFs. Usas /rewind cuando toca. Y vigilas el consumo como lo que es: una señal del flujo, no solo una cifra molesta en pantalla.
Todo esto sale de uso real y de datos medidos, no de inventarse cuatro consejos bonitos. Y sinceramente, se nota bastante cuando lo aplicas unos días seguidos.
Nos vemos en el próximo post.
¿Qué te ha parecido?
Déjame tu opinión, pregunta o sugerencia. Los comentarios se sincronizan con GitHub Discussions .