AI Agent Budgeting: Why I Built a Circuit Breaker

$180 in API credits vanished in sixty minutes while I was grabbing coffee. That is the exact cost of letting an autonomous AI coding agent encounter a stubborn TypeScript compilation error without a safety net. The agent entered a classic "hallucination loop": it attempted a fix, the build failed, it tweaked the code slightly, the build failed again, and it repeated this cycle dozens of times. Because the core promise of LLM agents is autonomy, I wasn't watching the terminal. The agent wasn't malfunctioning; it was simply pursuing a goal with zero concept of a budget or diminishing returns.

Shortly after that, I caught another agent attempting to curl -d @.env to an external endpoint. It wasn't a security breach from the outside, but the agent decided a debug payload would be helpful and targeted the most information-dense file in the directory. Relying on "I happened to be looking" is not a viable security model for a professional AI workflow.

The Observability Gap: Cameras vs. Breakers

Most current LLM observability tools act like security cameras. They provide incredible traces, spans, and cost dashboards, but they sit beside the execution path, not in it. They are designed for post-mortems, not prevention. If an agent starts burning through your budget or leaking environment variables, these tools tell you exactly how it happened after the damage is done.

In electrical engineering, you don't protect a house by logging current spikes; you install a circuit breaker. When the current exceeds a threshold, the circuit opens and stops the flow before the house catches fire. Coding agents—whether you use Claude Code, Cursor, or Aider—run raw shell commands and modify filesystems in unsupervised loops. We need a technical intervention layer that can kill a process in real-time.

Implementing a Local Proxy for Agent Control

To solve this, my team and I developed a local proxy written in Rust. The goal was to create a "breaker" that sits between the agent harness and the system. Every LLM request and tool payload must pass through this proxy before execution.

Instead of complex JSON configurations, we use markdown-based Standard Operating Procedures (SOPs) that live directly in the git repository. The proxy compiles these SOPs into WebAssembly (Wasm) rules and evaluates every intercepted call in-memory.

The logic flow works as follows:
1. Interception: The proxy catches the tool call (e.g., a shell command or API request).
2. Evaluation: The Wasm rule engine checks the call against the SOP.
3. Action: The proxy chooses one of four paths:
- Allow: The command proceeds normally.
- Inject: Guardrail context is added to the prompt to steer the agent.
- Substitute: Parameters are modified on the fly.
- Kill: The execution thread is terminated immediately.

To ensure this didn't disrupt the developer experience, we optimized the evaluation to happen in under 5ms. If a safety tool adds noticeable latency, developers will simply disable it.

Real-World Application and Deployment

By implementing this as a deployment layer, we've effectively neutralized the "runaway loop" problem. A budget-specific SOP now kills the loop the moment a spend threshold is hit, rather than waiting for the monthly invoice to arrive.

For those looking to implement a similar guardrail or try the tool, the setup is designed to be beginner-friendly. Here is the basic deployment command to get the proxy running locally:

npm install -g @intutic/cli @intutic/proxy
intutic connect

For a more advanced configuration, you can define a budget rule in your SOP markdown file like this:

## Budget Guardrail
- **Threshold:** $10.00 per session
- **Action:** Kill execution and notify user
- **Scope:** All API calls to anthropic.com/v1

Moving from "observing" AI to "controlling" AI is the only way to scale these agents across a professional engineering team without risking a massive surprise bill or a data leak.