> ../failures/runaway_loop_april_2026.md
A user of an open-source agent framework messaged the framework author six weeks after a private acquisition. The message read: "Hey, do you know why my OpenAI bill is $4,200 for one weekend?"
The user was not careless. He was an engineer. He had read the framework docs, written a system prompt, given the agent three tools, and instructed it to "keep trying until it works." Then he closed his laptop on Friday evening and went to his sister's wedding.
The agent did exactly what he asked.
—— The trace ——
The logs were monotonous. Plan, call a tool, hit a 429 rate limit, replan, call the same tool, hit a 429, replan. The cycle ran for 63 hours, from Friday night through Sunday into Monday morning. Each replan ingested the prior attempts as "lessons learned," which inflated the context. The context inflation increased token cost per turn. Token cost per turn increased the rate of approaching the 429. The agent learned nothing because the lesson was structural, not in the prompt.
By hour 63, when the user opened his laptop and saw the invoice alert, the agent had consumed enough tokens to write the complete works of Shakespeare roughly forty-six times.
—— The four-word failure ——
"Keep trying until it works."
That is the entire failure surface. It is a load-bearing assumption with no anchor in the runtime. Four words in the system prompt assumed three things the runtime never enforced.
◆ that a human would notice if "trying" went on too long
◆ that the cost of "trying" would stay bounded
◆ that the model's definition of "working" was the same as the user's
None of those assumptions held overnight. None of them ever do.
—— What the framework should have caught, and didn't ——
This is the part of the postmortem that matters for anyone shipping agents. The user is not the lesson. The framework is.
A production-grade agent runtime must enforce, at minimum, four budgets that the system prompt cannot override.
◆ Wall-clock budget. The agent has N minutes to complete the task. After N, it halts and reports state. The default should be 30 minutes for autonomous tasks. The user can raise it. The user cannot disable it.
◆ Token budget. The agent has N tokens to consume across all turns. The runtime tracks. At 80%, the agent receives a warning in context and a soft instruction to wrap up. At 100%, the runtime halts.
◆ Attempt budget. The agent has N attempts at any given tool call. After N, the runtime escalates, either to a human, to a different tool, or to a clean failure state. Naive exponential backoff is not enough, it only delays the next failure.
◆ Cost budget. Expressed in currency, not tokens. The runtime knows the price per model and tracks. At $X, alert. At $Y, halt.
None of these four budgets existed in the framework the user was running. None of them exist by default in most agent frameworks shipping today. Token budget is the easiest to add. Cost budget is the one boards understand. Wall-clock budget is the one that saves you on Friday nights.
—— The fix in code ——
The actual fix in the framework was twenty-three lines of Python. The conceptual fix is two.
agent.budget.cost_usd = 50 agent.budget.wall_clock_minutes = 30
If those two lines had been in the user's deployment, the maximum loss would have been $50 and 30 minutes. Not $4,200 and 63 hours.
—— The deeper pattern ——
There is a category of bug that production engineers have known about for thirty years. It used to be infinite loops in cron jobs. Then it was runaway queries in databases. Then it was unbounded retries in microservices. Every generation of infrastructure relearns the same lesson, that "fail fast and bounded" is non-negotiable, and that no system prompt is a substitute for a runtime guarantee.
Agent runtimes are the current generation. We will see this exact failure mode published as a postmortem at least three more times in 2026. The names will change. The four words in the prompt will change. The structural lesson will not.
—— The kill switch you build before launch ——
We covered the kill switch pattern in detail in an earlier note. The runaway-loop failure is the textbook case for why it exists. A kill switch is not a panic button. It is the runtime enforcing what the system prompt cannot. The four budgets above are the kill switch in its boring, default-on, "you will never thank me for this until the day you do" form.
—— What to do today ——
If your agent is in production right now, run this checklist before end of week.
◆ Find the wall-clock budget. If there is no wall-clock budget, that is the highest-leverage fix.
◆ Find the cost budget. If your runtime cannot tell you the current cost of an in-progress task, instrument it before next deploy.
◆ Find the attempt budget. Naive exponential backoff with no cap is not a retry policy, it is a slow infinite loop.
◆ Find the kill switch. If your team cannot stop a running agent in under 30 seconds at 3 AM without a deploy, you do not have a kill switch.
—— End of failure report ——
◆ Four budgets: wall-clock, token, attempt, cost.
◆ The runtime enforces them. The prompt does not.
"Keep trying until it works" is a runtime instruction, not a prompt one.
— ORBIRESEARCH