Open-Source Circuit Breaker: Putting a Cost and Infinite-Loop Leash on LLM Agents

When Agents Get Stuck in Loops, the Bill Quietly Inflates

When building autonomous AI agents, the most frustrating thing often isn't the model's capability boundary, but those moments of losing control: an uncaught exception triggers a retry, repeatedly calling the API with a massive context window, and by the time you receive a billing alert from OpenAI or Anthropic, the damage is already done. The lag in cloud billing alerts has developers urgently needing a local, real-time "fuse" that can intercept failures.

A developer in the Reddit community, based on this pain point, built a zero-dependency local circuit breaker in Python and TypeScript. Its core logic is simple and direct—hard-stop before the agent's behavior goes out of bounds, rather than remediating after the fact.

Three Layers of Protection: Budget, Loops, and Real-Time Cost

This circuit breaker provides three key mechanisms, covering the main paths to cost overrun:

1. Session-level dollar budget hard cap Developers can set a maximum spend per session (e.g., $1), and once cumulative consumption hits the threshold, the circuit breaker immediately halts all subsequent calls. This is equivalent to installing a "prepaid electricity meter" on the agent—when the balance runs out, power is automatically cut.

2. Infinite loop detector For situations where the agent repeatedly executes the same tool call or gets stuck in a loop logic, the circuit breaker identifies repeat patterns by comparing action signature hashes. Below is the core loop detection logic in its pure Python implementation:

import hashlib

class CircuitBreaker:
    def __init__(self, max_repeats=3):
        self.max_repeats = max_repeats
        self.hashes = []

    def check(self, action_signature: str):
        h = hashlib.sha256(action_signature.encode()).hexdigest()
        self.hashes.append(h)
        recent = self.hashes[-self.max_repeats:]
        if len(recent) >= self.max_repeats and len(set(recent)) == 1:
            raise RuntimeError(f"Infinite loop detected! Tripped circuit on: {action_signature}")

This code maintains a list of hashes of action signatures, and triggers an exception when the most recent N actions are completely identical. Although simple, it effectively intercepts the most typical repetitive call scenarios.

3. Cross-model real-time cost calculation The circuit breaker has built-in token pricing for mainstream models such as OpenAI, Claude, and Gemini, and can accumulate costs in real time based on the number of input and output tokens for each call. This means budget control no longer relies on cloud providers' after-the-fact bills, but occurs at the moment the call happens.

Circuit Breaker is a fault-tolerance pattern in distributed systems, first systematically described by Michael Nygard in Release It!. Its core idea is: when a dependent service fails continuously up to a threshold, the circuit breaker immediately "trips," and subsequent requests quickly fail rather than continuing to wait for timeouts or retries, thereby preventing cascading failures and resource exhaustion. A typical implementation has three states—closed (normal pass-through), open (direct rejection), and half-open (tentatively allowing a small number of requests to probe for recovery). This article transfers it from the domain of "service availability" to "financial safety": the trigger condition is no longer error rate, but dollar consumption or action repetition patterns. This analogy works because both share the same control logic—actively interrupting the call chain before losses expand.

LLM token billing mechanisms are the prerequisite for understanding real-time cost calculation. Mainstream large model APIs price input tokens and output tokens separately, with unit prices usually expressed in dollars per million tokens, and output token prices generally higher than input. Prices vary significantly across models and context length tiers, and some models charge a premium for long contexts. Therefore, the cost of a single agent call depends on: the chosen model, input context length (including system prompts, conversation history, tool return results), and generation length. In agent scenarios, context accumulates and inflates with each turn, causing non-linear cost growth—this is precisely why session-level hard caps are needed rather than relying solely on per-call limits. Only with a built-in pricing table can the circuit breaker immediately accumulate costs after each call returns the usage field, rather than waiting for cloud bills.

Free Calculator and Paid Full Package

In addition to the core circuit breaker logic, the author also provides a free web-based cost calculator that supports comparing token costs across 13+ current mainstream models. For developers who want to quickly estimate the cost of different model combinations, this is an intuitive auxiliary tool.

The complete production-grade package (including pre-configured token pricing for 15+ models, dollar cap settings, and a TypeScript version) is sold for $19 on the Polar platform. This "open-source core logic + paid production tools" model is not uncommon in the developer tools space; it lowers the barrier to trying while providing motivation for ongoing maintenance.

Why Local Circuit Breaking Is More Critical Than Cloud Alerts

Cloud providers' billing alerts typically have hour-level delays, and for high-frequency agent scenarios, several hours are enough to generate considerable costs. The value of a local circuit breaker lies in moving the control point forward: completing budget checks and loop judgments before each API call is sent, rather than waiting for after-the-fact notifications.

This approach is in line with traditional software fault-tolerance patterns—circuit breakers are used in distributed systems to prevent cascading failures, and now they are being ported to the financial safety domain of LLM agents. For any team running autonomous agents in production, such a local protection layer should be standard, not optional.

The author invites community feedback on the calculator and circuit breaker logic in the post, and this open attitude also means the tool is still in early iteration. For developers who want to implement it themselves, the loop detection code above already provides a sufficient starting point; for teams that need to deploy quickly, the paid package saves the time cost of adapting to multi-model pricing.

Implementation Recommendations and Limitations

In actual integration, the circuit breaker needs to be embedded in the agent's call chain to ensure that every tool call and model request is checked. For developers using frameworks such as LangChain or AutoGPT, the circuit breaker logic can be inserted at the wrapper layer of the tool executor.

It should be noted that hash-based loop detection can only catch completely repeated action signatures. If the agent slightly adjusts parameters within a loop (for example, passing slightly different inputs each time), simple hash comparison may fail. More complex semantic-level loop detection requires additional design. In addition, real-time cost calculation depends on accurate token counting, and tokenizer differences across models need to be properly handled.

Nevertheless, this project hits a real pain point in the deployment of LLM agents. While agent capabilities rapidly improve, supporting tools for cost control and safety guardrails also need to keep up. A local circuit breaker may not be the ultimate solution, but it points in the right direction: making costs visible, controllable, and interruptible.

Action signature refers to a string obtained by deterministically encoding a specific agent behavior, usually constructed by concatenating the tool name with structured parameters (such as sorted JSON). The effectiveness of hash comparison depends entirely on the granularity of the signature construction: if the signature includes timestamps, random IDs, or parameters that differ slightly each time, then loops with the same semantics will produce different hashes and detection will fail. Conversely, if the signature is too coarse (only the tool name), normal multiple calls of the same type may be misjudged as loops. In practice, parameters need to be tuned between "noise resistance" and "sensitivity," and secondary judgments can be made using sliding windows, action frequency statistics, or semantic similarity. The example in this article uses SHA-256 to hash the complete signature, which is the simplest form and suitable for intercepting infinite loops with completely identical parameters.