Why AI Agents Burn Budget Without Finishing, and How to Stop Them

An autonomous agent that crashes is easy to deal with. The expensive failure is the one that never crashes: it keeps calling tools, keeps producing reasonable-looking steps, and never reaches the finish line, while the token meter runs. This article explains the mechanism behind that behaviour, where the spend in a runaway agent typically accumulates, and the concrete stop conditions that prevent it, so that you can design agent loops that know when they are finished rather than relying on a larger budget to absorb the waste.

Consider a modest example: an unattended afternoon run that bills 40 dollars and delivers nothing. By agent-operations standards that is small change; teams trade stories of unmonitored overnight runs that reached four-figure totals. The size of the bill is not the interesting part. What matters is what it bought. The agent was not stuck and raised no error anyone could point to. It was busy the whole time, working on nothing.

What a runaway agent looks like in the transcript

Open the log of an agent that has gone off course and you will rarely find a stack trace. What you find reads like a conscientious employee who has lost track of what the assignment was.

The agent opens a file and summarizes it, then opens the same content framed a little differently and summarizes it again. It issues a search, judges the answer not quite satisfying, and reissues the query with a couple of words swapped. Each step, viewed alone, is defensible. That is precisely why the pattern is hard to spot by skimming: no single entry looks broken. The run simply never converges.

Why the model decides when it is done

The behaviour has a concrete cause that is worth understanding if you build or operate agents. Each response from a tool-calling model such as Claude ends with a stop reason drawn from a short, fixed list. Anthropic's guide to handling stop reasons covers several cases; two matter most for agent loops. The first signals that the model believes its work is complete:

"stop_reason": "end_turn"

The second signals that it wants to invoke a tool and continue:

"stop_reason": "tool_use"

An agent loop is ordinary application code. It sends a request, executes any tool the model asks for, sends the result back, and repeats until the model returns end_turn. Nothing outside the model declares the task finished. On every turn the model makes that call itself, judging whether the work in front of it seems complete. Other stop reasons exist, such as hitting the output token limit, but those are interruptions, not a judgement that the job is done.

That single fact explains the whole failure. When the goal is too loose for the model to tell that it has arrived, there is always another thing worth checking, and the loop continues until something external, typically a budget alert, intervenes. For a code-level treatment of loop design, see bounded agentic loops and reliable TypeScript patterns for LLM tool use.

How common this is

It is tempting to write this off as a quirk of one particular tool. Broader evidence suggests otherwise. A RAND Corporation study based on interviews with 65 seasoned data scientists and engineers put the failure rate of AI projects above 80 percent, roughly double that of conventional IT work. That study is about AI projects in general, not agents specifically, but loops that spin without delivering value are one of the mundane, day-to-day contributors to waste of that kind. They never feature in conference keynotes; they appear on invoices.

Larger versions of the story circulate as well. A frequently cited report tells of one recursive loop whose charges climbed into five figures before anyone intervened. That figure has not been independently verified, and any single dramatic number like it deserves some scepticism. The mechanism, however, is real, and it only scales upward: the same loop that spends 40 dollars in an afternoon can spend 4,000 across an unwatched weekend.

Where the spend accumulates

When you examine runaway costs, and compare them with what operators of large agent fleets report, the money tends to pool in the same few places:

• Unbounded web research. Every page fetched and every repeated search has a cost. Without a cap, open-ended research goes on while the model still believes another worthwhile source might be out there.
• An expensive model on cheap work. Frontier models cost more because they reason better, but many agent steps, such as reformatting a file, checking a status or retrying a call, need none of that capability. A smaller model would handle them for a fraction of the price.
• Threads that never end. An agent working inside one long conversation reprocesses its entire accumulated history each turn, which makes a weeks-old thread pricier per request now than when it began, however small the request. Prompt caching can soften this where your provider supports it, but the context still grows.
• Forgotten schedules. A recurring job configured once keeps firing long after anyone uses its output.

None of these is exotic. Together they behave like a forgotten subscription that charges by the token instead of by the month. For a structural view of how these costs compound, the article on why agentic AI costs explode goes deeper.

Fix the stop condition, not the ceiling

After an expensive run, the instinctive response is to lift the step or spending limits. That usually backfires, because a taller ceiling only lets the same stuck loop spin longer before it collides with it. What actually helps is giving the loop a way to notice that progress has stalled, which is a different question from whether it has used up its allowance of steps.

Put the finish line in the goal

Define "done" as part of the task, not as an afterthought. An instruction like "fix the failing test" leaves room for side quests such as tidying imports or reformatting the whole file. "Get this single test passing, then end" supplies an endpoint the model can actually detect. The more observable the completion criterion, the easier it is for the model to return end_turn at the right moment.

Make tool results unambiguous

Tool feedback should say clearly whether an action succeeded or failed. An unclear result reads to the agent as an invitation to retry, not as a signal to halt. Explicit status fields and clear error messages remove the uncertainty that fuels retries.

Detect repetition instead of counting steps

A fixed step counter is a blunt instrument. The same counter might abort a valid 15-step job at step 11 while allowing a 2-step cycle to waste several further costly calls before it fires. A much better signal is repetition: flagging back-to-back calls to one tool with identical arguments catches the pattern described earlier directly, without penalizing tasks that are simply long.

Add a human checkpoint and a hard spending guard

Any job left alone for longer than a few minutes should include a moment where a human looks at progress. Automated guards complement this. For example, GitHub's gh-aw ships a credit guardrail you can configure to stop a workflow the instant its spend passes a chosen limit, rather than leaving detection to whoever reads the invoice. A guard like this is a safety net, not a substitute for a good stop condition, but it caps the damage when everything else fails.

Activity is not progress

The most unsettling part of a runaway run is not the cost but the confidence. The agent's output never hedges and never admits uncertainty about whether any of the work is helping. It produces plausible steps until something external, often a person curious about an unexpected bill, stops it.

The lesson is not to trust agents less across the board. It is to stop mistaking motion for progress, in automated systems and in plenty of human work too.

Key takeaways

• In a tool-calling loop, the model alone decides when it is finished by returning end_turn; if the goal has no recognizable endpoint, it may never do so.
• Runaway spend concentrates in unbounded research, oversized models for simple steps, ever-growing threads and forgotten scheduled jobs.
• Raising budgets or step limits only delays the same failure; define completion explicitly in the task instead.
• Return unambiguous tool results and detect repeated identical tool calls rather than relying on step counts.
• For unattended runs, combine human checkpoints with a hard spending guardrail.