The $47,000 Agent Loop: Why AI Agents Keep Burning Through API Budgets Overnight

The most common shape behind a large, sudden agent cost overrun is two cooperating agents stuck asking each other for more work with no fixed, measurable stopping condition. In the LangChain A2A case, the Verifier's job was to check the Analyzer's output against quality criteria and either approve it or request one focused clarification. Instead, it kept asking for open-ended further analysis, and the Analyzer kept generating more content in response. Every LLM-based Verifier has a structural tendency toward this failure: asking a model whether output is complete, without a rigid grading rubric and a calibrated threshold, tends to produce an answer that suggests at least one more angle worth considering, because the model is trained to be helpful. That helpful instinct is the loop's fuel. There was no fixed criterion, such as three consecutive approvals or a hard iteration cap, that would have stopped the exchange once it was met, so the two agents traded API calls for eleven days straight. Any pipeline where one agent's output feeds into another agent's judgment of that output, without a non-LLM-judged, decidable definition of done, has this same failure mode latent in it.

A second, closely related pattern shows up in coordinator architectures where one agent dispatches sub-agents to do work, and those sub-agents can themselves dispatch further sub-agents. A April 2026 post-mortem filed against a production multi-agent Claude Code deployment documented a coordinator agent that got stuck in a recursive hook chain with no timeout and no depth limit, hanging past its wall-clock budget before eventually self-terminating without completing any work. The same catalog documented a background task-creation pattern with no rate limit and no deduplication check: a long-running coordinator's task list grew past thirty entries with no soft cap warning and no check for near-duplicate work being spun up repeatedly. Neither failure mode requires malicious input or a buggy prompt. Both come from the runtime treating recursion depth and task-creation volume as unbounded by default, so a coordinator that keeps deciding "this needs another sub-agent" has nothing structurally stopping it from doing that indefinitely, and every dispatch is a fresh set of API calls.

A less obvious driver of runaway spend is degradation that increases the number of calls a pipeline makes without ever throwing a visible error. A widely cited postmortem on Claude Code quality issues traced six weeks of complaints to three overlapping changes, one of which was a caching optimization intended to clear old reasoning content from idle sessions after an hour of inactivity. The clearing logic malfunctioned and fired on every turn instead of once, progressively erasing session history and forcing full cache misses on sessions that had accumulated large context windows, which meant every subsequent call reprocessed far more tokens than it should have. Separately, automated pipelines were observed silently delegating tasks to a cheaper, faster model more often than expected, a substitution that is only visible in verbose logging and that one practitioner described as invisible until it surfaces three tasks downstream. Neither of these failure modes looks like a bug from the outside. Both show up only as a gradual, then sudden, increase in total API spend with no corresponding error rate to explain it, which is exactly the kind of drift a simple pass/fail monitoring check will not catch.

Start with the provider's own usage dashboard broken down by time window rather than by monthly total, since a monthly aggregate is the single slowest signal available and is exactly what took eleven days to fire in the LangChain case. Look for a token or request-count curve that is flat-to-linear over a sustained multi-hour window rather than the bursty, tapering pattern of normal task completion; a loop produces a nearly constant rate of consumption because it never reaches a stopping condition. In application logs, grep for repeated pairs of agent identifiers exchanging messages with near-identical or templated content, for a task or session ID that has been active far longer than any comparable completed task, and for the same tool call or delegation pattern recurring without a corresponding change in output. If your framework logs an iteration or round counter, a distribution with a long tail, most tasks finishing in single digits and one running into the hundreds, is the fastest confirmation. Also check for cache-hit rate as its own metric, separate from raw spend: a sudden, sustained drop in cache hits on long-running sessions can mean the pipeline is silently reprocessing full context on every call, which inflates cost without any explicit error appearing anywhere in the log.

If diagnostics confirm an active runaway, stop the specific process, session, or task chain immediately rather than waiting to understand exactly why it started. Every minute spent root-causing while the loop keeps running is more spend accruing at the same rate that got you here. Use whatever hard-stop mechanism the platform actually provides, killing the process, revoking or rotating the API key scoped to that workload, or disabling the specific agent pair or task chain identified in diagnostics, rather than a soft signal like sending a stop instruction into the same conversation the runaway agents are having, which assumes the agents will notice and comply. Once the bleeding is stopped, preserve the logs and billing records for that window before any cleanup, since the sequence of calls is the only reliable evidence for figuring out which of the causes above actually applied and whether the fix needs to address a missing termination predicate, an unbounded delegation depth, or a silent degradation in caching or model routing.

