Agent Cost Circuit Breaker: Kill Runaway Token Spend In-Process, Before the Bill

Friday, 6 PM. A research agent ships behind caching and rate limits. By Saturday midnight it has fired roughly 8,400 API calls, re-querying the same documents with slightly different prompts and appending every tool response to a growing context. Cost per call is now forty times baseline. The ZenML production survey of 1,200 deployments documents the shape of this failure.^[1] No alert fired. No circuit tripped. The system worked exactly as designed. Monday: a $12,000 invoice.

Monitoring did not fail. Monitoring just showed up after the burn. Cloud anomaly detection aggregates on a 24–48 hour lag — another way of saying it tells you about Friday's incident on Sunday afternoon. Meanwhile, Datadog's 2026 State of AI Engineering report found that 5% of all LLM call spans report errors, and 60% of those errors are rate-limit exceeded — the provider's backstop, not yours.^[7] Your engineering team should not be relying on a vendor's rate limiter as a cost control. That control runs in the orchestration layer — in-process, per-session, measuring cumulative spend against a defined envelope and tripping before the loop compounds.

This is the circuit breaker pattern, ported. Hystrix used it for service availability: when a downstream endpoint starts failing, stop sending traffic instead of hammering a broken system. The adaptation for cost is mechanical. Replace HTTP 500 rate with session spend exceeding a profiled envelope. Everything else maps one to one.

If you already run agents in production, you have either had the billing surprise or you are queued for the first one. What follows is what catches it.

Cloud cost alerts work because cloud resources consume linearly. Ten EC2 instances cost ten times one. Agents break that assumption. Each tool call appends its result to the conversation context, so the tenth call in a session is not ten times the first — it can be twenty, because the context feeding that call is twenty times longer.^[6] A multi-agent workflow with a typical cost of $0.45 hits $87 the moment one sub-agent enters a tool loop and each retry appends a 2,000-token response to the shared context.

Datadog's 2026 engineering survey makes the scale concrete: token usage per request more than doubled for median customers year-over-year and quadrupled for 90th-percentile power users.^[7] And that's excluding the compounding effect inside runaway sessions — that figure measures normal operation. Runaway sessions sit above the P99 shoulder entirely.

The failure modes share one structural property: the termination condition never cleanly fires. The agent keeps going because nothing tells it to stop.

Infinite tool loops. The agent calls the same tool repeatedly. Each response is slightly different. The internal stopping criterion never trips. Tokens stack onto context. Cost per call climbs every iteration.

Hallucinated tool chains. The agent emits a multi-step plan with dozens of API calls. Each step looks cheap on its own. Each step anchors the next. The exit condition is the end of the plan or an error — whichever lands first.

Runaway research. The agent finds one more source. Then another. Diminishing returns is not a concept it has. Without a hard turn limit, it optimizes for completeness over cost.

System prompt bloat. Datadog found that 69% of all input tokens in customer traces were system prompts — internal instructions, policy definitions, and tool guidance executing down the chain from the initial user query.^[7] That baseline is not the problem, but it compounds the spiral: a large system prompt means every loop iteration starts from a higher token floor before the first tool response appends anything.

AWS Cost Anomaly Detection and its peers aggregate on a 24–48 hour delay. By the time the alert lands, the loop has been running for 36 hours. The control that matters runs in-process, in real time, scoped to one session.

Three states, each with one job.

CLOSED — Normal operation. Traffic flows through. The breaker silently tracks cumulative session cost. Below threshold, it stays out of the way.

OPEN — Threshold crossed. Every further agent call in this session is blocked and routed to a fallback. The session does not retry or queue. It degrades. An alert fires to oncall.

HALF-OPEN — After a configurable cooldown (5 minutes is a reasonable default), the breaker lets one probe request through with a tight sub-budget. Probe completes inside its budget, breaker resets to CLOSED. Probe spirals, breaker returns to OPEN and resets the cooldown.

The mapping is direct. Replace HTTP 500 rate with cost-per-session exceeding a defined envelope. Trip threshold takes the place of failure-rate threshold. Degraded response takes the place of a static fallback page.

One distinction is load-bearing: state must be per-session, not global. One runaway must not block 199 healthy concurrent sessions. Each workflow session owns its breaker instance and its cost accumulator. If your orchestration layer runs 200 concurrent sessions, you run 200 independent breakers — each tracking exactly one session's spend.

Several AI gateways now ship with budget enforcement built in. MLflow AI Gateway lets you define a budget policy with a USD threshold and reset period, then either alert or reject requests once the spend crosses the line.^[8] Portkey and Helicone offer similar controls at the API routing layer. These are genuinely useful. They're also not what this article is about.

Gateway-level budgets enforce spend across all sessions for a given workspace or API key. In-process breakers enforce spend within one session. The failure modes they catch are different.

