A Time Fuse and an Iteration Fuse Are Not the Same Thing

Mostafa Dhouib·September 4, 2026·7 min read

A Time Fuse and an Iteration Fuse Are Not the Same Thing

The short answer. An iteration cap is incremented by the loop, so a loop that is hung does zero iterations and the counter does zero decrements. It freezes, permanently, and can never fire. Only a clock catches a hang, which is why every embedded watchdog counts time rather than iterations and runs on separate silicon. Meanwhile a spin, where iterations happen but nothing moves, is caught only by the iteration side. They are opposite edges of one instrument, and most systems have shipped two copies of the same half.

Most teams that have thought about runaway agents have shipped two protections: a maximum iteration count and a maximum duration. Both are set, both are reasonable, and the system feels covered.

Then it hangs for eleven days.

The reason is that those two controls are not redundant, and they are not interchangeable. They catch opposite failures, and if you have configured them as though they were two versions of the same idea, one of the two failures is completely unguarded.

The hang: why the counter cannot fire

Put three signals on one time axis, the way you would on a scope.

The top trace is tool calls, toggling healthily, issue and return, issue and return. Then it goes high and stays high. A call went out and never came back.

The middle trace is your iteration counter, stepping down, seven, six, five, and then flat. Frozen.

The bottom trace is the wall clock, still ramping, indifferent.

Here is the mechanism. The loop performs zero more iterations. Zero iterations means zero decrements. The counter is frozen at its current value, not slowly, not eventually, but for as long as the hang lasts, which may be forever.

So the iteration cap cannot fire. Not "fires late". Cannot fire, ever, in this failure.

There is a precondition in the underlying termination argument that is almost never written down: from any non-terminal state, a step must be enabled. "The measure decreases every iteration" is trivially true when there are no more iterations. Your proof remains perfectly valid and your loop hangs forever, and both statements are true simultaneously. That is not a contradiction, it is a hole in what the proof ever promised.

The general form is worth keeping, because it recurs: the thing you are relying on to catch the failure is the thing the failure disables. A counter driven by the loop cannot detect a dead loop.

Which is why watchdogs count time, on their own silicon

This is not new engineering. It was settled in embedded systems decades ago.

Every hardware watchdog counts time, not iterations, and runs on a separate oscillator with separate silicon. It fires whether or not your code is alive, because time is the one quantity that keeps advancing while the loop is dead.

That is not belt-and-braces paranoia. It is the only design that survives the exact failure it exists to catch. Any watchdog driven by the thing it is watching shares the fate of the thing it is watching.

The direct translation: your agent's time fuse must be enforced by something outside the agent's own execution. A timeout checked at the top of the loop is not a timeout, for the same reason. It is a check that the loop performs, and the loop is not running.

The spin: why the clock is not enough either

Now the opposite failure, which is the reason you cannot simply replace the counter with a clock.

A spin is a loop that iterates enthusiastically and accomplishes nothing. Calls complete, steps run, the trace is busy, and no work moves forward. A wall-clock deadline eventually stops it, but only after it has burned the entire budget doing nothing, and only at the deadline rather than at the point the futility became evident.

The iteration count is what catches this, because iterations are happening and they are the thing that is excessive.

The windowed watchdog

Embedded systems have a name for the instrument that catches both, and it is the cleanest framing I know for this.

A windowed watchdog must be kicked inside a window, between a minimum and a maximum time. Kick it too late and you have a hang, which everybody expects. Kick it too early and that is also a fault, which is the part people find surprising.

Think about why. If you are completing cycles faster than the real world could possibly finish the work, you are not doing the work. You are spinning. Early kicks are evidence of futility, and the windowed watchdog treats them as a fault because they are one.

Too slow means hang. Too fast means spin. One instrument, two edges.

And you have already shipped both halves. Your iteration cap catches the left edge, the spin. Your wall-clock timeout catches the right edge, the hang. What nobody told you is that they are opposite ends of the same instrument, which has three consequences.

Tune them separately, against different failures. A max-iteration value chosen to bound cost is not a value chosen to detect futility. Ask what number of iterations, in this task, would mean the work is not progressing, and set it to that.

Do not congratulate yourself for having two limits. Two caps on the same edge is one protection. Check which edge each of yours actually guards, and if the timeout is enforced inside the loop, it guards neither.

Neither of them is looking at your task. This is the limit worth being honest about. Both fuses are backstops. They bound the damage of a failure; they do not detect that the work is done. That still requires a number that describes the task, and a fuse is a seat belt rather than a steering wheel.

What to check in your own system

Four questions, and they take a few minutes.

Is your wall-clock deadline enforced by something outside the agent's execution, or checked at the top of the loop? If the latter, you have no hang protection.

If a tool call hangs forever right now, name the specific limit that fires. If the answer is the iteration cap, the answer is wrong.

Do you have a spin detector distinct from your cost cap, and would it fire before the budget was exhausted rather than at exhaustion?

Do the two limits report distinguishable outcomes?

And if you want the cost of getting this wrong, the agent reliability calculator computes what a tree of individually capped runs can spend. A run stopped by the hang fuse and a run stopped by the spin fuse are different diagnoses, and if they return the same thing to the caller you have thrown away the finding.

FAQ

Does a max iteration limit stop a hung AI agent? No, and it cannot. The counter is decremented by the loop, so a hung loop performs zero iterations and zero decrements. The counter freezes at its current value and can never reach zero. Only a clock, enforced outside the agent's own execution, catches a hang.

Why do embedded watchdogs count time instead of iterations? Because time is the only quantity that keeps advancing while the loop is dead. A counter driven by the thing it is watching shares that thing's fate. This is also why hardware watchdogs run on a separate oscillator and separate silicon, so they fire whether or not the code is alive.

What is a windowed watchdog? A watchdog that must be kicked inside a window, between a minimum and a maximum time. Too late is a hang, and too early is also a fault, because completing cycles faster than the work could possibly finish is evidence that no work is being done. Two edges, one instrument.

What is the difference between a hang and a spin? A hang is a call that never returns, so iterations stop and the clock keeps running. A spin is a loop that iterates busily while nothing moves forward, so iterations run away and the clock is normal. They are opposite failures caught by opposite instruments.

Is a timeout plus a max-iteration cap enough to bound an agent? Only if the timeout is enforced outside the loop, and only for a single run. Neither instrument looks at your task, so both are backstops rather than stopping rules, and neither bounds a system of loops where capped runs call other capped runs.