Claude Code ha establecido un tope por defecto de 20 subagentes concurrentes, de forma que un solo mensaje ya no puede disparar un número ilimitado de agentes en segundo plano. El mismo cambio corrige un comportamiento que pasaba desapercibido y que era más costoso de lo que parece: --max-budget-usd ahora detiene los subagentes que ya están en ejecución al alcanzar el límite, en lugar de limitarse a impedir que arranquen otros nuevos. Son dos ajustes sin interfaz que no aparecerán en ninguna captura de pantalla, pero cambian el comportamiento de flujos que ya tenías montados.
Un solo mensaje podía abrir agentes sin techo
Para entender por qué hacía falta el límite conviene mirar cómo se llega a la situación. Nadie escribe «abre cien agentes». Lo que se escribe es algo perfectamente razonable —revisa todos los módulos de este proyecto, analiza cada archivo de esta carpeta, comprueba las dependencias de cada componente— y es la herramienta la que decide cuántas ramas paralelas necesita para cumplirlo. Cuando el objeto de la petición es una lista larga, el número de agentes lo marca el tamaño del repositorio, no la intención de quien escribió el mensaje.
Ese es exactamente el tipo de problema que un valor por defecto resuelve mejor que cualquier advertencia en la documentación. El usuario que se ve afectado no es el que abusa de la herramienta, sino el que la usa con normalidad sobre un proyecto grande y descubre a posteriori que la máquina se quedó sin aire o que la sesión consumió mucho más de lo previsto. Un techo de veinte cierra el escenario peor sin estorbar al caso normal.
Porque veinte, conviene decirlo, es un número alto para el trabajo cotidiano de un freelance. Las tareas habituales —revisar un plugin, comparar dos implementaciones, comprobar un puñado de archivos— se resuelven con un número de ramas paralelas que se cuenta con los dedos de una mano. El límite no está pensado para frenarte a ti en un día normal: está pensado para que el caso extremo tenga un final.
Nadie pide cien agentes. Se pide «revisa todos los módulos», y es el tamaño del repositorio el que decide cuántos se abren.
El tope de gasto que no frenaba lo que ya estaba corriendo
La segunda mitad del cambio es la más importante para quien trabaja con presupuesto cerrado, y es la que menos titular tiene. La opción --max-budget-usd existe para poner un techo de gasto a una sesión. Hasta ahora, al alcanzarse ese techo, la herramienta impedía lanzar subagentes nuevos, pero los que ya estaban trabajando seguían trabajando. Y consumiendo.
La diferencia entre esos dos comportamientos es pequeña sobre el papel y grande en la factura. Si el límite se alcanza en el momento en que hay una docena de agentes activos, cada uno de ellos continúa hasta terminar su tarea. El gasto final no es el límite que fijaste: es el límite más lo que costara cerrar todo lo que estaba en vuelo. Cuanto más paralelo el trabajo, mayor la diferencia, que es justo lo contrario de lo que uno espera de un tope de seguridad.
Corregido esto, la opción pasa a comportarse como cabe esperar de algo que se llama límite máximo. Y eso la convierte, ahora sí, en una herramienta utilizable para presupuestar: si un proyecto tiene un margen concreto para la parte automatizada, se puede fijar y confiar en él.
💸 Si presupuestas por proyecto
Revisa las sesiones donde ya venías usando un tope de gasto: hasta este cambio, el consumo real podía superar la cifra fijada por todo lo que quedaba en ejecución al tocar el límite. Si en algún proyecto te cuadró peor de lo esperado, probablemente la explicación esté aquí y no en un cálculo mal hecho.
Qué mirar en tus flujos antes de que el límite aparezca
La consecuencia práctica más inmediata afecta a las tareas de barrido: las que recorren un proyecto entero en lugar de trabajar sobre un punto concreto. Si tienes alguna rutina de ese tipo —una auditoría completa de un sitio, una revisión de todos los archivos de un tema de WordPress— es posible que hasta ahora estuviera abriendo más ramas paralelas de las que imaginabas. Con el nuevo tope no dejará de funcionar, pero puede tardar más, porque lo que antes se repartía de golpe ahora se encola.
Ese cambio de tiempos importa si la tarea vive dentro de una automatización con espera limitada. Un flujo de n8n que lanza una revisión y espera respuesta puede tener configurado un tiempo de espera calculado sobre el comportamiento anterior. No es un problema grave, pero sí de los que se descubren en el peor momento: cuando el flujo se ejecuta solo, de madrugada, y falla por tiempo agotado sin que nadie lo mire hasta la mañana siguiente.
La diferencia entre un asistente y algo que gasta tu dinero
Estos dos ajustes describen bien una transición que lleva meses ocurriendo. Poner un techo a la concurrencia y hacer que un límite de gasto frene de verdad son decisiones propias de una herramienta que consume recursos reales en nombre de quien la usa, no de un asistente que responde preguntas. Es el mismo tipo de salvaguarda que cualquier servicio serio acaba incorporando cuando descubre que la petición razonable de un usuario razonable puede escalar sola.
Para el lector que factura por proyecto, la lectura útil es que los valores por defecto de la herramienta forman parte de su presupuesto, aunque nunca los haya mirado. Merece la pena dedicar un rato a saber cuáles son los tuyos hoy —cuánta concurrencia toleras, qué tope de gasto tienes fijado, qué pasa cuando se alcanza— antes de que un cambio de comportamiento te lo explique por la vía cara.
