Cómo Reduje un 80% el Consumo de Tokens en Claude Code — Sin Perder Calidad

Gastaba más de $300 al día en tokens. No es una exageración — es un dato real de mi dashboard del 4 de marzo: $353,53 en un solo día. Opus se llevaba $298 de esos $353. Y lo peor: una parte significativa de esos tokens no generaba valor. Eran ruido.

He escrito sobre cómo usar especificaciones para guiar agentes de IA y sobre cómo montar equipos de agentes coordinados. Pero me faltaba hablar de algo que todo el que usa Claude Code a diario termina descubriendo: los tokens son un recurso finito, y optimizar su uso es tan importante como optimizar el código que produces.

Este artículo es el resultado de semanas de prueba, medición, y ajuste. No son trucos — son cambios de infraestructura que redujeron mi consumo de tokens drásticamente sin sacrificar la calidad del output.

El problema: tokens invisibles

Antes de optimizar, necesitas entender dónde se van los tokens. Y la respuesta te va a sorprender: la mayoría no se los lleva el código que genera el agente. Se los lleva todo lo demás.

Cada vez que un agente ejecuta git status, la respuesta completa entra en su ventana de contexto. Cada ls -la, cada npm run build, cada error de compilación — todo se acumula. En una sesión típica de desarrollo, el agente ejecuta entre 20 y 50 comandos. Si cada uno devuelve entre 500 y 5.000 tokens de output, estás quemando entre 10.000 y 250.000 tokens solo en respuestas de terminal. Tokens que el agente lee una vez y nunca vuelve a necesitar.

Luego está el modelo. Opus es el modelo más capaz de Anthropic. También es el más caro. Mis datos de marzo lo confirman: Opus representaba consistentemente entre el 80% y el 85% de mi gasto diario. Sonnet y Haiku se repartían el resto. Pero no todas las tareas necesitan Opus. Muchas se resuelven igual de bien con Sonnet. Y para algunas, Haiku sobra.

Y después están los MCPs. El Playwright MCP, por ejemplo, inyecta el accessibility tree completo del navegador en cada interacción. En 10 pasos de navegación, acumulas más de 10.000 tokens solo en estados de página que ya ni son relevantes.

La buena noticia: cada una de estas fuentes de desperdicio tiene solución.

RTK: comprimir lo que el agente no necesita leer completo

RTK (Rust Token Killer) es un proxy CLI escrito en Rust que intercepta la salida de los comandos y la comprime antes de que llegue al contexto del LLM. El agente no sabe que está ahí — ve una respuesta limpia en lugar de la respuesta cruda.

Cómo funciona

RTK se instala como un hook PreToolUse de Claude Code. Intercepta cada comando Bash y lo reescribe transparentemente:

git status  →  rtk git status
npm test    →  rtk npm test
ls -la      →  rtk ls -la

El agente pide ejecutar git status. RTK intercepta, ejecuta rtk git status, y devuelve una versión comprimida. El agente recibe la información que necesita sin el ruido que no necesita.

RTK aplica cuatro estrategias de compresión: smart filtering (quita headers, hints, y ruido visual), grouping (agrupa items similares), truncation (corta redundancia manteniendo contexto), y deduplication (colapsa líneas repetidas con contadores).

Mis números reales

Estos son los datos de mi instalación después de 136 comandos interceptados:

Comando	Sin RTK	Con RTK	Reducción
git status	805 bytes	268 bytes	67%
ls -la	~900 bytes	~400 bytes	71%
npm run build (Astro)	8.518 bytes	221 bytes	97%
Archivos pequeños (cat)	3.489 bytes	3.489 bytes	0%

El patrón es claro: donde más ahorra es en build logs, test output, y git status — que son exactamente los comandos más frecuentes en una sesión de desarrollo. Donde no aporta es en lecturas de archivos pequeños y greps con pocos resultados, que ya son concisos de por sí.

Mi dashboard de RTK muestra 91,9% de ahorro global en 136 comandos. De 714.900 tokens de input, solo 58.200 llegaron al contexto del agente. Los otros 656.700 eran ruido que RTK eliminó.

Instalación

brew install rtk
rtk init -g

rtk init -g configura el hook de Claude Code automáticamente en ~/.claude/settings.json. Reinicia Claude Code y listo — RTK empieza a interceptar desde la siguiente sesión.

Cuándo más importa

Si usas Agent Teams con un pipeline de 9 agentes, cada uno ejecuta múltiples comandos (git status, npm test, build, etc). RTK comprime todo transparentemente. El ahorro se multiplica por el número de agentes. En un pipeline completo, estamos hablando de cientos de miles de tokens ahorrados en una sola feature.

Playwright CLI: el MCP que quemaba tokens sin que lo supieras

Esta fue la optimización que más me sorprendió por lo invisible que era el problema.

El Playwright MCP es la forma estándar de dar acceso al navegador a un agente de IA. Funciona. Pero tiene un problema fundamental de diseño: cada interacción inyecta el accessibility tree completo de la página en el contexto del agente.

En una sesión típica de testing:

	MCP	CLI
