Anthropic ha añadido topes de presupuesto a las sesiones de Claude Managed Agents. Se fija un límite duro de gasto por sesión, valorado a tarifa pública de lista, y cuando la sesión llega ahí se para en seco con el motivo `budget_reached` en vez de lanzar una petición más al modelo.
Puntos clave
- El tope es por sesión y se calcula a precio de lista público.
- Al alcanzarlo, la sesión se pausa. No lanza nuevas peticiones al modelo y devuelve `budget_reached` como motivo de parada.
- Se puede subir el presupuesto o quitarlo para que la sesión continúe donde estaba.
- Los despliegues aceptan el mismo parámetro y lo aplican a cada sesión que arrancan.
- La misma tanda incorpora un "advisor": un modelo al menos tan capaz como el del propio agente, al que el hilo principal puede consultar a mitad de turno para pedir criterio.
- También llegan control geográfico y skills cargadas desde GitHub.
El problema real que esto resuelve
Un agente que trabaja solo durante horas es útil hasta el momento en que se atasca. Y cuando se atasca, no se para: reintenta. Vuelve a leer el mismo fichero, vuelve a probar la misma llamada que falla, vuelve a razonar sobre el mismo error.
Ese bucle no genera un aviso. Genera tokens. Y la primera noticia que tienes suele ser el gráfico de consumo del día siguiente.
Un tope duro por sesión convierte ese riesgo en un número que decides tú de antemano. No arregla el atasco, pero acota lo que cuesta. Que es exactamente lo que se le pide a un límite de gasto: no evitar el error, evitar que el error salga caro.
Que la parada sea explícita importa más de lo que parece
El detalle de `budget_reached` como motivo de parada tiene consecuencias prácticas. Una sesión que se corta con un error genérico obliga a investigar qué pasó. Una que se corta con un motivo nombrado se puede tratar en el código: registrarlo, avisar a alguien, decidir si se sube el presupuesto o si esa tarea merecía pararse.
Y el hecho de que la sesión se pause en vez de morir significa que el trabajo hecho hasta ahí no se tira. Subes el tope y sigue. En un agente que lleva dos horas de contexto acumulado, esa diferencia es horas de trabajo.
Que los despliegues hereden el mismo tope cierra el hueco por el otro lado. De poco sirve limitar una sesión si el sistema que las lanza puede abrir doscientas.
El advisor va en la otra dirección
La segunda pieza es curiosa porque empuja al contrario: un modelo al menos tan capaz como el del agente, disponible para que el hilo principal le consulte a mitad de turno.
Es una forma de dejar que un agente barato corra la mayor parte del tiempo y pida ayuda cara solo cuando la necesita. La misma lógica de enrutado que Nvidia acaba de empaquetar en Switchyard, aquí metida dentro del propio agente.
Las dos funciones juntas dibujan bien hacia dónde va esto: agentes que corren solos mucho tiempo, con un techo de gasto y con la posibilidad de consultar hacia arriba.
Por qué importa
Si tienes agentes en producción o estás a punto de tenerlos, el tope de gasto es de las primeras cosas que hay que configurar, antes que casi cualquier optimización.
La regla que funciona en la práctica: pon el límite en lo que estarías dispuesto a perder si esa sesión sale mal del todo, no en lo que crees que va a costar si sale bien. Son números muy distintos, y el segundo es el que la gente configura antes de aprender por qué no debía.
Relacionado
