¿Cuántos tokens extra consume un subagent? Costes y estrategia de uso en flujos multi-agent

Sun, 31 May 2026 14:17:42 +0800

Usar subagents o un flujo multi-agent normalmente aumenta el uso de tokens. La pregunta no es si aumenta, sino cuánto aumenta y si la mejora en velocidad o estabilidad compensa ese coste adicional.

Para tareas pequeñas, suele ser más barato que el agent principal haga el trabajo directamente. Los subagents tienen más sentido cuando la tarea se puede dividir con claridad, o cuando merece la pena una revisión independiente.

Un subagent no es un hilo paralelo más barato

Al ver subagents por primera vez, es fácil imaginarlos como hilos paralelos: el agent principal hace una parte, el subagent hace otra, la tarea termina antes y por tanto debería ser más eficiente.

Pero no funciona así. Un subagent también es una llamada independiente al modelo. Necesita leer la tarea, entender el contexto, inspeccionar archivos, razonar sobre el problema y producir una salida. No es una copia gratuita del agent principal; es una ruta de razonamiento adicional.

Por eso la pregunta clave no es “¿puede ejecutarse en paralelo?”, sino “¿el tiempo ahorrado o la mejora de calidad justifican el coste extra en tokens?”.

Por qué aumenta el uso de tokens

Una llamada a un subagent suele añadir consumo de tokens en varias partes:

la descripción de la tarea que escribe el agent principal;
el contexto que se pasa al subagent;
los archivos y detalles que el subagent lee;
el razonamiento y la salida del propio subagent;
la revisión, integración y verificación posterior del agent principal.

Si varios agents leen los mismos archivos grandes, el desperdicio se vuelve más evidente. Esto ocurre especialmente en análisis de codebases, traducción de documentos largos y limpieza de contenido por lotes. Si la división es mala, muchos tokens se gastan en entender repetidamente el mismo contexto.

Releer contexto es el mayor desperdicio de tokens

El mayor desperdicio no suele ser “abrir un agent más”, sino hacer que varios agents lean los mismos materiales una y otra vez.

Por ejemplo, supongamos que una tarea debe procesar 6 artículos. Si 4 agents empiezan leyendo toda la estructura del sitio, toda la documentación de skills y toda la lista de artículos antes de tocar una parte pequeña, la paralelización sale cara. Una mejor opción es que el agent principal defina primero los límites y que cada subagent lea solo el directorio del artículo que le corresponde.

Una división más barata suele verse así:

cada agent se encarga de un directorio claro;
el contexto enviado a cada subagent es lo más corto posible;
varios agents no repiten la misma exploración;
el agent principal hace la revisión final una sola vez, en lugar de pedir a cada agent una revisión completa;
las comprobaciones que se pueden automatizar con scripts se ejecutan una vez, no se repiten con varios agents.

En otras palabras, controlar el coste de los subagents depende sobre todo de los límites, no solo del número de agents.

Cuánto puede aumentar

La siguiente tabla es una estimación aproximada. El consumo real depende de la longitud del contexto, el tamaño de los archivos, la complejidad de la tarea y el número de agents.

Escenario	Aumento de tokens
Un subagent procesa una tarea pequeña	Aproximadamente `1.2x - 2x`
2-4 agents procesan en paralelo una tarea bien dividida	Aproximadamente `2x - 5x`
Varios agents leen muchos archivos y hacen análisis largos	Posiblemente `5x+`
El agent principal y los subagents leen repetidamente los mismos archivos grandes	El desperdicio más evidente

No es una fórmula exacta de facturación, solo un rango práctico. El consumo real también depende de si cada agent necesita leer archivos completos, hacer razonamiento largo o esperar varias veces a que se le pase más contexto.

Cómo escribir una tarea de subagent que consuma menos tokens

Cuanto más amplia sea la instrucción, más probable es que el subagent explore por su cuenta, y eso aumenta el consumo de tokens. Una instrucción más barata define los límites con claridad.

Una buena tarea para subagent debería incluir:

qué archivos o directorios puede procesar;
qué archivos son solo de lectura y cuáles puede modificar;
si puede sobrescribir archivos existentes;
qué campos debe conservar, como date, slug y aliases;
qué debe incluir el informe final;
qué no debe hacer, por ejemplo no ejecutar una build completa ni editar archivos no relacionados.

Para una traducción, no basta con decir “traduce este artículo a varios idiomas”. Una instrucción más eficiente sería: “Procesa solo content/post/2026/05/240; lee index.zh-cn.md; crea solo los archivos que falten: index.en.md, index.zh-tw.md, index.ja.md e index.es.md; si ya existen, omítelos; conserva date y slug.”

La instrucción es un poco más larga, pero reduce las suposiciones y la exploración repetida. En conjunto suele salir más barata.

Dividir por archivo o directorio es más barato que dividir por idioma o paso

Para traducción por lotes, dividir por directorio de artículo suele ser mejor que dividir por idioma.

