Desde el 7 de agosto de 2026, una sesión de Managed Agents de Claude acepta un presupuesto en dólares al crearse: al agotarlo se pausa con el motivo budget_reached en vez de seguir gastando, y se reanuda si cambias o quitas el tope. La misma actualización deja que una sesión cargue solas las skills que encuentre en la carpeta .claude/skills del repositorio que montas, sin subirlas a mano.
Esta guía asume que ya usas la API de Claude y que tienes acceso a Managed Agents. Los cinco pasos se hacen con curl o con el SDK; aquí van en curl porque es lo que deja ver cada campo tal cual lo espera la API.
Un presupuesto de sesión es un tope duro de gasto, opcional, que fijas al crear la sesión. La plataforma le pone precio en tiempo real a todo lo que la sesión consume, a tarifa de lista pública: los tokens de modelo al precio de lista de cada modelo que sirvió esa respuesta, las búsquedas web a 10 dólares por cada mil, y el tiempo que la sesión estuvo activa a 0,08 dólares por hora. La suma de eso es el "costo de lista" de la sesión, y es lo que el presupuesto vigila.
Ojo con un matiz: el costo de lista no es necesariamente lo que te cobran a ti. Si tu organización tiene descuentos negociados, la sesión igual se detiene cuando el total a precio de lista llega al tope, aunque tu factura real sea menor.
El presupuesto solo se puede fijar en el momento de crear la sesión — agregárselo después a una sesión que no lo tenía devuelve un error 400. Se manda al llamar a la API de sesiones (POST a /v1/sessions, con el encabezado beta managed-agents-2026-04-01) como el campo budget, con dos partes: type, que siempre es "limit", y max_list_cost, el tope mismo, expresado en centavos de dólar como texto dentro de un objeto con su moneda: "2500" son 25 dólares, "50" son 50 centavos, y no se aceptan formas decimales como "25.00" porque el monto viaja como texto para que ningún redondeo de punto flotante lo altere.
El presupuesto sí se puede cambiar o quitar en cualquier momento después de creado, solo no se puede añadir de cero a una sesión que arrancó sin él. Si administras despliegues (deployments), el mismo presupuesto se aplica a cada sesión nueva que ese despliegue arranque.
El tope se revisa entre una petición al modelo y la siguiente, no a mitad de una petición: la que ya iba en camino cuando se cruza el límite termina de correr. Por eso una sesión con tope de 50 centavos puede pausarse reportando 53 centavos consumidos — no es un error de cobro, es el margen esperado de una petición por hilo. Trata el presupuesto como un límite sobre trabajo nuevo, no como un punto de corte exacto, y déjale ese margen al fijar el número.
Cuando la sesión llega al tope no se termina: queda en reposo con el motivo budget_reached, y su historial y su sandbox se conservan igual que en cualquier sesión en reposo. En el flujo de eventos vas a ver, en orden, un evento de hilo en reposo con ese motivo, un evento de uso con el costo acumulado, y un evento de sesión en reposo con el mismo motivo. Diseña tu corrida para que un cierre en budget_reached entregue lo que alcanzó a hacer, no para que lo trate como una caída.
La misma actualización del 7 de agosto agrega esto: cuando una sesión monta un repositorio como recurso github_repository, la plataforma escanea la carpeta .claude/skills en la raíz del repositorio al arrancar la sesión, y cada skill que encuentra ahí queda disponible para el agente sin que la subas a mano ni la declares en el arreglo de skills del agente.
El escaneo espera exactamente esta forma, un nivel bajo la raíz — tu-repo/.claude/skills/nombre-skill/SKILL.md —; un SKILL.md suelto o anidado dos niveles no se detecta al arrancar la sesión.
Para activarlo, la sesión se crea igual que en el paso 2, pero en vez del campo budget se manda un arreglo resources con un objeto de tipo github_repository: la URL del repositorio y, si es privado, un authorization_token con permiso de lectura sobre él. La plataforma escanea .claude/skills apenas la sesión arranca, antes de que el agente reciba su primera instrucción.
Una skill de repositorio es una instrucción para el agente, y un repositorio montado pasa a ser parte de lo que el agente confía. Cualquiera que pueda escribir en ese repositorio — un pull request externo aceptado, una dependencia comprometida, un colaborador — puede agregar o cambiar una skill, y la plataforma la carga al arrancar la sesión sin pedir revisión. Con herramientas como bash o acceso web habilitadas, esa skill tiene alcance real. Monta solo repositorios en los que confíes, y revisa .claude/skills antes de montar uno que acepte contribuciones externas.