Where the spend actually comes from
The agent node takes a goal, a model and a list of tools, then loops through think, call and observe until it is done or a limit is hit. Nothing about that loop is unbounded by design, but three ordinary things push a run past what anyone intended.
- A retry loop: a tool call fails — a timeout, a rate limit, a malformed argument — and the agent tries again. Each attempt is a fresh model call with its own tokens, and a model that is bad at knowing when to give up will keep trying long after a human would have stopped.
- A tool that returns a huge document: a policy lookup, a full ticket thread, a page of search results. Whatever a tool hands back goes into context for the next iteration, so one oversized result inflates every turn that follows it, not just the one that fetched it.
- A prompt that grows every turn: the agent keeps its own history so it can reason about what it already tried. That is also why turn ten costs more than turn one even when nothing else about the task has changed.
None of these need a bug. A retry policy that is reasonable for an HTTP node is reckless for a model call that costs money on every attempt. A tool that faithfully returns everything it found is doing its job. The loop is working as designed; the design just did not have a ceiling.
What a budget should be scoped to
On OCNORA, AI spend is tracked in tokens and in USD, per tenant and per provider, and the router checks it before every model call and reconciles it after the call returns — not from a bill at the end of the month. That scoping is deliberate, not incidental, and it matters for two separate reasons.
Per tenant, because on any multi-tenant platform one workspace having a bad day should not spend another workspace’s money. A cap set on the whole account cannot tell you that; a cap set per tenant contains the blast radius to the tenant that caused it.
Per provider, because a workflow that fails over from one model vendor to another during an outage should not be able to spend twice. And tracking both tokens and USD catches different failures: a token cap catches a loop that will not stop even on a cheap model, a USD cap catches the same loop after someone switches it to an expensive one.
Watching spend before the cap has to speak for itself
Every model call is written to a cost ledger with its workflow, run, node, model, tokens and USD, and spend is reported against budget alongside the workflows responsible for it. The AI page lists what each entry records. The trace viewer and the ledger are the same data, so a spike you see in one is not a separate mystery from the other.
Insights adds AI spend over time alongside runs, failures and duration, so a workflow that is drifting upward is visible as a trend before it is the reason a tenant’s budget runs out mid-month. None of that is a substitute for the cap itself — it is checked before every call so that enforcement does not depend on whoever happens to be looking at a chart.
What happens when the circuit breaker trips
When a tenant’s budget for a provider is spent, the circuit breaker for that tenant and provider opens. A run that would call it is held with a clear reason instead of being retried blindly, and it takes its fallback path while someone decides what to do next.
A held run is a question, not an incident: something spent more than expected, and you get to decide why before it happens again.
- Read the trace on the run that tripped it. The per-iteration tokens and tool names usually show which of the three mechanisms above did it — a tool called on repeat, or one huge result that fattened every turn after it.
- Check the ledger entries for the workflow responsible for the spend. A cap that trips once a month is a workflow to look at; a cap that trips every day is a workflow to fix.
- Fix the cause, not the ceiling: cap the retries on the tool that failed, or trim what it hands back to the agent, before you raise the number.
- For a step worth protecting on its own merits — a refund, a send, a delete — put a
human.promptapproval in front of it. A budget limits further model calls; an approval stops the action.
Before you let one run unattended
Set the tenant-and-provider budget before the first unattended run, not after the first surprising one. A cap you chose on purpose, sized to what the workflow should plausibly cost, is a very different thing from a cap you discover by hitting it.
A circuit breaker that has never tripped is not proof that an agent is efficient. It may just mean nobody has looked at what it would take to trip it. Compare what a tenant is actually spending with its cap before you trust the number you set (how AI spend is budgeted covers the ledger and the breaker) — the first budget on a new agent is a guess, and the ledger is what tells you whether the guess was any good.
