Coste de subagentes: por qué sube al cambiar de modelo
DominicodeCambié el modelo de mi pipeline de research y la factura del día siguiente no cuadraba.
No había tocado el código. Ni un prompt nuevo, ni una tool nueva. Solo el identificador del modelo en una variable de entorno.
Mi primera sospecha fue el precio por token. No era eso.
Era que el modelo nuevo delegaba más. El mismo prompt de orquestación, palabra por palabra, lanzaba más subagentes por tarea. Y ese es el problema: el coste de los subagentes no se fija una vez y queda escrito en tu repo.
El número de subagentes que lanza tu sistema no lo decides solo tú. Lo decide en parte el modelo: cuántos subagentes delega por defecto es una propiedad del modelo, no de tu código, y cambió en las tres últimas generaciones de Claude Opus — 4.6 lanzaba muchos, 4.7 menos, y Opus 5 vuelve a delegar más que los anteriores. Por eso tu factura puede subir sin que toques una línea.
Un aviso antes de seguir: si lo que estás decidiendo es si montar varios agentes o quedarte con uno, este no es tu post. Esa pregunta la respondí entera en cuándo usar multi-agente sin orquestador. Aquí doy por hecho que ya tienes subagentes corriendo. Voy a otra cosa: tu ajuste está atado a un modelo que ya no existe.
Cuántos subagentes delega Claude Opus 4.6, 4.7 y 5 por defecto
Esto es lo que documenta Anthropic en su guía de migración de modelos sobre el comportamiento por defecto al delegar:
| Modelo | Comportamiento por defecto al delegar |
|---|---|
| Claude Opus 4.6 | Lanzaba muchos subagentes |
| Claude Opus 4.7 | Tiende a lanzar menos subagentes que 4.6 |
| Claude Opus 5 | Delega en subagentes más fácilmente que los modelos anteriores |
Fuente: documentación de Anthropic sobre Claude Opus 4.6, 4.7 y 5, consultada en julio de 2026.
Arriba, abajo, y otra vez arriba.
Tres versiones, tres defaults distintos. Y ninguno aparece en tu diff, en tu changelog ni en tu suite de tests.
Sobre Opus 5 Anthropic es literal: la delegación "compensa en tramos de trabajo grandes y genuinamente independientes, pero multiplica coste y tiempo cuando se aplica a tareas pequeñas".
Multiplica. No suma.
Un cambio de modelo tiene dos tipos de consecuencias: las que rompen la llamada y ves en el primer deploy —de esas hablé en los 2 breaking changes de Claude Opus 5— y las que no rompen nada. Estas segundas son peores, porque el sistema sigue funcionando. Solo cuesta más y tarda más.
Por qué el coste de los subagentes se dispara: los ajustes se acumulan
Piensa en lo que hiciste cuando tu modelo delegaba poco.
Le empujaste. Escribiste algo del tipo "si la tarea toca más de tres ficheros, reparte el trabajo entre varios subagentes". Funcionó, lo dejaste ahí y pasaste a otra cosa.
Esa frase sigue en tu prompt.
La escribiste contra un modelo que iba parado. Ahora se la dices a uno que ya corre solo. Empujar a alguien quieto y empujar a alguien lanzado no dan el mismo resultado, y esa es la situación de casi todos los sistemas de agentes que reviso.
El prompt de orquestación es la capa que más rápido envejece y la que menos gente revisa. Si tienes montado el patrón coordinador que expliqué en cómo orquestar subagentes de IA, el coordinador es donde vive esta deuda: ahí siguen las instrucciones que compensaban algo que ya no hay que compensar.
Los ajustes de prompt no se reemplazan al cambiar de modelo. Se acumulan sobre el nuevo default.
La recomendación de Anthropic va en dos direcciones: dar guía explícita sobre qué escenarios justifican delegar, o poner topes deterministas a cuántos agentes se pueden lanzar. Este es el bloque de guía que ellos mismos proponen, traducido:
Delega en un subagente solo para tareas grandes que sean genuinamente
independientes y paralelizables, como una investigación amplia en muchos
ficheros. No delegues trabajo que puedas terminar tú en un puñado de
llamadas a herramientas, y no uses subagentes para verificar o revisar
tu propio trabajo. Si un subagente puede completar la tarea, usa uno en
vez de varios, y mantén bajos los recuentos de lanzamiento.
Fíjate en la frase del medio. Ahí está el cambio más caro.
El caso más caro: el subagente que verifica
No uses subagentes para verificar o revisar tu propio trabajo.
Hace un año eso era lo contrario de lo que recomendábamos casi todos, yo incluido: un subagente con contexto limpio revisaba la salida del principal y pillaba lo que el autor no veía. Funcionaba.
Con Opus 5 esa misma instrucción es gasto.
Anthropic documenta que Opus 5 verifica su propio trabajo sin que se lo pidas. Y va más lejos: si tu prompt lleva instrucciones explícitas del tipo "incluye un paso final de verificación" o "usa un subagente para verificar", hay que quitarlas, porque provocan sobre-verificación. Quitarlas reduce tokens desperdiciados sin pérdida de calidad.
Eliminar instrucciones baja el coste y no empeora el resultado.
Lo mismo con el auto-chequeo. La indicación es no pedirle re-chequeos que ya hace, y eso invierte una de las best practices de prompting más repetidas de los últimos años.
El patrón escritor-verificador no está muerto: Anthropic dice también que Opus 5 coordina equipos de subagentes bien, con pocos casos de agentes que se pisan el trabajo entre ellos. Lo que cambia no es el patrón, es el reflejo.
La línea es esta: sobra que el modelo se revise a sí mismo dos veces; no sobra un control independiente sobre el trabajo de otro. Una puerta antes de mergear, un revisor de seguridad, un validador de contrato. Eso no es sobre-verificación, es una barrera, y las barreras no se quitan porque el modelo haya mejorado.
Un verificador independiente sobre un entregable grande sigue teniendo sentido. Enganchado por defecto a cada tarea pequeña, revisando lo que el modelo ya revisó solo, duplica el coste de los subagentes a cambio de nada.
Y otra vez Anthropic: para cargas sensibles al coste, limita la delegación.
Lo único estable: el tope determinista
Un prompt es una sugerencia que el modelo pondera junto a todo lo que hay en su contexto. Un tope en el harness es un número.
Si el default del modelo se mueve y tu tope no, tu coste tiene techo.
Por eso el sitio donde escribes "máximo tres subagentes por tarea" importa más que la frase. En el prompt es una preferencia. En el código que rodea al modelo es una ley. La misma distinción que explico en por qué un LLM por sí solo no es un producto: el modelo propone, el harness decide qué se ejecuta.
Dónde vive ese número depende de cuánto harness tuyo haya. Si el bucle lo escribes tú —API directa o SDK—, el tope es un contador en la función que lanza subagentes y no hay más discusión. Si trabajas dentro de una herramienta de terceros no tienes esa función, pero casi siempre tienes tres palancas: qué subagentes existen como definición, un hook que intercepte la llamada que los lanza —como los hooks de Claude Code— y el log. Si tu plataforma no te da ninguna de las tres, asúmelo: tu único control es el prompt, y entonces el número de la factura no lo decides tú.
Cuatro topes de subagentes que no dependen del modelo
El mecanismo aguanta cualquier generación; el número que metes dentro, no. Ese lo revisas tú, con el log delante.
- Contador de lanzamientos por tarea. El spawn número N+1 se rechaza, sin negociación.
- Presupuesto de tokens por ejecución. Cuando se agota, se corta y se devuelve lo que haya.
- Profundidad máxima de anidamiento. Un subagente que lanza subagentes es donde se va el presupuesto sin aparecer en ninguna traza. Si tu harness permite anidar, el límite es 1 salvo que puedas justificar lo contrario. Y si defines los subagentes como ficheros, como en Claude Code, la lista de herramientas de cada uno es donde se decide quién puede delegar y quién no.
- Timeout por rama. El subagente colgado también cuesta, sobre todo en latencia.
El tope tiene un precio y conviene decirlo. Si el modelo iba a repartir bien un trabajo de verdad paralelizable, el rechazo número N+1 le corta el plan por la mitad. Por eso el tope no puede ser solo un throw: define qué pasa después. Lo razonable es degradar, no abortar — el trabajo que iba a delegar lo hace en línea, más lento y más barato, y el log registra que el tope saltó. Un tope que convierte un sobrecoste visible en un resultado truncado silencioso es peor que no tener tope.
Y el tope solo protege del exceso. Si el próximo modelo vuelve a delegar poco —y ya ha pasado— nunca llega a saltar, y lo que notas es peor cobertura, no peor factura. El log es lo que te dice si el número hay que subirlo, bajarlo o dejarlo en paz.
Cuántos agentes puede lanzar tu sistema es una decisión de arquitectura y se toma antes de escribir el código, no cuando llega la factura. Es el fondo de lo que cuento en el libro de Spec-Driven Development: lo que no está en la spec lo acaba decidiendo el modelo por ti.
Qué revisar hoy en tu prompt de orquestación: checklist en 5 pasos
- Busca en tu prompt de orquestación las frases que empujan a delegar. Las escribiste contra un modelo concreto. Si ese modelo ya no es el que corre, bórralas o reescríbelas.
- Busca las instrucciones de verificación que el modelo se aplica a sí mismo. "Verifica al final", "usa un subagente para revisar tu trabajo", "comprueba tu respuesta". Si estás en Opus 5, quítalas y mide antes y después. Lo que no tocas es el control independiente: si tienes una puerta que valida el entregable de otro agente antes de que salga, se queda donde está.
- Loguea cuántos subagentes se lanzan por tarea. Media y percentil 95. Sin ese número no tienes el problema medido, tienes una intuición — va de eso cómo monitorear agentes de IA en producción.
- Pon un tope duro en el harness, aunque lo pongas alto. La primera vez que salte te contará algo que no sabías.
- Anota contra qué modelo está afinado tu prompt. Modelo y fecha, dos líneas en el repo. Eso convierte el futuro "esto ya no va igual" en "esto se afinó contra 4.7".
El resumen cabe en una frase: el prompt es una recomendación, el harness es una ley. Todo lo que quieras que sobreviva al próximo modelo, escríbelo en el segundo.
En Dominicode Labs revisamos configuraciones reales de producción, con sus facturas delante.
Preguntas frecuentes sobre el coste de los subagentes
¿Cuántos subagentes debería lanzar mi sistema por tarea?
Los menos que resuelvan la tarea. La guía de Anthropic es explícita: si un subagente puede completar el trabajo, usa uno en vez de varios y mantén bajos los recuentos de lanzamiento.
No hay número universal, pero sí un punto de partida razonable: tope de 3 lanzamientos por tarea y profundidad de anidamiento 1 —un subagente no lanza subagentes—, y a partir de ahí subes solo cuando el log demuestre que hacía falta. Mide el tuyo antes de opinar sobre él.
¿Por qué subió el coste de los subagentes si no cambié nada del código?
Porque el comportamiento por defecto al delegar es una propiedad del modelo y cambia entre versiones. Claude Opus 4.6 lanzaba muchos subagentes, Opus 4.7 tiende a lanzar menos que 4.6 y Opus 5 delega más fácilmente que los anteriores. Cambiar el identificador del modelo en una variable de entorno cambia ese default sin tocar una línea de tu sistema.
¿Hay que quitar el subagente verificador de mi orquestador?
Si corres sobre Claude Opus 5, sí en su forma refleja. Anthropic recomienda eliminar las instrucciones explícitas del tipo "usa un subagente para verificar": el modelo ya verifica su propio trabajo y esas frases provocan sobre-verificación, así que quitarlas reduce tokens desperdiciados sin pérdida de calidad.
Un verificador independiente sobre un entregable grande sigue teniendo sentido; enganchado a cada tarea pequeña, no. Para las instrucciones de auto-chequeo dentro del propio prompt —el clásico "revisa tu respuesta antes de contestar"— el detalle está en los 2 breaking changes de Claude Opus 5.
¿Sigue siendo válido el patrón escritor-verificador?
Sí como patrón de coordinación. Anthropic documenta que Opus 5 coordina equipos de subagentes bien, con pocos casos de agentes que se pisan el trabajo entre ellos. Lo que deja de tener sentido es el verificador reflejo: un subagente revisando cada tarea pequeña que el modelo ya ha revisado solo.
¿El tope de subagentes va en el prompt o en el código?
En el código. Un tope en el prompt es una sugerencia que el modelo pondera junto a su comportamiento por defecto; en el harness se cumple siempre, sea cual sea el modelo. El prompt sirve para la guía cualitativa —qué escenarios justifican delegar—, no para el límite duro.
¿El default de delegación también cambia entre versiones de otros proveedores?
El comportamiento por defecto al delegar es una propiedad de cada modelo, no del proveedor, así que asumir que se mantiene estable entre versiones es mala idea con cualquiera. Los datos de este post proceden de la documentación de Anthropic sobre Claude Opus 4.6, 4.7 y 5, que lo recoge de forma explícita; si trabajas con otro proveedor, búscalo en su guía de migración antes de dar tu ajuste por bueno, y si no lo documenta, con más razón pon el tope en el harness: lo que no está escrito puede cambiar igual, solo que sin avisarte.
Por Bezael Pérez — Developer senior con más de 15 años de experiencia y fundador de Dominicode.