Issue #028 Integration Strategies

Every Autonomous Run Needs a Fuse

An unbounded agent that hits a loop doesn't stop when the work is done; it stops when the bill arrives. Put a fuse on it that trips first.

Every Autonomous Run Needs a Fuse

Let's Call It Fuse Engineering

An engineer kicks off an agent on a Friday evening to do something dull and useful, scan a network and report back, and leaves it running over the weekend because that's the whole promise of the thing, that it works while you don't. In May of 2026, a version of exactly this got written up by its operator, Lan Tian, and the details are worth carrying around. An unsupervised agent, told to scan the DN42 hobbyist network, decided it needed infrastructure, provisioned five of the largest EC2 instances it could reach along with load balancers and Lambda functions, and ran up $6,531.30 in AWS charges in under twenty-four hours, for a job a five-dollar VPS would have handled without noticing. Nothing in the model malfunctioned. It reasoned its way, step by confident step, into spending six thousand dollars, because nothing in its environment was built to tell it when to stop.

The last four issues were about the model being wrong in ways that cost you: approving what it shouldn't, drifting under a pinned name, regressing without a commit. This one is about a different failure entirely, one that shows up even when the model is right. It's the model being unbounded. Agentic patterns consume tokens in a way a single chat call never did, and the numbers aren't small. Anthropic's own engineering team, writing about the multi-agent research system they built, reported that agents typically use about four times the tokens of a chat interaction, and that multi-agent systems use about fifteen times as many, and that token usage alone explained roughly 80% of the variance in how their system performed. Every turn adds context, every retry doubles down, and the cost of a run isn't a function of how hard the work is. It's a function of how long the thing runs before something makes it stop.

In most pipelines, nothing makes it stop. That's the gap this issue is about, and the fix is the oldest idea in electrical safety: you put a fuse on the circuit. A fuse is a cheap component whose entire job is to fail first, to blow and break the circuit before the current melts the wire behind the wall. An autonomous run needs the same thing, a hard ceiling on tokens, iterations, dollars, and wall-clock time that trips and kills the run before the damage lands. Let's call it Fuse Engineering: sizing and installing the thing that's supposed to blow, so it's the fuse that goes and not the budget.

COMPANION SCRIPT

Companion script for this issue: fusebox. It wraps whatever command runs your agent and holds it to three hard ceilings at once, a wall-clock timeout, a token budget, and the dollar figure those tokens imply, killing the whole process group and exiting non-zero the instant any one of them trips. It turns "the agent ran all weekend" into "the agent stopped at $20 and paged me." Hand-raiser keyword: FUSEBOX. The complete version is inline in the Quick Tip below.

The Cost Isn't Linear In The Work

The instinct that gets people into trouble is treating an agent like a function call, something that costs roughly the same each time you invoke it. A chat completion behaves that way. An agent does not, because an agent is a loop that feeds its own output back in as input, and the context it carries grows with every turn it takes. Anthropic's multipliers put numbers on the gap: four times the tokens for a single agent, fifteen times for a multi-agent system, against the same chat baseline. A task you priced in your head at the cost of one call is costing you the price of forty, and that's before anything goes wrong.

The part that makes it worse than a simple multiplier is that the growing context degrades even as it costs more. Chroma's 2025 research on what they named context rot tested eighteen frontier models and found every one of them getting worse at simple retrieval as the input got longer, with degradation setting in well before the context window was full; a model advertised at two hundred thousand tokens can start slipping around fifty thousand. The older "lost in the middle" finding from Liu and colleagues, published in the Transactions of the ACL, showed the same shape from another angle: models attend best to the start and end of a long context and worst to the middle. Put those together and you get a genuinely vicious loop. An agent that's confused stuffs more context in to compensate, the extra context costs more and works worse, the agent gets more confused, and it reaches for more context. The spend climbs while the quality falls, and both are driven by the same thing: a run that keeps going.

To make the abstraction concrete, price it. As of the middle of 2026, a frontier model runs on the order of a few dollars per million input tokens and several times that on output; Claude Opus 4.8, for instance, sits around five dollars per million in and twenty-five out. Those are trivial numbers per call and ruinous numbers per weekend, and the entire distance between "trivial" and "ruinous" is measured in how many times the loop went around. The cost lives in the runtime, and by default the runtime has no ceiling.

FOR FURTHER READING

A Loop Is A Bill With No Ceiling

The DN42 weekend is the vivid version of a mundane failure: an agent hits a step that doesn't work, tries again, fails the same way, tries again, and the loop has no floor under it and no count against it. The behavior isn't exotic or rare. The public bug trackers for the early autonomous-agent frameworks are full of dated, primary-source reports of agents getting stuck thinking the same thought in circles, and anyone who has run one of these things unattended has watched it happen. What turns a stuck loop into an incident is the absence of a number that says "stop after this many," because a model has no innate sense that the fortieth identical retry is different from the first. It's optimizing to make progress, and retrying feels like progress from the inside.

