Written by AI agents, curated and verified by me.
Session budgets in Claude Managed Agents: the cap is a pause, not a kill switch
- Claude
- Agentic Engineering
- Automation
- Verification
On 7 August, Anthropic added four changes to Claude Managed Agents in the release notes: a budget per session, an advisor in the multiagent roster, a control for where inference runs, and skills loaded from a GitHub repository. Three of them are configuration. One is a control primitive for long runs, and it is interesting because it works differently from what the name suggests: the budget does not abort the session, it pauses it.
What is in the entry of 7 August?
First, you can set a budget on a Managed Agents session, a hard cap on the session’s spend, priced at public list rates. A session that reaches its budget pauses with the budget_reached stop reason instead of starting new model requests. Changing or removing the budget resumes it. Deployments accept the same budget and apply it to each session they start.
Second, a session can be given an advisor: a model at least as capable as the agent’s own, which the session’s primary thread can consult mid-turn for strategic guidance. You configure it as a {"type": "advisor"}entry in the agent’s multiagent roster, naming the model to consult.
Third, you can control where model inference runs for an agent. inference_geo sits inside the model object when you create the agent, and it can be overridden for a single session. Which geos exist and what they cost is in the data residency documentation, not in the release entry.
Fourth, sessions can load skills from a GitHub repository. When a session mounts a repository, any skills in its root .claude/skills directory are discovered automatically at session start and are available to the agent for that session.
Why is the budget more than cost control?
Because the semantics differ. A cost limit that ends a session is an emergency brake. You pull it after something went wrong, and the run is gone. A limit that pauses, and that resumes when you change the budget, is something else: a predetermined stopping point. The run holds, the state stays, and the question “continue or not?” lands with someone who has to answer it.
That is the point. Long agent runs rarely have a problem starting. They have a problem stopping. An agent that cannot solve a task does not stop trying, it just gets more expensive. The usual answer so far was observation: you watch cost and runtime and step in. The budget reverses the direction. The session reports itself, before it issues the next model request.
With Grok 4.5 in July I argued that the price per token says little until you know the cost per task. A session budget is the practical flip side. You do not need to know the cost per task up front. You decide what an answer is worth to you, and the platform stops when the amount is reached. That is no replacement for measuring. It is a boundary that holds while you are looking elsewhere.
Read one limitation along with it. The entry says a deployment applies the same budget to each session it starts. That is a per-session cap, not a shared pool. Start many sessions and you have bounded the spend per run, not the total.
What does the advisor change structurally?
Multiagent setups usually delegate downward: a strong model hands subtasks to smaller, cheaper ones. The advisor goes the other way. What gets consulted is a model at least as capable as the agent’s own, mid-turn, for strategic guidance. Not to offload work, but to check a direction.
That costs money. A consultation is a model request, so it falls under the spend of the same session you just capped. The two changes work on each other: the advisor allows more expensive intermediate steps, and the budget bounds how many of them a session may afford. How good the advice actually is, the entry does not say, and I would not guess. That is a measurement, not an opinion.
Where do the skills come from?
From the repository the session mounts, automatically, at start. The convenience is obvious: skills live in the same repo as the code, they are versioned and reviewed with it. The flip side is just as obvious. What sits in .claude/skills determines what the agent can do in that session, and it is not approved item by item, it is discovered. A pull request that changes a file there changes the behaviour of your agents.
Treat that directory as executable code, not as documentation. Mandatory review, clear ownership, no exception for “it is only instructions”. The same day, the Codex CLI changelog raised a similar question for plugin catalogs: where capabilities come from becomes a supply chain as soon as it is convenient enough.
What does this mean for your work?
First, set a budget before you start the first long run, not after. The amount may be rough. It only has to exist, so that budget_reached becomes your normal end state instead of an invoice at the end of the month.
Second, decide who determines whether a paused session continues, and on what basis. A stopping point without a responsible human is just a delayed continuation.
Third, settle inference_geo with the same people who decide data residency at your company. That it can be overridden per session is practical, and it also means one session can deviate from your default.
All four items are architecture, not model quality. That is the point of agentic engineering: reliability lives in the setup. A budget that pauses is a built-in place where a human re-enters. That human was answerable for the run all along.