Tokens por sesión	~114.000	~27.000
Por interacción	~1.000+ (accessibility tree completo)	~20 (comando shell)
En 7 pasos	7.400+ tokens acumulados de page state	~150 tokens + 1 snapshot en disco
Ahorro	—	~75% menos

El problema es acumulativo. En 10 pasos de navegación, el agente tiene 10 versiones del accessibility tree apiladas en su contexto. Versiones anteriores que ya no son relevantes. Y lo peor: el agente empieza a referenciar elementos de versiones antiguas porque tiene múltiples estados de página mezclados.

La alternativa: Playwright CLI

Playwright CLI es la respuesta de Microsoft a su propio problema. En lugar de inyectar el estado del navegador en el contexto del LLM, guarda snapshots en disco como YAML. El agente ejecuta comandos shell para controlar el navegador y lee los snapshots solo cuando los necesita.

playwright-cli open https://example.com
playwright-cli snapshot
playwright-cli fill e5 "user@example.com"
playwright-cli click e3
playwright-cli screenshot
playwright-cli close

Los e5 y e3 son referencias a elementos del snapshot. El agente lee el YAML del snapshot, identifica la referencia, y actúa. El snapshot no entra en el contexto del LLM — está en disco.

Instalación y migración

npm install -g @playwright/cli@latest
playwright-cli install --skills

El segundo comando instala la skill de Claude Code que le enseña al agente cómo usar la CLI en lugar del MCP. Después, desactivas el Playwright MCP desde Claude Code (/mcp → seleccionar Playwright → Disable).

En mi setup, tengo la skill instalada globalmente en ~/.claude/skills/playwright-cli/ para que todos mis proyectos la hereden automáticamente.

Cuándo seguir con el MCP

El CLI es mejor en casi todos los escenarios donde el agente tiene acceso al filesystem. Pero si usas un agente en sandbox sin acceso a disco (como Claude Desktop), el MCP sigue siendo la única opción. También es más cómodo para sesiones muy cortas (menos de 5 interacciones) donde la acumulación de contexto no es un problema.

Selección de modelo: la optimización más obvia que nadie hace

Mis datos de costes de marzo, desglosados por modelo:

Día	Total	Opus	Sonnet	Haiku
Mar 2	$106,82	$85,66 (80%)	$13,59	$7,57
Mar 4	$353,53	$298,58 (84%)	$42,79	$12,17
Mar 7	$202,32	$172,72 (85%)	$25,66	$3,95

Opus es entre 10x y 15x más caro que Sonnet. Y sin embargo, yo lo estaba usando para todo. Para implementar funciones simples, para generar migraciones, para escribir tests que siguen patrones establecidos. Tareas donde Sonnet produce exactamente el mismo resultado.

Cuándo cada modelo

La regla que sigo ahora:

Opus: Diseño de arquitectura, decisiones complejas de dominio, code review, debugging de problemas sutiles. Cuando necesito criterio, no velocidad.

Sonnet: Implementación siguiendo specs, generación de tests, tareas con patrones claros. Cuando las rules del proyecto y la especificación ya definen qué hacer, Sonnet ejecuta igual de bien que Opus.

Haiku: Tareas triviales, formateo, generación de boilerplate, queries de búsqueda.

En mi pipeline de Agent Teams, la distribución es:

Modelo	Agentes
Opus	Architect, Devil’s Advocate, Code Reviewer
Sonnet	Domain Dev, Infra Dev, Unit Tester, Endpoint Tester, Documenter

Los agentes que deciden usan Opus. Los que ejecutan usan Sonnet. Es la misma lógica que en un equipo humano: el arquitecto senior cobra más que el desarrollador junior, y está bien — porque su valor está en un tipo de trabajo diferente.

Gestión de contexto: lo que el agente carga importa

Cada sesión de Claude Code empieza cargando: el system prompt, las definiciones de herramientas, el CLAUDE.md, las rules, las skills, y los agentes custom. Todo eso consume tokens antes de que escribas una sola línea.

Un vistazo rápido a mi contexto actual con /context:

System prompt: 3.600 tokens
System tools: 20.800 tokens
Memory files (CLAUDE.md): 1.500 tokens
Skills: 2.000 tokens
Custom agents: 740 tokens
Total antes de empezar: ~28.600 tokens

Eso es un 14% de la ventana de 200k consumido antes de escribir nada. ¿Se puede optimizar? Sí, pero con cuidado.

.claudeignore

Si tienes un .gitignore, necesitas un .claudeignore. Este archivo le dice a Claude Code qué directorios y archivos ignorar al indexar el proyecto. Si no lo tienes, el agente puede terminar leyendo node_modules/, dist/, logs, o archivos de build que no aportan nada.

node_modules/
dist/
.next/
coverage/
*.log
*.lock

No es ahorro de tokens directamente — es ahorro de contexto cuando el agente busca archivos o explora el proyecto.

/compact y /clear

/compact comprime la conversación actual manteniendo el contexto esencial. Útil cuando llevas una sesión larga y notas que el agente empieza a repetirse o perder el hilo. No pierdes lo importante, pero recuperas espacio en la ventana.