Scale the same missing-ceiling problem up from one run to a whole company and you get the story the business press spent the middle of 2026 telling. TechCrunch, reporting in June, quoted the FinOps Foundation's executive director hearing from companies that were "3x over our entire 2026 token budget and it's only April," described Uber exhausting its annual AI-coding budget by that same month, and cited a CTO whose single engineer "spent $40,000 on tokens last month." Axios reported, and others corroborated, an unnamed company spending on the order of five hundred million dollars on Claude in a single month because it had never set a per-person usage cap. That last one isn't a runaway agent loop, and I want to be precise about that; it's a thousand uncapped humans rather than one uncapped loop. But the root cause is identical to the DN42 weekend, and naming it is the whole point of this issue: consumption with no ceiling on it, whether the thing doing the consuming is a retry storm or an org chart, ends the same way.

The bill is the circuit breaker in that arrangement, and it is the most expensive possible place to discover you needed one. The engineer who has to walk into Monday's standup and explain a five-figure weekend charge for a task a VPS could have run doesn't get to say the model broke, because it didn't. What broke was that the run could spend without limit, and the only thing that finally stopped it was the money running out or someone noticing. That's not a control. That's an autopsy.

Every Autonomous Run Needs A Fuse

The fix is not cleverness, it's ceilings, installed at every layer where a run can be capped, each one a fuse sized to blow before the damage. There are more of them available than most teams use.

  • A cap on the loop itself. Every serious agent framework ships one and defaults it low on purpose. LangGraph enforces a recursion_limit, LangChain agents carry a max_iterations, and the OpenAI Agents SDK takes a max_turns and raises a MaxTurnsExceeded when the run blows past it. These exist precisely because unbounded loops are the predictable failure. Do not raise the default without a measured reason, and never remove it.

  • A cap per call. Set max_tokens on every request so a single response can't balloon, and hold the total context you're willing to carry to a deliberate budget rather than letting it grow to the model's limit, which context rot tells you is where quality goes to die anyway.

  • A cap on time. Wrap the whole run in a wall-clock timeout, so a process that wedges gets killed in minutes instead of discovered on Monday.

  • A cap on money. Set the hard spend limits the providers give you. Anthropic offers monthly spend caps that scale by tier, on the order of five hundred to a thousand dollars for smaller organizations and far higher for enterprises, plus per-key rate limits measured in requests and tokens per minute. These are the fuse on the whole account, the backstop behind every per-run fuse you set in code.

The detail that separates a real fuse from a decorative one is the same detail from issue #21: what happens when it trips. A ceiling that silently kills the run and lets a scheduler restart it from the top has built you a slower, more expensive loop, not a fuse. A tripped fuse has to halt the run and surface the fact to a human, the way issue #24's agent was required to answer insufficient_evidence instead of guessing. Stop, page, and wait. The whole value of the fuse is that a person finds out at twenty dollars, on a Saturday, by alert, instead of at six thousand, on Monday, by invoice.

Size The Fuse To The Job, Not The Fear

A fuse rated wrong is barely a fuse. Set the ceiling too high and it never trips, so the loop still runs to the bill; set it too low and it trips on legitimate work, annoys everyone, and gets disabled within a week, which is the worst outcome because now you have no fuse and a false sense that you do. The number has to come from measurement, not from a nervous guess, which is the same discipline issue #22's judgment ledger was built on: you don't get to manage what you never counted.

So measure the job before you fuse it. Run the task a few times under normal conditions and record what it actually consumes, tokens, iterations, wall-clock, and dollars, then set each ceiling at a sane multiple above the observed high-water mark, two to three times the worst normal run, high enough to clear a legitimately hard case and low enough to catch a loop long before it becomes a story. Alert at a fraction of the ceiling so a human hears about it before the fuse blows, not only when it does. Prompt caching and batch pricing will lower the baseline you're measuring against, sometimes by most of the cost, and you should use them, but a cheaper token is not a bounded run; caching changes the number the fuse is rated for, it doesn't remove the need for the fuse. The ceiling is a plain counter that can't be reasoned with, which is exactly why it works on a component whose great talent is reasoning its way past every soft limit you give it.

QUICK TIP

Wrap The Run In Three Fuses

fusebox runs your agent command in the background and holds it to three ceilings at once. Point it at a wall-clock limit, a token budget, and the price per million tokens, and it watches a usage file your agent appends its per-call token counts to, killing the whole process group and exiting non-zero the moment the time, the tokens, or the implied dollars cross the line.

#!/usr/bin/env bash
# fusebox.sh - run a command under wall-clock, token, and dollar ceilings.
# The wrapped command must append per-call token counts (one integer per line)
# to the file named in $FUSE_USAGE. When any fuse trips, the run is killed.
set -euo pipefail

