217 AI agent loops on GitHub, no budget file in any of them

Frits Zwager, Fizzl · 8 November 2026 · four studies from 2026, and the usage log of our own paid services from 1 to 7 November 2026. x402 Doctor, presign-guard, Ichimoku Signal, Fizzl Buy and the Fizzl Agent Wallet, named below, are ours

The next step after an agent that does a task is an agent that keeps doing it: a schedule or an event starts it again and again, and nobody presses a button for each run. A nightly triage job. An agent that answers every new issue. A bot that checks a price every 15 minutes. Researchers have started to count these loops, and what they find is the same every time: the loops run, and very few of them know when to stop or what they may spend.

All four studies below measure that cost in tokens. Give the loop a wallet and the same runaway is counted in payments, which no model provider refunds and no restart undoes. This page puts the numbers next to each other, adds what we see at our own paywalls, and ends with what a loop that can pay needs.

What the studies found

Loop Engineering (arXiv:2608.21884, Lulla, Nersesyan, Mohsenimofidi, Treude and Baltes, August 2026) looked for agents that run without a person starting each run. Of 36,710 repositories sampled, 36,645 could be scanned; 256 looked like loops, and 217 were confirmed. Most start on an event (195, of which 180 only on an event); 36 run on a schedule. In the files committed with those loops the authors found no budget file and no cost log with measured values. Only 55 of the 256 repositories they inspected by hand had a goal or a stop condition at all, and 13 had human oversight they could confirm. One scheduled triage workflow they looked at ran 6,290 times without ever reaching the agent step: a loop that costs a run every hour, whether there is work or not. And from the gray literature they collected: roughly eight million tokens spent in 48 hours.

Token Budgets (arXiv:2606.04056, Sajjad Khan, June 2026) collected 63 budget-overrun incidents from 21 agent frameworks. Its summary of the risk:

a single retry loop can spend thousands of dollars before an operator notices

In 11 of the 63 the cause was a race: an agent handed work to several sub-agents at once, and each of them saw the same remaining budget and spent it.

When Agents Do Not Stop (arXiv:2607.01641, Hou, Wang, Zhao and Wang, July 2026) scanned 6,549 repositories and confirmed 68 infinite-loop failures in 47 projects. The harms it lists are cost exhaustion, model denial of service, context growth, and repeated external side effects. A payment is the clearest repeated external side effect there is.

Bounded Loops (arXiv:2609.27871, Bhardwaj, Singh and Bhardwaj, 2026) went through a catalogue of 69 loops and found 47 vacuous gates: checks that look like a limit but can't actually stop anything. Its sharpest line is about where the limit sits:

the ceiling is enforced inside an attempt, not between attempts

A cap of 20 steps per run means nothing for a loop that starts a new run every 15 minutes.

What loops look like at a paywall

Our four paid services (x402 Doctor, presign-guard, Ichimoku Signal and Fizzl Buy) log every request in a usage log, with an anonymous visitor id instead of an IP address. From 1 to 7 November 2026, leaving out our own monitor and test payments:

The repeaters come in two shapes. Some run on a clock. One asked Doctor the same question every 30 minutes, 48 times a day, all week. Two others asked presign-guard the same question every 15 minutes, about 94 times a day; on 4 November both started asking twice per tick, and went to 190 a day. Had they paid per call, their cost would have doubled overnight, without anyone touching a budget. Others come in bursts, with no pause between requests: the largest sent 33,441 quote requests to Doctor's preflight in the week, the same input up to 3,356 times.

We can't tell from a request whether it came from an agent loop, a status monitor or a scanner, and many of these are surely monitors checking that our 402 is up. What matters is what they did: they asked for the price, got it, and stopped. A 402 is a natural brake. A loop without a wallet hits it and goes no further.

Now picture the same client with a wallet that pays every 402 it gets. At Doctor's list price of $0.001, the burst client above would have spent about $33 in a week. At ten cents a call, a common price for data APIs, it would have been over $3,300, for answers that mostly didn't change between calls. That is the token-budget incident from the studies, moved to the payment side: no model provider sees it, and stopping the loop doesn't bring the money back.

What a loop that can pay needs