Supongamos que hay 6 artículos y cada uno necesita versiones en inglés, chino tradicional, japonés y español. Es mejor que un agent se encargue de todos los idiomas dentro de un directorio de artículo, en lugar de asignar un agent a todos los archivos en inglés y otro a todos los archivos en japonés.

La razón es simple: el front matter, los bloques de código, los enlaces, las tablas y el contexto semántico de un artículo solo necesitan leerse una vez. Si divides por idioma, varios agents leen el mismo texto fuente repetidamente y el consumo de tokens aumenta.

La misma lógica aplica a tareas de código. Es mejor dividir por módulo, directorio o componente que por pasos como “primero analizar, luego implementar, luego probar”. Dividir por pasos suele obligar a cada agent a releer el mismo contexto.

Cuándo merece la pena usar subagents

El valor de los subagents viene principalmente de dos cosas: paralelismo y una perspectiva independiente.

Casos adecuados:

traducir varios artículos por lotes;
editar varios directorios independientes;
separar claramente trabajo de frontend, backend y pruebas;
un agent implementa y otro revisa riesgos;
cambios de alto riesgo que necesitan una segunda perspectiva.

En estos casos, el uso de tokens aumenta, pero el tiempo total puede bajar de forma notable. Además, cada agent puede concentrarse en una parte concreta del trabajo.

Cuándo merece la pena usar un agent de revisión

Un agent de revisión no siempre vale la pena. Es más útil cuando la tarea es arriesgada, tiene mucho impacto o es fácil que el agent principal pase por alto detalles.

Casos en los que puede valer la pena añadir un agent de revisión:

cambios relacionados con inicio de sesión, pagos, permisos o borrado de datos;
contenido multilingüe que afecta categorías, URLs o enlaces internos;
refactors amplios que necesitan revisión independiente de regresiones;
el usuario pide explícitamente code review o revisión de riesgos;
el agent principal ya implementó el cambio y hace falta una segunda mirada sobre casos límite.

También hay casos claros en los que no compensa: cambios pequeños en un solo archivo, ajustes de título, correcciones simples de front matter o ejecutar un solo comando. Para eso, la autocomprobación del agent principal suele ser suficiente.

Cuándo no merece la pena

Los subagents no suelen merecer la pena en estos casos:

cambios pequeños en un solo archivo;
preguntas y respuestas simples;
ejecutar un único comando;
cambios de alcance muy pequeño;
tareas que no se pueden dividir claramente;
tareas en las que el subagent debe esperar varias veces a que el agent principal le pase contexto.

En estos casos, usar un subagent suele añadir sobrecarga. El agent principal es más rápido y más barato.

Mi estrategia por defecto: ahorrar tokens primero y añadir revisión solo por riesgo

Si el objetivo es ahorrar tokens, una estrategia conservadora funciona bien:

Tareas pequeñas: no usar subagents.
Tareas medianas: no usar subagents.
Tareas grandes por lotes: no usar subagents por defecto, salvo que el usuario pida explícitamente paralelizar para ganar velocidad.
Tareas de alto riesgo: considerar un agent adicional de revisión, intercambiando tokens por estabilidad.

Esta estrategia renuncia a parte de la velocidad paralela, pero reduce la lectura repetida de contexto y el razonamiento duplicado.

Si una tarea es grande pero no es de alto riesgo, primero conviene mirar scripts, comprobaciones por lotes y procesamiento local estructurado. Varios agents tienen más sentido cuando la división es muy clara o cuando el usuario quiere explícitamente más velocidad mediante paralelización.

Una estrategia más equilibrada

Si quieres controlar el coste sin renunciar del todo al paralelismo, una estrategia intermedia sería:

por defecto, el agent principal hace el trabajo directamente;
considerar subagents solo cuando la tarea se puede dividir claramente por archivo o directorio;
cada subagent lee solo los archivos que le corresponden;
no permitir que varios agents lean los mismos archivos grandes;
el agent principal hace la revisión final de campos clave, resultados de pruebas y Git diff;
añadir un agent de revisión independiente solo en tareas de alto riesgo.

Así se evita paralelizar por paralelizar. Los subagents deberían servir a un objetivo claro de velocidad o calidad, no convertirse en la acción por defecto.

Resumen

Los subagents y los flujos multi-agent siempre aumentan el uso de tokens. Un solo subagent puede añadir poco, pero varios agents en paralelo pueden multiplicar el coste.

Que merezca la pena depende de la tarea. Si el trabajo se puede dividir con claridad, o si el riesgo justifica una revisión independiente, los tokens extra pueden tener sentido. Para cambios pequeños en un solo archivo, preguntas simples o comprobaciones rutinarias, es más barato que el agent principal lo haga directamente.

En una frase: ahorra tokens en tareas pequeñas, divide solo cuando los límites sean claros y usa agents extra para estabilidad solo cuando el riesgo lo justifique.

Cost Optimization on KnightLi Blog