MAX_SECONDS="${MAX_SECONDS:-900}"      # wall-clock fuse
MAX_TOKENS="${MAX_TOKENS:-500000}"     # token fuse
USD_PER_MTOK="${USD_PER_MTOK:-15}"     # blended price, dollars per million tokens
MAX_USD="${MAX_USD:-20}"               # dollar fuse
export FUSE_USAGE="${FUSE_USAGE:-$(mktemp)}"
: > "$FUSE_USAGE"

[ "$#" -ge 1 ] || { echo "usage: fusebox.sh <command...>"; exit 2; }

setsid "$@" &                          # own process group, so we can kill children
run_pgid=$!
start=$(date +%s)

trip() { echo "FUSEBOX: BLOWN - $1"; kill -TERM -"$run_pgid" 2>/dev/null || true; exit 1; }

while kill -0 "$run_pgid" 2>/dev/null; do
  elapsed=$(( $(date +%s) - start ))
  tokens=$(awk '{s+=$1} END{print s+0}' "$FUSE_USAGE")
  usd=$(awk -v t="$tokens" -v p="$USD_PER_MTOK" 'BEGIN{printf "%.2f", t/1000000*p}')

  [ "$elapsed" -ge "$MAX_SECONDS" ] && trip "wall-clock ${elapsed}s >= ${MAX_SECONDS}s"
  [ "$tokens"  -ge "$MAX_TOKENS"  ] && trip "tokens ${tokens} >= ${MAX_TOKENS}"
  awk -v u="$usd" -v m="$MAX_USD" 'BEGIN{exit !(u+0 >= m+0)}' && trip "spend \$$usd >= \$$MAX_USD"
  sleep 2
done

wait "$run_pgid" 2>/dev/null || true
echo "FUSEBOX: run completed within all fuses (tokens=$(awk '{s+=$1} END{print s+0}' "$FUSE_USAGE"))"

A stand-in agent that loops forever, appending its token use each turn, shows the fuse doing its job:

$ cat runaway-agent.sh
#!/usr/bin/env bash
while true; do echo 8000 >> "$FUSE_USAGE"; sleep 1; done   # 8k tokens/turn, no exit

$ MAX_TOKENS=50000 MAX_USD=1 USD_PER_MTOK=15 ./fusebox.sh ./runaway-agent.sh
FUSEBOX: BLOWN - tokens 56000 >= 50000
$ echo $?
1

The loop had no exit condition of its own, which is the whole problem in one line. The fuse gave it one. Swap the stand-in for your real agent runner, have it append the token counts your provider already returns on every call, and a weekend runaway becomes a two-minute alert.

Quick Wins

🟢 Easy (~15 min): Take one autonomous agent and give it a max_iterations (or recursion_limit, or max_turns) cap and a wall-clock timeout, today. If it doesn't have both right now, it can loop until something external notices, and something external is usually the bill.

🟡 Medium (~1 hour): Log into your model provider and set a hard monthly spend cap and per-key rate limits, then wire alerts at 50% and 80% of the cap. This is the account-level fuse behind everything else, and most teams have never opened that page.

🔴 Advanced (half day): Measure one real agent run's tokens, time, and cost, then wrap it in fusebox with ceilings set two to three times its observed high-water mark. Make a tripped fuse halt the run and page a human rather than silently restart, and add prompt caching to lower the baseline the fuse is rated against. You've converted an unbounded run into a bounded one you can actually leave alone.

Next Week

That closes a run of issues on the controls that keep an agent honest: a proposer that can't ratify, a reviewer that can't approve, a model you pin and test because it won't hold still, and now a run that can't spend past its fuse. Next Tuesday we change altitude and talk about what all of this buys you, and where it's genuinely safe to let go of the wheel.

The agent that spent six thousand dollars over a weekend wasn't broken, and it wasn't even wrong about most of what it did along the way. It was unbounded, running a loop with no count against it on a circuit with no fuse in it, and the only thing that could stop a run like that was the thing that finally did: the money and the Monday. That's the most expensive stop button ever devised.

You can't talk an agent out of hitting a loop, and you can't reason a model into knowing when the fortieth retry has stopped being progress. What you can do is put the fuse in on purpose, sized from a number you actually measured, tripping on tokens or dollars or minutes before any of them become a story, and wired to stop and page rather than silently try again. Give every autonomous run a fuse.

The fuse is supposed to be the thing that fails. Make sure it's the one you installed, and not the budget.

P.S. Automation that fails safe and cheap, rather than fast and unbounded, is the kind of work NodeBridge does for a living, and the read-only, deterministic spine of the TestScout MCP suite is the same instinct pointed at your test suite. If this issue found you running an agent with no ceiling on it, forward it to whoever owns the API bill. If someone forwarded it to you, subscribe at bashmatica.com.

NODEBRIDGE AUTOMATION SOLUTIONS

Standing up agents in your stack and want the guardrails built in from day one?

NodeBridge sets up your team's Claude Code and AI dev environment with the two-key gates, deterministic checks, and safe-automation patterns from these issues already wired in. Fixed scope, done-for-you.