1. A money limit in the signer, across runs. A limit in the prompt is a wish. Put it where the payment is signed: per payment, per day, per task. And count it between attempts, not only inside one: the day total has to survive a restart and a new scheduled run, or every run starts with a fresh budget. Fizzl Buy, for example, rebuilds its day budget from its own log when it restarts.
2. A stop rule that can fire. A done-when line, a maximum number of runs, and one rule that the studies keep missing: the same request with the same answer twice means stop, not try again. Only 55 of 256 loops in the Loop Engineering sample had a stop condition.
3. Gates that can fail. A check that always passes is a vacuous gate. Test that each gate can actually say no. We learned this on our own monitor: on 7 and 8 November a wrong argument made one check print "0 events" for hours, which read like a quiet night. Our monitor scripts now exit with an error when they can't see what they should, and a failed check is never a quiet run.
4. A check of the seller before paying, and of the signature before signing. A loop pays the same seller again and again, so a seller that changed its price or payout address since yesterday should stop the loop, not get paid. x402 Doctor's preflight ($0.001, or the free MCP tool x402_quick_check) checks the 402; presign-guard's quick check is free for anything a loop is about to sign.
5. Retries that can't pay twice, and sub-agents that can't race. Reuse one payment identifier (x402's payment-identifier extension) when a paid answer was lost, so the seller treats the retry as the same purchase. When a seller took the money and gave nothing, stop and tell the owner. And reserve the budget before spawning sub-agents, so they don't all spend the same remainder at once.
6. A spend log with real values. Not "budget: $5" in a config, but each payment as it happened: when, to whom, how much, the transaction. The next run reads it before it pays. None of the 217 loops committed one.
7. No paid call for an answer that didn't change. A loop that asks every 15 minutes should keep the last answer and how long it is good for, and only pay when it is stale.

A task line for a loop that can pay, the way we write it in our own agents:

Goal: refresh the BTC signal in signal/latest.json
Runs: every 4 hours, at most 6 a day
Budget: at most $0.01 per payment, $0.10 a day, counted from spend/ (not per run)
Sellers: go verdict only; same payout address as last time, else ask me
Stop when: the answer equals the previous one twice, or any payment failed
Done when: signal/latest.json is updated and the payment is in spend/

The full setup, with the limits in the wallet, approval above them and the free checks as MCP servers, is in our guide The payment lane of your agent harness.

How we counted

• The study numbers are the papers' own, as published on arXiv (Loop Engineering v2 of 26 August 2026). Some posts about Loop Engineering give other counts; we only use the figures in the paper.
• Our numbers come from the public usage log of x402 Doctor, presign-guard, Ichimoku Signal and Fizzl Buy, 1 to 7 November 2026 (UTC), with our own monitor, test agents and test payers left out (69,718 requests). A client is one anonymous visitor id; a "same request" has the same service, route and input.
• A price quote is a 402 that wasn't followed by payment on the same request. A client that asks again after a quote is not always a loop: monitors, scanners and directories check paid endpoints on purpose.
• The dollar amounts for a paying loop are a calculation at a given price, not money anyone spent.

Questions

What is an agent loop?

An AI agent that a schedule or an event starts again and again, without a person starting each run: a nightly triage job, an agent that answers every new issue, a bot that checks a price every 15 minutes. The Loop Engineering study (arXiv:2608.21884) found 217 of them in 36,645 GitHub repositories.

Why is a token budget not enough when an agent can pay?

A token budget limits what the model costs you. A loop that pays sellers spends money on every call, outside the model provider's bill, and a payment can't be refunded by stopping the loop. The limit has to sit where the payment is signed: per payment, per day, and across runs, so a restart or a new scheduled run doesn't reset it.

How do I stop an agent loop from paying twice?

Give each purchase one payment identifier (x402's payment-identifier extension) and reuse it on a retry, so the seller treats the retry as the same purchase. When a seller took the money and gave no answer, stop and tell the owner instead of paying again. When an agent hands work to sub-agents, reserve the budget before it spawns them, so they can't all spend the same remaining amount at once.

Check an endpoint with x402 Doctor, check a payment before signing with presign-guard, and give a loop a wallet with limits outside the model with the Fizzl Agent Wallet.