Costs · October 28, 2026 · 9 min read

Budget caps for agent runs: turn limits, token budgets and provider spend limits

A runaway agent loop can cost ten times a normal run before anyone notices. Here is how to cap a single run with turn limits and token budgets, how provider spend limits behave when you hit them, and why your retry logic needs to know the difference.

Some links are affiliate links; we may earn a commission at no extra cost to you. As an Amazon Associate I earn from qualifying purchases. Disclosure

Most agent cost advice is about making each call cheaper: shorter prompts, better caching, a smaller model for easy steps, batch pricing for work that can wait. That advice matters, and we have covered it in our guides to tool-calling costs, context compaction and batch APIs. But the most expensive agent runs are rarely the ones with a bloated prompt. They are the ones that never stop. A model that keeps calling the same failing tool, a planner that keeps rewriting its plan, or two agents politely handing a task back and forth can burn through a month of budget in an afternoon. This article is about the other half of cost control: putting hard ceilings on how much a single run, a single project and a whole organization can spend, and making sure your code reacts correctly when one of those ceilings is hit.

Why one runaway run costs so much

Agent loops get more expensive with every turn, not just more numerous. Each model call re-sends the conversation so far, and each tool result and model reply makes that conversation longer. Here is a worked example using Claude Sonnet 5.5 at the $2 per million input tokens and $10 per million output tokens listed on Anthropic's pricing page. Suppose a run starts with an 8,000-token prompt, and each turn adds about 3,000 tokens of tool output and model text while producing about 500 output tokens.

A healthy run that finishes in 10 turns sends about 215,000 input tokens in total, which is roughly $0.43, plus 5,000 output tokens for $0.05. Call it 48 cents. Now let the same run get stuck and keep going to 40 turns. The input side grows to about 2.66 million tokens, or $5.32, and output reaches 20,000 tokens for another $0.20. That is about $5.52 for one run, more than eleven times the healthy one, before any caching discount. Four times the turns cost eleven times the money because the context keeps growing. Caching softens the input side, but it does not change the shape of the curve, and a loop that keeps adding new tool results keeps adding uncached tokens at the end of the prompt.

The lesson is that the length of a run, not just the price per token, is a cost variable you need to control directly. That is what turn limits and token budgets are for.

Turn limits: the cheapest safety net

Every serious agent framework has a cap on how many times the loop can go around. In the OpenAI Agents SDK, the runner calls the model, runs any tool calls, appends the results and calls the model again, and if the run exceeds the max_turns value you pass, it raises a MaxTurnsExceeded exception. You can pass max_turns=None to turn the limit off, which is exactly what you should not do in production. The SDK also accepts error_handlers keyed by error kind, including "max_turns", so instead of crashing you can return a controlled final answer such as "I couldn't finish within the turn limit. Please narrow the request." The documentation's own example sets max_turns=3 for a transcript analysis task and installs that kind of handler.

LangGraph has the same idea under a different name. Its graph API documentation describes a recursion limit on the number of super-steps a graph can execute in one invocation. When the limit is reached, LangGraph raises GraphRecursionError. Since version 1.0.6 the default is 1,000 steps, and you override it per call with config={"recursion_limit": 5}. A thousand steps is a guard against infinite loops, not a budget. For a support agent that normally finishes in a handful of steps, a limit in the low tens is much closer to what you actually want to pay for.

LangGraph also lets a graph see the limit coming. The current step counter is available in config["metadata"]["langgraph_step"], and a RemainingSteps managed value in the graph state tracks how many steps are left. The documentation's example routes to a fallback node when two or fewer steps remain, and that node returns a best-effort answer instead of letting the run fail. This is the pattern worth copying in any framework: when the run is close to its ceiling, stop exploring and summarize what you have. A partial answer the user can act on is better than an exception and a bill.

How do you pick the number? Look at your traces. If 95 percent of successful runs finish in eight turns or fewer, a limit of 15 or 20 leaves room for honest hard cases while cutting off the long tail of loops. Set it per agent rather than globally, because a research agent and a form-filling agent have very different healthy lengths. Our guide to evaluating agent tool calls covers how to collect the trace data that makes this choice evidence-based instead of a guess.

Token budgets: counting what you actually pay for

Turn limits are coarse. Two runs with the same number of turns can differ in cost by a factor of ten if one of them pulls a large file into context. For a tighter ceiling, track tokens as the run progresses and stop when a budget is spent.

The OpenAI Agents SDK makes this straightforward. Its usage documentation explains that the SDK tracks token usage for every run and exposes it at result.context_wrapper.usage. The object counts model requests, input tokens, output tokens and their total, and it breaks out cached input tokens, cache write tokens and reasoning tokens. There is also a per-request list, request_usage_entries, so you can see which turn was the expensive one. Usage is aggregated across every model call in the run, including calls that only produce tool calls or handoffs. The same object is passed to RunHooks, so a hook can check the running total at lifecycle points and log it, or end the run, once a threshold is passed.

