Stopping a runaway agent before it finishes, not after the invoice
A per-call budget check answers one question: is this specific call, on its own, reasonable? For a single agent making sequential calls, that's usually enough. It breaks down completely the moment an orchestrated task spawns multiple subagents running concurrently — because every individual call, evaluated in isolation, can look completely fine, while the run as a whole quietly blows through any sane ceiling.
That's not a hypothetical edge case. It's the default shape of the problem once an agent framework can fan out into subagents: ten subagents each making calls that cost a few cents look, from a per-call view, like ten perfectly reasonable calls. Multiply that by a task that takes longer than expected — a tool call stuck in a retry loop, a subagent that keeps re-deriving the same context — and the run's total spend can be an order of magnitude past what anyone intended, with no single call ever having been the violation.
Why the common approaches fall short
Daily billing anomaly alerts are the default answer most teams already have running, and they genuinely catch some problems — a sudden, sustained jump in daily total spend is exactly the pattern this kind of monitoring is built to flag. The structural limitation is timing: anomaly detection runs against aggregated billing data on a schedule, typically once a day. A run that starts, spends heavily across dozens of concurrent subagent calls, and finishes within the hour can complete entirely before the next scheduled check even runs — the anomaly gets flagged after the money is already spent, not before.
Per-call budget limits alone are a real, necessary control — they stop any single call from being unreasonably expensive on its own. What they cannot do is see across calls. A limit set per call has no concept of “this is the fourteenth call in a run that's already spent $80” — each call is evaluated in isolation, passes its own check, and the aggregate overspend that only exists at the level of the whole run never trips anything. This is the concurrency gap: the problem isn't that any individual limit is set wrong, it's that no per-call mechanism has visibility into the run as a whole.
Why this needs a run-level ceiling, not a smarter per-call one
You can't catch this by making the per-call check stricter — the overspend isn't a property of any single call, it's a property of the run as a whole. It needs its own ceiling, tracked across every call in that run regardless of which subagent made it. That requires a shared, run-scoped counter that every call — no matter which subagent, no matter how many are running concurrently — reserves against atomically, so two subagents checking the budget at the same instant can't both see “room available” and both proceed past the limit.
How it actually works
Every call in a run carries the same X-Cost-Run-ID header — one identifier shared across every subagent call, however deep the workflow tree goes. Cognocient reserves the estimated cost of each call against a shared budget for that run ID using an atomic Redis operation, not a read-then-write check that two concurrent calls could race past. The first call to declare a run budget — via an explicit X-Cost-Run-Budget header, or falling back to your account's configured default — sets the ceiling for every later call in that same run, including ones from subagents that haven't made a call yet.
Once the run's total reserved spend would cross that ceiling, the call is rejected with a clear error naming the run, its ceiling, and how much it has spent so far — not a generic budget error, but one that makes clear this limit applies to the entire run across every subagent, not just the individual call that tripped it. The reservation expires automatically after 24 hours so a long-abandoned run identifier doesn't hold state forever.
What this looks like in practice
Consider a hypothetical research task that fans out into six subagents, each investigating a different part of a question in parallel. The orchestrator sets a $15 ceiling for the run on its first call via X-Cost-Run-Budget, and every subsequent call from any of the six subagents carries the same X-Cost-Run-ID. Five subagents finish quickly and cheaply. The sixth hits a page that keeps triggering follow-up tool calls, one after another, each individually a few cents — the kind of call that would sail through any per-call limit without a second look.
Because every call from every subagent reserves against the same run-scoped counter, the sixth subagent's calls are stacking on top of what the other five already spent, not starting from a fresh budget of their own. Once the combined total would cross $15, the next call is rejected — not because that individual call looked expensive, but because the run as a whole hit its ceiling. This is illustrative of how the mechanism behaves, not a specific customer's reported outcome.
The complementary problem: a loop that isn't expensive, just stuck
A run-level budget catches overspend. It won't necessarily catch an agent that's stuck — repeating the same failing tool call, or hitting the same class of error over and over — if each individual call is cheap enough to never approach the ceiling. That's a different failure mode with a different detector. See how Cognocient tells a retryable failure apart from a stuck agent — the two protections are designed to run together, not to substitute for each other.
Why this requires being in the request path
None of this is achievable by reading billing data after the fact — by the time a read-only integration could see a run's total spend, every call in it has already happened and been billed. Atomic, pre-call reservation only works from inside the request path, which is the core reason Cognocient is a proxy rather than a dashboard on top of your provider's invoice.