What gateway budgets catch: slow accumulation across thousands of sessions each running slightly over expected cost. If 50,000 sessions each cost 20% more than profiled, no individual session trips an in-process breaker — but the fleet blows the monthly cap. A gateway budget with a REJECT action stops new requests once the aggregate threshold is hit. That's the right tool for fleet-level drift.

What in-process breakers catch: a single session spiraling to 50× expected cost within hours. A gateway budget set at $10,000/month will not stop one session from accumulating $12,000 over a weekend. The aggregate threshold doesn't trip until the damage is already done. Per-session enforcement does.

Run both. They protect against distinct failure classes.

A breaker without a cost distribution behind it is theater. The wrong threshold is as costly as no threshold: too tight, you trip on legitimate traffic and the team learns to ignore the alert; too loose, the breaker never fires until the damage is already done.

We got this wrong on the first deployment. We ran 50 test inputs, saw a P95 of $0.80, set the threshold at $2.40 (3×), shipped. What we had not profiled was end-of-month reporting queries — they naturally pull more context and run 2–3× longer than typical interactions. The breaker tripped 17 times in week one, all legitimate. The team started treating the alerts as noise. The next month, a real runaway happened, the alert fired, and oncall dismissed it alongside 14 legitimate ones. False-positive fatigue is the same outcome as no threshold, with extra steps.

The profiling process is three steps.

Step 1 — Profile representative inputs. Run the agent against 200–500 production-like inputs before deploying. Measure token counts at each step: input, output, tool call, and tokens appended to context from each tool response. Log the full per-session cost trace.

Step 2 — Compute P50, P90, P95, P99 session costs. Session cost = Σ(tokensinstep × inputprice + tokensoutstep × outputprice) across every step in the session. Plot the distribution. P50 is the happy path. P99 is the outlier shoulder. Anything above P99 is a runaway candidate.

Step 3 — Set the trip threshold at 3× P95 as the starting point. Not 10× (too loose to catch spirals early), not 1.5× (you trip on legitimate variance). 3× P95 buys enough headroom for real-world variance while still catching genuine runaways before they compound — calibrate against your workload from there.^[2]

Add a turn-count threshold alongside the cost threshold. Long turn counts usually precede cost spikes — a workflow that normally takes 8 turns and has hit 35 is almost certainly in a loop, even if cumulative cost has not crossed the dollar line yet.

One number worth knowing: agent framework adoption has doubled from 9% to 18% of production services in a single year.^[7] Most of those teams are profiling cost for the first time. If your agent is newer than 6 months, your P95 is probably underfit — run the profiling pass again with inputs collected from real production traffic, not test suites.

Place the breaker at the orchestration layer, not on individual model calls. Wrapping chat.completions.create() gives you per-call visibility and exactly nothing about the emergent session cost. The breaker has to see the running total or it cannot do its job.

The minimal state per session is three fields: cumulative cost, current state (CLOSED/OPEN/HALF-OPEN), and the timestamp the breaker last opened (for cooldown tracking). Everything else is a callback.

If your orchestration layer is TypeScript — LangGraph, Vercel AI SDK, or a custom loop — the same logic translates directly. LangGraph exposes an event stream where every model call is tagged with input/output token counts, so you can compute cost in a stream handler and check the breaker before each graph node executes.

The breaker is pure control logic. It just needs a cost number per call. The interesting question is where that number lives in your stack.

Langfuse exposes per-generation cost through generation.usage.cost, computed from token counts and model pricing automatically. Hook the Python SDK callback to feed cost into the breaker in real time, instead of polling after the fact.

OpenTelemetry spans give you the infrastructure layer. Propagate cost across services, correlate with workflow ID, user ID, and feature flag, and pipe the result into the observability stack for cross-session analysis. When a breaker trips, the span carries enough context to name the workflow, the input type, and the tool call sequence that fed the spiral.

LangGraph's event stream emits on_chat_model_end events with usage_metadata carrying input and output token counts on every model call. That's your cost hook in a TypeScript graph: multiply by the per-token price for the active model, call breaker.recordCall(), and the TypeScript implementation above handles the rest.

TrueFoundry's rate-limiting layer adds a three-tier enforcement model: per-user, per-team, and per-application token budgets enforced at the gateway before the request reaches the model.^[9] Use it as a second line alongside the in-process breaker — not a replacement.

One prompt-caching note: only 28% of LLM calls in Datadog's telemetry utilize prompt caching, despite most production models supporting it.^[7] If your system prompt is large and stable — likely, given that 69% of input tokens are system prompts — enabling caching materially reduces the baseline cost per call, which in turn lowers both your P95 and your trip threshold. Profile after enabling caching, not before.