Can you put a hard spending cap on an AI agent?

Yes, and the cap stops the next model request rather than the invoice. Anthropic's session budgets pause a Claude Managed Agents session with a budget_reached stop reason once its running list cost reaches the ceiling you set. The request already in flight finishes, and it bills.

The mechanism is the granularity of enforcement. Every money cap on offer is checked at a boundary, either between two requests or between two propagation cycles, and work that got past the boundary before the check ran completes anyway. A cap bounds new work. An invoice counts finished work.

What does a session budget cap, and by how much can it overshoot?

The platform prices what a session consumes at public list rates: model tokens at each served model's price, web searches at $10 per 1,000, and session running time at $0.08 per hour. That running total is the session's list cost, and it is what the cap compares against. Once it reaches the cap, every thread pauses before its next request and the session goes idle. Nothing is terminated. The history and the sandbox are preserved the way they are on any other idle session.

The overshoot is documented rather than left for you to discover. Anthropic's own example: a session capped at "50", meaning 50 cents, can pause with a recorded list_cost of "53", because the request that carried the total past the cap was admitted while the session was still under it. The bound is one model request per thread. A multiagent session shares one budget across its threads with no per-thread caps, so that bound scales with the number of threads you are running.

One unit trap, and it costs a factor of a hundred in either direction. The amount field is a whole number of US cents written as a string. "125" is $1.25. Decimal forms such as "25.00" are rejected outright, which is the friendlier failure.

Why is the cap priced at list rates and not at what you pay?

Because the platform can only enforce against a number it publishes. The documentation says it plainly: list cost is not your contracted price, and if your organization has negotiated discounts, the session reaches its cap when the list-price total does while your billed spend is lower. A team on a 30% discount setting a $20 cap has built a $14 circuit breaker, and the console will not tell them.

The same rule has a sharper edge. A budget can only track consumption the platform can price, so a budgeted session that comes to use a model with no public list price can pause at budget_reached with the budget no longer able to measure anything, and changing that budget is then rejected. Remove it to get the session moving again. That is the documented way out and the only one.

What can a spend cap not stop?

Whatever your own client is already holding. At or over the budget, the session still accepts four event types, all of which settle work in progress: user.tool_confirmation, user.tool_result, user.custom_tool_result and user.interrupt. Anything that would start new work, user.message included, is rejected with a 400 naming that list.

So the tool call the model emitted before the pause is still sitting in your process, and running it is your decision rather than the platform's. This is the seam described in How do you stop an AI agent from doing the same thing twice?: the layer that spends money is the model call, the layer that touches the world is the tool call, and the two stop at different moments. We built OFFSET, which files declarations directly to the ΑΑΔΕ portal. A cap landing mid-run stops the spending.

The budget stopped the model. The form was already submitted.

How fast does a stuck loop spend against a cap?

A loop that has stopped making progress on Claude Opus 5.5 spends either $14.40 an hour or $151.20, and the variable is prompt caching. Prices checked by Unity Horizon on 25 September 2026 against Anthropic's pricing page: Claude Opus 5.5 is $4 per million input tokens and $20 per million output, with cache hits at $0.20 per million, which is 0.05x base input rather than the usual 0.1x.

Take one request out of that loop, carrying 200,000 tokens of context and writing 2,000 tokens back.

Context on this request	Input	Output	Per request
All cache hits	$0.04	$0.04	$0.08
All cache misses	$0.80	$0.04	$0.84

At one request every 20 seconds, that is $14.40 an hour on hits and $151.20 an hour on misses. Session runtime at $0.08 an hour rounds away next to both. A $20 cap therefore buys about 83 minutes of the first loop and under 8 minutes of the second.

Same cap, same model, same agent, ten times the runway. What moved it was whether the loop keeps rewriting its own prefix, which is the same behaviour we costed in Does trimming an AI agent's context save money?.

Which caps exist, and what does each one miss?

Cap	Where it lives	Unit	What it does not cover
Session budget	Claude Managed Agents	US cents at list price	The in-flight request, and the tool result your client is holding
Task budget	Messages API, beta	Tokens, advisory	Enforcement. The docs call it a soft hint, not a hard cap
max_tokens	Any Messages API request	Output tokens, per request	The next request, and the whole input side of the bill
Spend limit	OpenAI organization or project	US dollars, per billing period	Usage inside the propagation delay
max_turns	OpenAI Agents SDK runner	Turns	Money, because a turn has no price

Two rows deserve their footnotes. Task budgets inject a countdown that only the model sees, carry a minimum of 20,000 tokens, and are described in the documentation as a soft hint that Claude may exceed when interrupting an action would be worse than finishing it. OpenAI's spend limits return a 429 with organization_spend_limit_exceeded or project_spend_limit_exceeded, under a sentence worth reading twice: "Enforcement is not instantaneous, so recorded spend can slightly exceed the configured amount."

A cap of this shape suits the team running one long session with somebody watching it. It does much less for the team running a thousand short sessions on a schedule, because a deployment's budget is copied onto each session it starts rather than summed across them. A deployment capped at "2000" can spend about $20 on every run, cron granularity goes down to the minute, and an hourly schedule turns that $20 into $480 a day. The vendor bounded the session. Finance is counting the month.

What to set before an agent runs unattended

Set the cap at creation. A budget can only be attached when the session is created, and adding one afterwards returns a 400, so an agent already running uncapped stays uncapped for the rest of its life. That is the door that shuts quietly.

Treat removal as permanent. A session whose cap you removed cannot be given a new one, which turns "drop the budget to unblock the run" into a decision somebody should make on purpose.

Raise a cap from the right number. The new value has to clear the consumed list cost strictly, and the reported figure is rounded to the cent, so read usage.list_cost and set the new value at least a cent above it. Read the events rather than polling a bill: a session.usage event carrying cumulative tokens and list cost always immediately precedes the idle event that reports budget_reached.

Then write the turn cap anyway. The OpenAI Agents SDK raises MaxTurnsExceeded when a run exceeds max_turns, and max_turns=None switches the limit off. It counts turns rather than dollars, which makes it the wrong unit and the only one that binds on a plain Messages API loop.

We have not run enough budgeted sessions to the cap to publish our own distribution of the overshoot in cents. The one-request bound above is Anthropic's documented bound, and the per-hour figures are arithmetic over published list prices rather than an invoice we have paid. If you have counted the overshoot across your own sessions, we would rather quote your figure than reason from a documented bound.

What is the largest amount one of your agents could spend between now and Monday morning with nobody watching, and which line of your code enforces that number? If no line does, that is the kind of work we scope.