Two details from that page are easy to miss. First, when you use a session, each Runner.run() call reports usage only for that run, even though earlier messages are re-sent as input. If your budget is per conversation rather than per run, you have to add the runs up yourself. Second, usage reporting through third-party adapters varies. The SDK notes that some LiteLLM backends do not report usage by default and often need ModelSettings(include_usage=True). A budget check that reads zero because the provider never sent a number is worse than no check at all, so validate usage reporting on the exact backend you deploy.

Turning tokens into dollars is simple arithmetic once you have the counts. Multiply input, cached input and output by the per-million prices for the model, keep the prices in one config file, and check the running total after every model call. Reasoning tokens deserve special attention, because they are billed as output even when you never see them. Our article on reasoning models in agent loops explains how output caps like max_output_tokens interact with thinking, which is the per-call version of the same budget.

Provider spend limits: the backstop for everything else

Run-level limits protect you from one bad run. They do nothing about a bug that starts thousands of normal-looking runs, a leaked key, or a cron job that fires every minute instead of every day. For those, the providers offer account-level ceilings, and each one behaves a little differently.

OpenAI's spend limits guide separates spend alerts, which only send a notification while traffic continues, from hard spend limits, which stop traffic. You can set a monthly hard limit for the whole organization or for an individual project. When one is reached, requests fail with HTTP 429 and an error code of organization_spend_limit_exceeded or project_spend_limit_exceeded. OpenAI warns that enforcement is not instantaneous, so recorded spend can slightly exceed the limit. Its production best practices page also recommends separate projects for development and production, each with its own rate and spend limits, which is the easiest way to stop a test harness from eating the production budget.

Anthropic's rate limits page describes two kinds of ceiling. Each usage tier has a monthly spend cap: $500 for Start, $1,000 for Build and $200,000 for Scale, with Custom tier limits arranged with the account team. When an organization hits its tier cap, usage pauses until the first of the next month, and requests return HTTP 429 with an error_code of enforced_spend_limit_reached on the Messages API. You can also set your own lower limit on the Console's billing page, and when that limit is reached, requests return HTTP 400 with an invalid_request_error whose message says you have reached your specified usage limits. Workspaces can carry their own limits too, though not the default workspace.

Google's Gemini API billing page lists monthly spend caps at both the billing account tier and the project level, with tier caps of $250 for Tier 1, $2,000 for Tier 2 and $20,000 to $100,000 for Tier 3. Project owners and editors can set a per-project cap in AI Studio. Google is candid about the gaps: billing data can take around ten minutes to process, and long-running work such as batch jobs and agent sessions may run past a project cap before it takes effect. Spend caps are also not available on invoiced accounts.

The pattern across all three is the same. Provider limits are a monthly backstop with some lag, not a precise per-run meter. Set them, set alerts below them, and keep a separate production project so one experiment cannot exhaust it. Then do the precise work in your own code.

Teach your retry logic the difference

This is where budget caps meet error handling. Many agent stacks retry every 429 with exponential backoff, on the assumption that a 429 means "slow down and try again." A spend limit also returns a 429 on OpenAI, and on Anthropic when the tier cap is reached. Anthropic's documentation says plainly that retrying, including the SDK's automatic retries, fails until access resumes, which may be the first of next month. A loop that retries those errors does not recover; it just keeps the agent spinning and the logs filling up.

So check the error code before retrying. On OpenAI, treat organization_spend_limit_exceeded, project_spend_limit_exceeded, organization_usage_limit_exceeded and credit_balance_exhausted as stop conditions that page a human, not as transient failures. On Anthropic, treat enforced_spend_limit_reached and a 400 that reports a reached usage limit the same way. Real rate limits still get backoff, as described in our guide to handling tool errors in agent loops. The agent should end the run with a clear message that the service is out of budget, which is something a user or an operator can act on.

A layered setup that fits on one page

Put together, a sensible budget design has four layers. Each run gets a turn limit sized from real traces, with a handler that returns a partial answer instead of an exception. Each run also carries a token or dollar budget that is checked after every model call, using the usage numbers the SDK reports and prices from one config file. Each environment lives in its own provider project with a hard monthly limit and alerts set well below it. And the retry layer knows that a spend-limit error means stop, not wait. None of this makes a single call cheaper. It makes sure the rare bad run costs a few dollars instead of a few hundred, and that you hear about it the same day.

Hard ceilings on spend are part of shipping any production ML system. Designing Machine Learning Systems by Chip Huyen covers operational guardrails and feedback loops that apply just as well when the unit of work is an agent run instead of a batch prediction job.

If you run models on your own machine, we keep a short list of local LLM gear — GPUs, Macs, RAM and storage — with plain-text Amazon links.