Gastar menos tokens

Qué es y por qué importa

Un token es un trocito de texto: es la unidad con la que se mide cuánto trabaja el modelo. Cada mensaje que envías, cada archivo que Claude lee, cada respuesta y cada razonamiento consumen tokens. Con una suscripción cuentan para tus límites de uso. Con la API acaban en la factura.

Lo que al principio no había entendido es esto: con cada mensaje, Claude Code le reenvía al modelo toda la conversación, no solo tu última frase. La caché abarata esa relectura, pero no la deja a cero. Así que un chat largo cuesta más con cada pregunta, aunque la pregunta sea de una línea.

La segunda: el grueso del despilfarro no es el modelo que eliges, son las vueltas en vacío. Escribes una petición vaga, Claude hace otra cosa, tú dices «rehazlo», él lo relee todo y vuelve a intentarlo. Cada vuelta se paga.

1. Chats cortos, archivos largos

Las decisiones importantes no las dejo en el chat. Las escribo en un archivo del proyecto. Yo lo llamo DECISIONES.md, pero el nombre lo eliges tú. Dentro va poca cosa: qué hemos decidido, por qué y qué falta.

Cuando el chat se alarga, o cuando paso a un trabajo que no tiene nada que ver, lo cierro y abro uno nuevo. En Claude Code se hace con /clear: vuelves a empezar con una conversación vacía, y los archivos del proyecto se quedan donde están.

Antes de cerrar escribo:

Actualiza DECISIONES.md con lo que hemos decidido hoy y lo que falta.

Luego /clear, y en el chat nuevo:

Lee DECISIONES.md y sigue desde ahí.

Así el chat nuevo arranca ligero, solo con lo que hace falta, en lugar de arrastrar horas de intentos, errores y mensajes superados. Si un chat viejo te importa, no lo pierdes: con /resume vuelves a él.

Una nota sobre CLAUDE.md, el archivo de instrucciones que Claude Code carga solo en cada sesión. Ahí pongo solo las reglas que valen siempre y lo mantengo corto, porque entra en cada sesión aunque no haga falta. Las decisiones del día van en DECISIONES.md, que Claude lee cuando se lo pides.

2. No pegues los logs

Un log es el registro de lo que hace el programa mientras se ejecuta: errores, avisos, mensajes. A menudo son cientos o miles de líneas. Si las pegas en el chat, entran todas en la conversación y se quedan ahí. Y como la conversación se reenvía con cada mensaje, esas líneas las vuelves a pagar en cada pregunta siguiente.

Yo ya no pego nada largo. Le digo a Claude dónde está el archivo, o le pido que lance él el comando, y le pido que vuelva solo con lo que importa:

Lee logs/server.log y encuéntrame el error: dime solo las líneas que importan.

Lanza tú los tests y mira la salida: dime qué falla y por qué.

Algo que conviene saber: lo que Claude lee también entra en el chat. La ventaja es que él puede buscar dentro del archivo y leer solo los trozos útiles, en lugar de tragárselo todo como cuando pegas tú. Si la salida es enorme de verdad, como todos los tests del proyecto, le paso el trabajo a un ayudante: el ruido se queda en su conversación y a mí solo me llega el resumen.

Usa un ayudante para lanzar los tests: a mí tráeme solo cuáles fallan y por qué.

3. Razonamiento alto, no máximo

En Claude Code puedes decidir cuánto razona Claude antes de responder. Se llama nivel de effort y tiene cinco escalones: low, medium, high, xhigh y max. Cuanto más alto, más tokens gasta pensando, y los tokens del razonamiento se pagan como los de la respuesta.

En los modelos actuales el nivel de partida es medium. Yo como base lo tengo en medium o high, o sea, medio o alto, según el trabajo: es una elección mía, no una regla. Se cambia con el comando /effort: solo abre un control deslizante, o escribes directamente el nivel.

/effort high

El máximo lo enciendo solo para la sesión en la que hace falta: un bug que no hay manera de encontrar, un trabajo que toca todo el proyecto. Luego vuelvo a empezar desde mi nivel base. Es cómodo, porque max vale solo para la sesión en curso y no se queda guardado. Y la propia documentación avisa de que en max el modelo tiende a darle demasiadas vueltas, con una ganancia que muchas veces no compensa los tokens.

4. Ayudantes con el modelo pequeño

Claude Code puede encargar trozos de trabajo a ayudantes, los subagentes (subagents). Cada ayudante trabaja en su propia conversación separada y al final te devuelve solo el resultado. Para los trabajos sencillos, como buscar dónde se usa una función, resumir un archivo o revisar unos textos, no hace falta el modelo más grande.

