Your AI agent is stuck in a loop and burning API credits. Stop it now, then prove what it did.

Same tool, again and again. The agent calls one tool, or a tight cycle of two or three tools, far more times than the task could plausibly need.

Near-identical inputs. Each call differs from the last by almost nothing: the same query reworded, the same file reread, the same URL refetched, the same failing request retried with no change in approach.

No progress marker. Nothing new exists after the calls: no new file, no new result the agent actually uses, no checklist item closed, no step count moving toward done. Time passes and money leaves, but the state of the job stays frozen.

Results it ignores. A common trigger is an agent that gets a perfectly usable answer, decides it is not quite what it wanted, and asks again. Another is a tool error the agent treats as a reason to retry forever instead of a reason to stop and report.

1. Kill the process or session first. If the agent is running in a terminal, a notebook, an IDE, or a hosted session you control, stop that run now: interrupt it, close the session, or kill the process. This is the fastest stop and it works even if you do not yet know which key or account it is spending from.

2. If it runs unattended, revoke or pause the API key. A background worker, a scheduled job, or a second copy of the agent can restart the loop after you kill the copy you saw. If you cannot account for every running copy, disable the key the agent uses in your provider dashboard. Revoking a key feels drastic. It is cheaper than one more hour of looping, and you can issue a fresh key in minutes once you understand what happened.

3. Set the provider hard limit while you diagnose. In your provider billing or limits settings, set a hard monthly or project limit low enough that a restart cannot hurt you, and turn on any usage alert the provider offers. Do this even after a successful kill. It is the backstop that protects you from the copy you missed and from the next loop, which will not announce itself either.

4. Write down the time window. Note when you first suspect the loop started and when you stopped it, in your local time. You will need that window for the trail walk below and for any report you file with the provider.

1. Sort the receipts by time and find the last useful call. Read forward from the start of the run. Mark the last call that produced real progress: a new result, a completed step, a state change you wanted.

2. Find the first repeated call after it. The call right after your progress mark is usually the trigger. Look for a result the agent misread, a validation error it retried, or a condition it could never satisfy. That call is the loop boundary.

3. Count the iterations and price them. From the boundary to the kill, count the calls and group them by tool and by input. Near-identical inputs grouped together show you the loop cycles plainly, and the count multiplied by the per-call cost gives you what the loop actually spent, separated from the legitimate work before it.

4. Include the rejected calls. On Zambo, receipts issue for rejected calls too. A stretch of rejections in the trail often is the loop: the agent sending a call that fails validation, reading the failure as incomplete work, and sending it again. Without a receipt for the rejected call, that stretch would be invisible and you would guess at it.

A hard spending cap that stops the run itself. Set the provider limit and, for work through Zambo, work within the pass boundary, so that hitting the cap ends the run instead of sending you a notification while the run continues. A cap that only alerts is a news service. A cap that stops the run is a guard.

A max-iteration guard in the task brief. Write the limit into the job itself, in plain words the agent cannot reinterpret: this task may make at most this many tool calls, or repeat any single step at most this many times, and then it must stop and report what it has. Vague instructions to be efficient do not survive contact with a confused agent. A number does.

A progress check the agent must pass to continue. Require the agent to state, at set intervals, what new result it produced since the last check and what will change in the next step. If it cannot name new progress, it stops. This one guard kills most loops early, because a looping agent fails the check by definition: it has nothing new to report.

How do I tell a loop from a long legitimate job?

Look at progress, not duration. A long legitimate job keeps producing new state: different inputs, new files, new results, and a step count that moves toward a finish line you can describe. A loop repeats the same tool with near-identical inputs, returns results the agent does not use, and has no progress marker you can point to after several minutes. If you cannot say what changed in the last ten calls, treat it as a loop and stop it. You can always restart a stopped job. You cannot unspend credits.

My agent runs while I sleep. What then?

Never let an unattended agent run on hope. Before you sleep, give it a separate API key, a hard provider limit on that key or project, a max-iteration number written into the task, and a progress check it must pass to continue. Run work that goes through Zambo under its own caps as well, and check the receipt trail when you wake up before you check the bill. If any one of those guards is missing, shorten the job instead of letting it run all night.

Can a loop spend past a Day Pass?

On the Zambo side, no. Zambo-side caps stop Zambo calls when the pass or the free tier ends, and the loop cannot keep buying Zambo calls past that boundary. Your provider key is a separate rail. If the same agent also calls a model provider directly with your key, a loop can keep spending there until that provider limit stops it. That is why you cap both rails: the Zambo pass on one side and a hard provider limit on the other.

Do repeated or rejected calls leave a receipt?

On Zambo, yes. Every Zambo tool call issues a verifiable receipt carrying the task, the timestamp, and a fingerprint of the saved result, and receipts issue for rejected calls too. That matters in a loop because the repeated and rejected calls are often the shape of the loop itself. Instead of a clean trail that hides the waste, you get a record of each attempt, so you can count the iterations and find the first one.

Where do I find the exact step where the loop started?

Walk the receipts in order from the start of the run. Note the last call that produced genuinely new progress. The next call is usually the trigger: a result the agent misread, a tool error it decided to retry, or a check it could never pass. From that call onward, compare the inputs side by side. When the inputs stop changing in any meaningful way, you have found the loop boundary, and that is the step to fix in the task brief.