The single clearest lesson from the LangChain post-mortem is that observability and enforcement are independent properties, and a system can have excellent observability while being completely unsafe. A dashboard that shows a spend rate accurately is not a defense against that spend rate; it only becomes one if something reads that signal and takes an action before the next API call is allowed to fire. Concretely, this means the runtime, not a human watching a chart, needs to hold a per-agent and a per-pipeline budget cap that is checked before each call is dispatched, refusing the call outright once the cap is reached rather than logging that the cap was exceeded after the fact. It also means a hard maximum on iteration count or recursion depth between cooperating agents, and a wall-clock timeout on any task chain, cheap to build and, per the same post-mortem, sufficient on its own to have prevented the large majority of this specific loss. None of this replaces the architectural work of designing pre-execution budget enforcement properly; it is the minimum viable version of that control applied to a system that does not have it yet.

Once a hard enforcement layer exists, cost anomaly alerting is still worth having, but it needs to run on a window measured in minutes, not the monthly or even daily aggregate most billing dashboards default to. Configure an alert on rate of spend over a rolling short window, for example dollars per fifteen minutes compared against that workload's historical baseline, rather than an absolute monthly ceiling, since an absolute ceiling only fires after the damage that ceiling represents has already happened. Route that alert to something that pages a human or triggers an automated pause, not to an email digest that gets read the next business day. Treat this layer as the backstop that catches whatever the enforcement caps did not anticipate, a legitimate but unusually expensive task, a new agent pattern nobody added a cap for yet, rather than as the primary mechanism for stopping a loop, since alerting by definition happens after spend has already occurred.

After deploying a fix, do not consider it validated because the same test scenario now generates an alert faster than before. Reproduce the loop condition deliberately in a sandboxed environment, an Analyzer and Verifier pair that never converges, a coordinator that keeps deciding to spawn another sub-agent, and confirm that the pipeline is actually refused further calls once the cap is hit, with a logged rejection at the point of attempted dispatch rather than a downstream cleanup. Separately verify the cap applies at the layer you think it applies at: a per-session budget check that only runs inside the top-level orchestrator will not catch a sub-agent that has its own API credentials and calls the provider directly, which is a common gap in coordinator architectures that grew organically. Finally, confirm the fix did not just move the bottleneck, for example a hard iteration cap on the Analyzer/Verifier pair that now reliably terminates but always terminates at the cap without ever reaching genuine completion, which caps cost but silently produces no usable output every time, trading a cost problem for a quality problem that will not show up in a billing dashboard at all.

The most common incomplete fix is an alert that is louder or faster but still has no enforcement behind it: shortening the alerting window from monthly to daily is a real improvement over the LangChain case's failure mode, but a loop that burns budget for six hours before a daily digest fires is still a five- or six-figure incident depending on the workload's per-call cost, just a smaller one. A second failure case is a cap that is set high enough to avoid interrupting legitimate long-running work, which in practice often means it is set high enough to still allow a slow-burn loop to run for hours before tripping; a cap needs to be validated against your own workload's actual normal-completion cost distribution, not set to a round number that feels generically safe. A third is enforcement that only covers the primary orchestration path and misses sub-agents or delegated tasks that hold their own credentials, which is exactly the gap that let a coordinator's recursive hook chain run unchecked in the multi-agent coordination post-mortem referenced above. A fourth, subtler failure case is a fix that caps cost successfully but does so by silently discarding or truncating work rather than surfacing that the cap was hit, which means the team stops losing money but starts shipping incomplete results without knowing it.

Treat a runaway loop as a straightforward engineering incident, owned by whoever built the pipeline, when the root cause is internal: a missing termination predicate, an unbounded delegation pattern, a caching bug in your own orchestration code. Escalate to your security team and treat it as a security incident, not only a cost incident, when the loop involved credentials or data leaving the environment in a way nobody authorized, when the pattern suggests the agent was manipulated into the loop by adversarial input rather than a design gap, or when the spend pattern coincides with any other sign of compromise, since a cost anomaly is one of the more reliable side-channel indicators that something is exfiltrating data or abusing a credential at scale. Escalate to the model or platform provider when the mechanism itself lives in their infrastructure rather than yours, a caching bug in the provider's session handling, an undocumented model-routing substitution, or a documented framework-level gap like the absence of default iteration caps in agent orchestration libraries, since no fix on your side addresses a defect in the provider's own request-handling layer, and a vendor-side confirmation is also what you need before relying on any fix that depends on their infrastructure behaving correctly going forward.