Si no dices nada, un ayudante suele usar el mismo modelo que el chat principal. El modelo más pequeño, Haiku, sirve para estos trabajos y consume menos. Hay dos maneras de usarlo.

Se lo pides en el momento

Cuando Claude pone en marcha un ayudante, puede elegir el modelo para ese trabajo. Basta con pedirlo:

Usa un ayudante con el modelo pequeño para encontrar todos los sitios donde se usa el login, y luego dame la lista.

Lo creas una vez y lo reutilizas

Los ayudantes que usas a menudo los puedes guardar como archivos en la carpeta .claude/agents/ del proyecto. Lo más sencillo es pedirle a Claude que cree uno. En el archivo, el campo model decide el modelo: con model: haiku funciona siempre con el pequeño.

Crea un ayudante para este proyecto que busque en el código y resuma los archivos. Guárdalo en .claude/agents/ y ponle model: haiku.

Los ayudantes también consumen tokens, que se suman a los del chat principal. El ahorro viene del modelo más pequeño y de que su ruido no acaba en tu chat.

5. Una petición clara

Tres peticiones vagas cuestan más que una clara. Con «arregla el perfil» Claude tiene que explorar medio proyecto para entender qué quieres decir, luego quizá arregla lo que no era, y vuelta a empezar. Una petición precisa le hace leer pocos archivos e ir directo.

Antes de escribir pongo cuatro cosas:

• Dónde: qué página, qué archivo, qué botón.
• Qué falla: qué pasa ahora.
• Qué quiero: qué tiene que pasar después.
• Cómo lo compruebo: un test, una comprobación, un resultado que pueda ver.

En lugar de «arregla el perfil» escribo:

En la página de perfil, el botón Guardar no guarda el email. Corrígelo y añade un test que lo demuestre. No toques otros archivos.

El «cómo lo compruebo» es lo que más cuenta: si Claude puede revisar solo su trabajo, encuentra el error antes de que tengas que encontrarlo tú. Y un «rehazlo» menos es una vuelta entera de tokens ahorrada.

Y si Claude sale en la dirección equivocada, páralo enseguida con Esc en lugar de esperar a que termine.

Los números: un día tipo, en un mes de trabajo

Estos números son un ejemplo realista de cómo cambian las cosas, no una factura. Dependen de cuánto trabajes, del proyecto y del modelo. Sirven para que veas de dónde sale el ahorro.

• Antes, con los chats largos y los logs pegados: cada nueva función necesitaba de media 4 o 5 vueltas de «rehazlo», y un día de trabajo consumía unos 6 millones de tokens.
• Después de los cinco hábitos: 1 o 2 vueltas por función, y el mismo día consume unos 3 millones.

El grueso del ahorro viene de dos cosas: los chats limpios, porque el chat largo se relee entero con cada mensaje, y menos «rehazlo». A final de mes el gasto es más o menos la mitad, con el mismo trabajo hecho.

Tus números los ves con /usage: muestra los tokens de la sesión y, si tienes suscripción, cuánto de tus límites has usado. Con /context ves qué está llenando el chat en este momento.

La regla: el gasto no es el precio del modelo, es cuántas veces le haces rehacer lo mismo.

Errores comunes

• Tener un solo chat abierto todo el día: con cada mensaje reenvías toda la historia, así que ciérralo con /clear cuando cambies de trabajo.
• Dejar las decisiones solo en el chat: cuando lo cierras ya no las tienes a mano, así que haz que las escriba antes en DECISIONES.md.
• Pegar logs y salidas enteros: dile a Claude dónde está el archivo y pídele solo las líneas que importan.
• Dejar el razonamiento en max también para las cosas pequeñas: úsalo solo en la sesión del bug difícil y luego vuelve a empezar desde tu nivel base.
• Mandar peticiones vagas y luego corregir a base de «rehazlo»: escribe dónde, qué falla, qué quieres y cómo lo compruebas.

Lista de comprobación

• Tengo un archivo DECISIONES.md en el proyecto
• Hago que lo actualice antes de cada /clear
• No pego logs largos en el chat
• Razonamiento base en medio o alto, max solo para la sesión que lo necesita
• Los ayudantes para trabajos sencillos usan el modelo pequeño
• Cada petición dice dónde, qué falla, qué quiero, cómo lo compruebo
• De vez en cuando miro /usage

Preguntas frecuentes