How to — stop an agent before it burns your budget

An agent that runs unattended fails in a way a chat window never does: it fails expensively. The job here is to make the worst case of any run a number you know before you press go — and to have the run stop itself the moment it stops making progress.

Most teams discover this the hard way. A task that should take twelve steps takes four hundred, half of them re-asking the same question in slightly different words, and the invoice arrives two days after the incident. You are not going to out-argue the loop once it is running. You cap it in advance and you watch it while it goes.

1. Put a number on the worst case before you start

Three caps, set before the run, not after: maximum steps, maximum wall-clock time, maximum spend. The cap has to live in the harness — the thing that calls the model — because that is the only component the agent cannot edit mid-trajectory.

Do the arithmetic once, plainly. Take the cost of a typical step (input plus output, plus any tool call that hits a paid API), multiply by your step cap, and that is your worst case. If you cannot state that number out loud, you do not have a cap; you have a hope. Anthropic's own engineering guidance describes agents as "just LLMs using tools based on environmental feedback in a loop," and recommends stopping conditions such as a maximum number of iterations to maintain control. That advice sounds obvious and is skipped constantly, because the demo worked.

The three caps fail independently: steps bound the loop, wall clock stops one slow tool holding a worker hostage all afternoon, spend covers the case where your step estimate was off by an order of magnitude.

2. Make the cost of each step visible while it runs

You cannot stop what you cannot see. For every step, record the tokens in and out, which tools were called, and how long it took — tagged with the run, so you can line steps up in order afterwards.

Then watch the shape, not the total. A run where step twenty-eight costs five times the average is telling you something is wrong right now: the context has grown, or a large tool response is being fed back into itself. That signal arrives minutes before the invoice does, and most people miss it because they only check the monthly spend dashboard. If your platform shows nothing but a chat transcript, that is your first fix — a transcript is the agent's version of events, and you want the tool calls underneath it.

3. Learn the three loop shapes

Almost every runaway is one of three patterns, and each has a signature you can recognise in the log without reading the content.

The cosmetic retry. Same tool, same arguments, slightly reworded query — the search that returns nothing useful, asked eleven ways. The verify-fix-reverify spiral. The agent checks its work, finds a problem, fixes it, checks again, finds a new problem, and never converges because each fix creates the next defect. The silent stall. A tool keeps failing and the agent keeps retrying it with identical arguments, waiting for a different result.

All three share one property: no new information is entering the run. Progress in an agent is new evidence in the context — a page it had not seen, a test that now passes, an error message that changed. When ten consecutive steps add nothing, the trajectory is dead; a step counter cannot see that, the log can.

This is also why the problem grows rather than shrinks. METR measures the length of software task an agent completes half the time, and found that horizon doubling roughly every seven months. Longer-horizon agents are the product everyone is shipping, and longer runs mean more steps in which a loop can get expensive before anyone notices.

4. Cut the loop in the harness, not with a stern prompt

The instinct is to send a message: be more efficient, stop repeating yourself, wrap it up. It rarely works, and the reason is mechanical. By the time the loop is visible, the failures are already in the context, so the agent is reasoning over its own bad trajectory; telling it to do better adds one more thing to reason about instead of removing the mess.

What works is a hard stop and a clean restart. Kill the run, keep the transcript, restart the job narrower — one document instead of ten, one file instead of a repository. A run stuck at step eighty almost always started too broad. Splitting the task is not a workaround for the agent's weakness; it is how any long task stays tractable.

Give the agent permission to stop, too. A stop rule — "after three failed attempts at the same thing, report what you have and what blocked you" — turns a runaway into a partial result you can act on. Without it, the agent's only available behaviour when stuck is to keep trying, because nothing in its instructions says giving up is allowed. OpenAI's agent tooling calls this pattern a tripwire: a check that halts execution the moment a condition trips, rather than a warning the model is free to ignore.

5. Bound the tools, not just the agent

A step cap gets defeated by a single step that does unbounded work. Look at every tool you have handed over and ask what the largest possible response is. Search that can return a thousand results. Pagination with no ceiling. A file listing over a directory tree with no depth limit. A tool that can call the agent again.

Cap each one at the tool boundary: results returned, pages followed, records fetched. An agent that can ask for more will ask for more, and that response lands in the next step's context — which you then pay for on every remaining step of the run. Bounding a tool once is cheaper than bounding the loop it creates.

Permissions and budget are separate jobs, and mixing them up is a common gap: deciding what an agent may do is not the same as deciding how much it may spend doing it. An agent can stay entirely inside its permissions and still cost a fortune.

6. Price the run afterwards and keep the receipt

When a run finishes, compare the steps it took with the steps the task actually needed. That ratio is the most useful number you will get all week: a two-line answer that took forty steps is either a task you described badly or a tool that returns too much, and you cannot tell which without the log. Set the next run's caps from that observed median rather than a guess, and re-check whenever you change the model, the tools, or the prompt — a cheaper model that needs three times the steps is not cheaper.

Finally, keep the raw record. Your audit trail is the only thing that survives an argument about what the agent did, and the agent's summary of its own work is not evidence — as we argued in an agent grading its own homework, the summary is the claim, the log is the proof.

Don't do this

Don't make a monthly budget your only guard. It is the right backstop and the wrong control: a single looping run can consume a month's allowance in an hour, and monthly dashboards tell you about it after the fact. The cap that saves you is the one attached to the individual run — steps, clock, and spend — because that is the only place the loop can be stopped while stopping is still cheap.

How you'll know it worked

You can state the worst-case cost of any run before you start it. You have watched at least one run hit its ceiling and stop cleanly, with a partial result and a note about what blocked it, instead of a bill. And repeating the same task twice costs roughly the same both times, rather than three times as much on a Tuesday because the agent decided to be thorough.

Have you had an agent run away with your budget — and what finally stopped it? Write to us via our contact page.