Llevo ya bastantes meses usando herramientas de codificación con IA a diario. Empecé con Claude Code y la suscripción Max para trabajo de cliente con Drupal, luego me pasé a OpenCode porque te dejaba conectar modelos más baratos y controlar mejor el gasto, y cuando Anthropic cortó la posibilidad de usar la suscripción a través de OpenCode, volví a Claude Code para el trabajo pesado y dejé OpenCode para tareas rutinarias con modelos económicos. En algunos meses la factura ha sido más elevada de lo que debería, y a base de ir probando cosas y buscando información he ido aprendiendo una serie de prácticas para reducir el consumo de tokens sin perder calidad en los resultados.
Después de años trabajando con herramientas de desarrollo, pocas veces he visto una diferencia tan grande entre usarlas bien y usarlas mal como con los agentes de codificación con IA.
En los últimos meses he visto en grupos de Telegram, en Discord, en Reddit y en Twitter a bastante gente quejándose de lo mismo: que queman demasiados tokens, que la suscripción se les queda corta, que no les salen las cuentas. Yo sigo quemando tokens. De hecho más que antes, porque ahora tengo procesos automatizados corriendo que consumen bastante. Pero creo que lo estoy controlando razonablemente bien. He ido leyendo qué hace otra gente, probando configuraciones, y poco a poco he montado mi propia forma de trabajar.
Lo que comparto aquí son las prácticas que a mí me funcionan a día de hoy, con los modelos y versiones actuales de Claude Code y OpenCode. Hace poco publiqué un artículo explicando cómo tengo montado mi entorno completo de desarrollo con IA en DDEV, y a raíz de eso me ha parecido interesante compartir también los tips que he ido aprendiendo con el tiempo para gastar menos tokens, que al final se traduce en que la suscripción me dura más tiempo o que el gasto de API es menor. Esto aplica de forma muy similar tanto en OpenCode como en Claude Code, aunque en este artículo me voy a centrar más en Claude Code. Aviso de antemano: no descarto que de aquí a unos meses, con nuevos modelos o actualizaciones, parte de esto quede obsoleto. Pero a día de hoy, esto es lo que me vale.
Menos MCPs, más contexto
Cada servidor MCP que tienes conectado ocupa espacio en la ventana de contexto. En cada mensaje que envías. Lo uses o no lo uses en esa tarea concreta. Si tienes varios MCPs cargados al mismo tiempo, te estás comiendo una parte enorme de la ventana antes de empezar a trabajar.
Cuando empecé con Claude Code los MCPs se comían una barbaridad de contexto. En una actualización posterior optimizaron cómo se carga esa información y consiguieron reducir entre un 80% y un 85% el consumo por tener MCPs que no estás utilizando. Ahora cargan solo los nombres de las herramientas al arrancar y descargan los detalles cuando Claude necesita una herramienta concreta. Eso ayudó bastante, pero no quita el problema de fondo.
Y a mí también me ha pasado lo que le pasa a mucha gente. Al principio fui activando y probando MCPs: el de GitHub, el de Slack, Linear, Playwright... Se quedaban ahí instalados aunque no los estuviera usando. Hasta que me di cuenta de que para mi trabajo del día a día, que es desarrollo web con Drupal, solo necesito uno: Playwright. Lo uso para que la IA pueda interactuar con mi web local, loguearse como usuario, hacer capturas de pantalla, ver el HTML, revisar los comentarios de Twig, y comprobar si los formularios de backend funcionan como deberían.
Mi solución fue la más simple posible: desinstalar todos los MCPs que tenía acumulados y dejar solo Playwright. Ni desactivar, ni deshabilitar temporalmente. Desinstalar. Si algún día necesito otro MCP para algo puntual lo instalo, lo uso, y lo quito. Tenerlos ahí "por si acaso" es tirar tokens.
Conversaciones cortas, siempre
Este fue el cambio que más me costó adoptar. Mi instinto era mantener una conversación abierta toda la semana porque así Claude "sabía de qué iba el proyecto" y no tenía que explicarle todo otra vez.
Error.
La API de Anthropic no tiene memoria entre llamadas. Cada vez que envías un mensaje, se reenvía toda la conversación desde el principio: el system prompt, todas las herramientas, tu configuración, y todo el historial de mensajes anteriores. El coste va creciendo con cada turno. Una conversación que empieza ligera puede estar consumiendo cantidades enormes de tokens en el turno 15 o 20.
Cuando la conversación ocupa demasiado, aproximadamente sobre el 80% de la ventana, Claude Code compacta automáticamente. Resumir todo lo anterior para liberar espacio. El problema es que ese resumen pierde información importante. Me ha pasado que después de compactar, Claude "olvidaba" que un enfoque ya había fallado, lo volvía a intentar, y volvía a fallar. Aparte de que baja la calidad, la compactación también te sale más cara en tokens. Ahí es donde la cosa se tuerce para mucha gente.
Lo que hago yo es no llegar nunca a ese punto. Cuando veo que la ventana de contexto supera el 50%, empiezo a pensar en abrir una conversación nueva. Cierro, abro limpio, y si necesito que Claude sepa algo de la sesión anterior, le paso un resumen rápido de dónde estaba. Sé que puede parecer pesado, pero la alternativa es peor: dejar que la conversación se hinche, que salte la compactación, que baje la calidad del código y que encima te cueste más.
El cache que pierdes al dormir
Esto va muy ligado a lo anterior, pero merece su propio punto porque mucha gente no lo sabe. Si trabajas con una conversación por la tarde y la retomas por la mañana siguiente, has perdido el cache.
Anthropic cachea los prefijos de tokens que se repiten entre llamadas, y la lectura de cache cuesta una fracción del precio normal. Pero ese cache tiene un tiempo de vida limitado. Si pausas más de unos minutos, se evapora. Cuando retomas una conversación antigua, todo ese contexto tiene que volver a procesarse desde cero a precio completo. Estás pagando la misma conversación dos veces: la de ayer y la de hoy para reconstruir el cache.
La recomendación es sencilla: empieza una conversación nueva cada día. No intentes retomar donde lo dejaste ayer.
Opus no es para todo
Claude Code te deja tener subagentes y especificar qué modelo usa cada uno. Esto es clave, porque no todo tiene que correr con el modelo más caro.
Yo uso Opus para el agente principal, que es el que orquesta y el que toma las decisiones complejas: diseño de arquitectura, debugging de problemas difíciles. Para la mayoría del trabajo de desarrollo uso Sonnet, que da un resultado prácticamente igual a una fracción del coste. Y luego hay cosas que tengo controladas, que sé que Haiku hace bien, como buscar código en el proyecto o interactuar con el navegador a través de Playwright. Esas tareas acostumbran a gastar muchos tokens porque cada interacción genera un montón de contexto, y me interesa que se gasten tokens baratos en un modelo que sea lo suficientemente listo pero que no sea excesivamente caro.
Lo bueno es que puedes configurar cada agente para que use su modelo de forma automática. El agente principal con Opus delega en un agente de desarrollo con Sonnet, que a su vez llama a otro agente con Haiku para testear en el navegador que lo que se ha hecho funcione. Distintos agentes, distintos modelos, y el consumo se optimiza solo sin que tengas que cambiar de modelo manualmente.
Yo al principio usaba Opus para absolutamente todo, incluidas cosas así de mecánicas, y cuando miré los números del primer mes no me lo podía creer. La diferencia entre hacer un refactor con Opus y hacerlo con Sonnet puede ser de 5 dólares frente a menos de 50 céntimos. En una tarea suelta no parece mucho, pero al cabo del mes se nota.
Aparte de esto, en OpenCode tiro de modelos open source como Qwen o Kimi 2.5, que puedes ejecutar en local o a través de servidores de terceros a un precio mucho menor de lo que te costaría cualquier modelo de Anthropic. Los modelos de Anthropic son en general bastante más listos y mejores, pero para tareas rutinarias y relativamente fáciles no necesitas esa potencia, y la diferencia de coste es enorme.
El contexto que no compartes
Hay otro beneficio de los subagentes que va más allá del ahorro en el modelo y que poca gente menciona.
Cada subagente trabaja con su propia ventana de contexto, separada de la conversación principal. Cuando termina su tarea, solo devuelve un resumen con los resultados. Todo el trabajo intermedio que haya hecho, los archivos que haya leído, las búsquedas, las pruebas que haya lanzado, se queda dentro del subagente y no ensucia tu conversación principal.
¿Qué significa esto en la práctica? Que si delegas las tareas pesadas a subagentes, la conversación principal se mantiene limpia mucho más tiempo. Tardas más en llenar la ventana, retrasas o directamente evitas la compactación, y puedes tener sesiones más largas y más profundas sin que la calidad se degrade. Es una de esas cosas que cuando las entiendes te cambia bastante la forma de organizar el trabajo.
Skills en vez de instrucciones sueltas
Este punto lo veo menos en las conversaciones sobre optimización de tokens, pero para mí es bastante importante.
Las skills son instrucciones reutilizables que Claude carga solo cuando las necesita. A diferencia de la configuración general del proyecto, que se envía en cada llamada, las skills se cargan bajo demanda. Si tienes instrucciones detalladas sobre cómo hacer un deploy o cómo ejecutar migraciones, en vez de meterlas en la configuración principal donde van a ocupar espacio siempre, las pones en una skill y solo se cargan cuando toca.
Es mejor tener unas pocas skills bien escritas que un montón de instrucciones vagas metidas en la configuración general. Y de paso, ten unos pocos agentes con modelos Sonnet o Haiku que sepan usar esas skills. No necesitas veinte agentes. Con cuatro o cinco bien definidos, cada uno con su modelo apropiado, tienes más que de sobra.
Un CLAUDE.md que no pese
Relacionado con lo anterior. El archivo CLAUDE.md se envía en cada llamada a la API. Cada palabra que metas ahí la estás pagando en todos los mensajes.
He visto configuraciones de CLAUDE.md de 2.000 líneas con absolutamente todo el proyecto documentado dentro. Eso es tirar dinero. Mi enfoque es tratarlo como un índice: solo lo esencial, lo que Claude hace mal repetidamente para que no lo vuelva a hacer, y punteros a documentos más detallados para cuando haga falta. Cuanto más corto, mejor.
Las cuentas de Max vs API
Me han preguntado varias veces qué compensa más, si la suscripción Max o ir con API y pagar por uso. Depende totalmente de cuánto lo uses.
Si usas Claude Code tres o cuatro veces a la semana para cosas puntuales, la API te sale más barata. Probablemente gastes menos de 10 dólares al mes. Pero si lo usas a diario varias horas, la suscripción compensa con diferencia. He visto casos de gente que con uso intensivo habría pagado miles de dólares en API y con la suscripción Max se queda en 100 o 200 al mes. ¿Realista? Totalmente. Hay un caso documentado de un usuario que consumió 10.000 millones de tokens en 8 meses. En API serían más de $15.000. Con Max pagó $800.
En mi caso uso Max con Claude Code para el trabajo interactivo del día a día, y API a través de OpenCode para tareas automatizadas y loops de calidad de código que puedo dejar corriendo sin supervisar.
Los dos errores más caros
La realidad es que la mayoría del gasto innecesario viene de dos sitios.
El primero: usar Claude Code con la configuración por defecto, sin agentes, sin skills, todo corriendo con Opus. Es el setup más caro posible y no te da ninguna ventaja real sobre tener agentes bien configurados con modelos apropiados para cada tarea.
El segundo: tener una sola conversación por proyecto y reutilizarla para todo durante días o semanas. Te va a saltar la compactación cada dos por tres, la calidad va bajando conforme se acumula el contexto, y acabas pagando mucho más de lo que deberías por el mismo trabajo.
Lo que me queda claro
Después de meses pasando de Claude Code a OpenCode y volviendo, probando configuraciones y mirando los números, lo que he aprendido es que la diferencia entre gastar poco y gastar mucho no está en usar la herramienta menos. Está en cómo la configuras y en cómo gestionas las conversaciones. La mayor parte del gasto se va en overhead: contexto que se reenvía una y otra vez, MCPs que no estás usando, conversaciones que deberían haberse cerrado hace rato.
Si solo vas a cambiar una cosa después de leer esto, que sea poner Sonnet como modelo por defecto y dejar Opus solo para las tareas que de verdad lo necesiten. Solo con eso ya notarás la diferencia a final de mes.
PS: Si trabajas con Drupal y usas DDEV, te recomiendo que eches un vistazo al artículo donde explico cómo tengo montado mi entorno completo de desarrollo con IA. Ahí cuento en detalle la arquitectura, cómo se comunican los contenedores, y por qué tengo dos CLIs instalados al mismo tiempo. He publicado también el repositorio ddev-ai-workspace, que con un solo comando te instala OpenCode, Claude Code, Playwright como MCP, un orquestador autónomo para tareas sin supervisión, y 10 agentes especializados en Drupal con sus skills y configuración de modelos. Es totalmente gratuito, lo único que necesitas es una suscripción de Claude Code o pagar APIs para poder usar las herramientas de IA. Si te interesa probarlo o tienes cualquier duda, puedes contactarme directamente.