/clear borra todo y empieza de cero. Más agresivo, pero a veces es lo que necesitas. Si la tarea anterior ya terminó y vas a empezar algo nuevo, un /clear evita que el agente arrastre contexto irrelevante.

Mi regla: cuando /context muestra más del 50% de uso, evalúo si necesito compactar. Si estoy por encima del 70%, compacto. Si voy a cambiar de tarea, /clear.

Plan Mode

Shift+Tab activa Plan Mode. En este modo, el agente planifica antes de ejecutar. Parece un detalle, pero tiene implicaciones directas en el consumo de tokens.

Sin Plan Mode, el agente puede empezar a implementar, darse cuenta de que el enfoque no era correcto, volver atrás, y re-implementar. Cada intento fallido consume tokens. Con Plan Mode, el agente propone un plan, tú lo validas, y después ejecuta con confianza. Menos ida y vuelta, menos tokens desperdiciados.

Para tareas complejas, empiezo siempre en Plan Mode. Para tareas simples, voy directo.

Monitorización: lo que no mides no mejora

De nada sirve optimizar si no puedes verificar que las optimizaciones funcionan. Estas son las herramientas que uso para medir.

ccusage

ccusage lee los logs JSONL locales de Claude Code y genera reportes de costes. No necesita API ni configuración — funciona con npx directamente.

npx ccusage daily --breakdown --compact --since 20260301

Esto me da un desglose diario por modelo: cuánto gasté en Opus, cuánto en Sonnet, cuánto en Haiku. Es lo que me permitió descubrir que Opus se llevaba el 85% del presupuesto.

npx ccusage session es aún más revelador — muestra el coste de cada sesión individual. Así puedes identificar qué tipo de tareas consumen más y dónde hay margen de optimización.

rtk gain

rtk gain

El dashboard integrado de RTK muestra tokens totales, tokens ahorrados, porcentaje de reducción por comando, y el ranking de qué comandos más ahorran. Es la forma más rápida de validar que RTK está haciendo su trabajo.

rtk gain --history da el desglose diario. rtk discover muestra oportunidades de ahorro que RTK detectó pero no aplicó (comandos que podrían beneficiarse de una regla que aún no existe).

/cost y /context

Los comandos nativos de Claude Code. /cost muestra tokens y coste de la sesión actual. /context muestra cómo se distribuye la ventana de contexto entre system prompt, herramientas, memoria, skills, y mensajes.

Los uso como check rápido durante las sesiones. Si /cost me muestra un pico inesperado, investigo qué comando lo causó. Si /context muestra que los mensajes ocupan el 70%, es hora de compactar.

El impacto combinado

Ninguna de estas técnicas es revolucionaria por sí sola. El impacto real viene de combinarlas.

RTK elimina el ruido de la terminal — 60-90% de ahorro en output de comandos.

Playwright CLI reemplaza un MCP que acumulaba contexto innecesario — 75% menos tokens en sesiones de navegador.

Selección de modelo ajusta el coste al tipo de tarea — pasar de Opus a Sonnet en implementación reduce el coste 10-15x para esas tareas.

Gestión de contexto mantiene la ventana limpia y el agente enfocado — menos repeticiones, menos ida y vuelta, menos tokens desperdiciados.

Monitorización cierra el ciclo — mides, detectas, ajustas.

Mi gasto diario pasó de $200-350 a $60-100 para el mismo volumen de trabajo. No porque haga menos — porque cada token genera más valor.

Cuánto ahorras depende de cómo trabajas

Si usas Claude Code para tareas puntuales — un bug aquí, una función allá — la optimización tiene un impacto moderado. El consumo base ya es bajo y las sesiones son cortas.

Pero si trabajas como yo, con Agent Teams ejecutando pipelines de 9 agentes sobre especificaciones formales, cada optimización se multiplica. RTK ahorra tokens en cada agente. La selección de modelo reduce el coste de 5 de los 9 agentes. Playwright CLI elimina miles de tokens en cada sesión de testing e2e.

La regla es simple: cuanto más tokens consumas, más impactan las optimizaciones. Y si usas agentes, consumes muchos tokens.

Conclusión

Los tokens son el recurso más caro y más invisible del desarrollo con IA. La mayoría de los desarrolladores no saben cuánto gastan, ni en qué, ni por qué. Instalan Claude Code, trabajan, y al final del mes ven una factura que no entienden.

La optimización no es restringir — es ser inteligente con un recurso finito. RTK comprime lo que el agente no necesita leer completo. Playwright CLI elimina un MCP que acumulaba estado innecesario. La selección de modelo usa el modelo correcto para cada tarea. Y la monitorización te da los datos para seguir ajustando.

El primer paso es medir. Ejecuta npx ccusage daily --breakdown y mira dónde se va tu presupuesto. Te garantizo que vas a encontrar sorpresas.

P.D.: Si has encontrado otras formas de optimizar el consumo de tokens, me encuentras en Twitter como @lmmartinb. Y si todavía no tienes un sistema de especificaciones para tus agentes, empieza por mi artículo sobre SDD con OpenSpec.