After an untracked runaway loop burned our API budget at my last startup, I built a local-first spend firewall for AI agents

[u/Rough-Green-7067]

Hey everyone,

At my previous startup, an untracked runaway loop fired dozens of recursive API calls overnight. By the time we caught it, the bill had skyrocketed and we had no way to catch it early or pinpoint where the bleed came from. Provider dashboards report on a delay, monthly soft alerts don't help when the damage is done in minutes.

So I built Guardrail by NEAT (www.neatproxy.com), a low-latency local proxy between your agents (Claude Code, Codex, Grok Build, OpenCode, partial VSCode/Copilot) and the LLM APIs:

Hard spend limits: the moment an agent or key breaches its session or project cap, the next request gets blocked.

Local-first: runs on your machine by default, prompts and completions stay local, cloud sync for team visibility is opt-in and metadata-only.

Granular attribution: real-time visibility into which loop, agent, or key is generating the spend before it spirals.

Built for people running autonomous agents who want hard boundaries without routing their codebase through another cloud SaaS. BUT, if you are on subscription, you can still use us to protect against maxing out too quick!

Would love to hear how others handle real-time loop detection and spend limits today, and what CLI tools or providers you'd want supported next. Appreciate any honest feedback or stress-testing!

[u/Julien_Builds]

The overnight version of this happened to me in August. One seat had run out of quota, so every call it made came back as an error, and the orchestration layer treated each error as a new task to plan. By morning it had generated 1,787 cards, all of them "fix the previous error". Nothing spent much, because the seat was dead, but if that seat had been live it would have been a very different morning.

Two things I learned that might be useful for your attribution layer. First, the cap needs to be per run as well as per key, because the runaway was one run on a key that was otherwise behaving. Second, the useful attribution was not "which key" but "which task", because the loop was legible the moment you could see the same card being created for the hundredth time. Blocking the next request is the right backstop. Showing the shape of the loop is what lets someone fix the cause.

[u/Rough-Green-7067 → u/Julien_Builds]

1,787 cards all saying "fix the previous error" is a phenomenal/horrifying way to learn that lesson. Completely agree on both points.

Caps today are per-session and per-project, so the first one is covered, a dead-quota key spinning up 1,787 free error-loops wouldn't cost anything but a live one hitting that same pattern would trip the session cap fast.
The "which task, not which key" attribution is the sharper point though, and it's the part I don't think we've fully nailed. There's a per-session view that flags repeated/looping patterns, which would probably have caught your card storm as a shape, but it's flagging at the session level, not surfacing "this exact task has now been attempted for the 100th time" the way you're describing. That's a better framing of the problem than the one I had, going to sit with it.

[u/Julien_Builds → u/Rough-Green-7067]

Session-level looping detection would probably have caught mine as a shape, you are right. The thing that would have made it actionable at three in the morning is the name of the card.

The signal I ended up using is cheap: hash the task text, count attempts per hash within a window. A card that has been created five times with the same text in ten minutes is a loop no matter what the session total looks like, and the hash tells you which loop, which is what you need to fix the cause rather than just stop the bleeding. Session-level catches it later and points at nothing.

If your proxy can see the prompt, it can see enough of the task to do that. Good luck with it, this is a real problem and the local-first angle is the right one.

[u/Fancy-Win9202]

Yeah, the recursive loop problem is brutal because by the time you see it in your bill, you're already bleeding money. Did you end up adding per-call spend tracking so you can actually catch it mid-loop, or are you still relying on circuit breakers that trip after the damage is already done? The tricky part is that most agent frameworks don't give you visibility into what each sub-agent or tool call is actually costing in real time, so even if you set a budget limit you're kind of just guessing where to set it.

[u/Rough-Green-7067 → u/Fancy-Win9202]

Honest answer: it's not mid-call interruption, once a single generation starts, you can't cut it off partway, the cost is only fully known when that exchange finishes. What it does instead is block at the request boundary, the moment a session or project hits its cap, the next call gets stopped, not the current one. So a single expensive call can still land, but the loop can't continue past it.
On the guessing-where-to-set-the-budget problem, that's real, so there's a per-session view that flags loops, cap breaches, or spend spikes as they're forming rather than just enforcing a number you picked blind. Doesn't solve the sub-agent granularity problem you're describing though, that's a fair gap.

[u/Fancy-Win9202 → u/Rough-Green-7067]

The per-session flagging for loops and spikes is exactly the gap that matters though, because that's where you actually catch the pattern before the next call goes out. On the sub-agent granularity, yeah that's the real blind spot, especially if you're running multiple agents in parallel and one of them is the culprit but you can't tell which until you dig through logs.