Supón que tu factura de Claude Code llega a $312 en una semana. Reestructura cómo usas los subagents y la semana siguiente puede quedarse en unos $124 con más trabajo hecho — el mismo proyecto, aproximadamente un 60% menos de gasto. Esos números son una ilustración de la mecánica, no una medición real, pero la solución a la que apuntan sí es real, y no es "usar un modelo más barato."
La frase clave es Claude Code subagents, y casi todo lo que se escribe sobre ellos los trata como un juguete para la paralelización. En realidad son una palanca de costes. Eso es lo que nadie me había dicho.
Por qué un hilo largo sangra dinero
Esto es lo que por fin entendí. Cuando trabajas en una sesión gigante de Claude Code, cada mensaje arrastra consigo todo el historial de la conversación. A la tercera hora, tu ventana de contexto está repleta de volcados de archivos antiguos, intentos fallidos y un registro de ti mismo diciendo "no, el otro archivo." Pagas por todo eso en cada turno.
Un subagent recibe un contexto fresco y acotado. Hace un trabajo, devuelve un resumen conciso y su contexto de trabajo inflado desaparece. El hilo principal nunca ve los 8,000 tokens de contenido de archivos que el subagent revisó — solo ve la respuesta de tres líneas.
Ese es todo el truco. Los subagents son aislamiento de contexto. El aislamiento de contexto es control de costes.
Cómo distribuyo el trabajo en la práctica
Ahora construyo una funcionalidad en aproximadamente cuatro movimientos, y asigno cada uno a quien debe hacerlo.
El agente principal sigue siendo el orquestador. Mantiene el plan y casi nada más. Luego delego:
- Un subagent de investigación lee el código base e informa: "aquí están los 4 archivos que tocan auth y lo que hacen." Revisa 20 archivos. Yo recibo un párrafo.
- Un subagent constructor escribe el cambio real a partir de ese párrafo.
- Un subagent revisor lee el diff en frío, sin memoria de cómo llegamos aquí, lo que lo hace extrañamente bueno detectando errores tontos.
El hecho de que el revisor sea amnésico es una ventaja. Un agente fresco no racionaliza el código que acaba de escribir.
Los defines en .claude/agents/ como archivos markdown. Uno mínimo:
---
name: codebase-researcher
description: Finds and summarizes relevant files. Use before any change.
tools: Read, Grep, Glob
---
You locate the files relevant to the task and return a tight summary:
paths, what each does, and the 1-2 functions that matter. No code dumps.
Fíjate en la línea tools. Al investigador le di herramientas de solo lectura. Físicamente no puede editar un archivo ni ejecutar un comando. Eso elimina toda una clase de divagación cara, donde un agente "investiga" ejecutando tu suite de pruebas once veces.
El error que más me costó
La delegación vaga. Al principio lanzaba un subagent con "arregla el bug del login." Releía todo el código base desde cero porque no tenía ni idea de dónde buscar, quemando exactamente los tokens que intentaba ahorrar. El subagent empezaba desde cero.
Ahora el orquestador hace primero un reconocimiento barato y luego le da al subagent un objetivo concreto: "En auth/session.ts, el token de actualización no está rotando. Arregla solo esa función." Entrada acotada, contexto acotado, factura pequeña.
Si el prompt de tu subagent no nombra archivos, le estás pagando para que se pierda.
Cuándo NO usar un subagent
Esto me sorprendió. Los subagents no son gratuitos. Hay una sobrecarga en el traspaso y, si la tarea es pequeña, lanzar uno cuesta más que hacerlo directamente. ¿Renombrar una variable? Hazlo en el hilo principal. Un cambio de dos líneas no necesita un comité.
Uso la prueba del olfato: si la tarea requiere leer más de unos pocos archivos para hacerse bien, la aíslo en un subagent. Si no, no lo hago. El paralelismo por sí solo es simplemente una forma más cara de ser lento.
Los números, concretamente
¿A dónde se va una semana de $312 como esa? Una gran parte es el modelo releyendo los mismos cuatro archivos grandes en casi cada turno porque están fijados en el contexto de la sesión. Muerte por mil relecturas.
En la semana reestructurada, el subagent de investigación lee esos archivos una vez, los resume y el hilo principal avanza sobre el resumen. Los archivos entran al contexto exactamente una vez en lugar de treinta. Ese único cambio de comportamiento explica la mayor parte del ahorro.
Unos cuantos logros menores se sumaron. Empecé a limpiar el contexto entre tareas no relacionadas en lugar de dejar una sesión correr todo el día. Dejé de pegar registros enormes en el hilo principal y dejé que un subagent los clasificara. Y configuré modelos más baratos para la investigación rutinaria mientras mantenía el modelo más potente para la construcción y la revisión reales — que el inteligente piense, que el rápido busque.
Mi configuración actual
Tres archivos de agentes: investigador, constructor, revisor. El investigador y un agente de clasificación de registros corren sobre un modelo más barato y rápido. El constructor y el revisor corren sobre el modelo más potente que tengo, porque ahí los errores son caros de otra manera — el código malo cuesta más que los tokens.
El trabajo del orquestador es mantenerse ligero. En el momento en que el hilo principal empieza a almacenar contenido de archivos, sé que he metido la pata y empujo ese trabajo a un subagent.
Trabajar solo significa que tu factura de cómputo es la compañera de piso de tu sueldo. Cada token que no malgastas es margen. Los subagents no son para ir más rápido, aunque sí lo haces. Son para no pagar por releer el mismo archivo treinta veces como hice yo.
Revisa tu desglose de uso esta semana. Apuesto a que son relecturas.