It usually starts on a Friday afternoon. Someone deploys an agent. The agent works well in testing — a few calls, reasonable cost, everything looks fine. They ship it and go home.
By Sunday night, the bill is $14,000.
This has happened at enough companies that the pattern has a shape. Understanding the shape is the first step to making sure it doesn't happen to you.
How the loop forms
Agents are different from single-shot API calls in one critical way: they're designed to keep going. That's the whole point — you give an agent a goal, and it figures out the steps.
The problem is that "figuring out the steps" involves calling the model. And calling the model to plan the next step sometimes results in a plan that involves calling the model again. And again. On a task that turns out to be harder than expected. Or on a task that encounters an error and retries. Or on a task that succeeds but the agent doesn't recognize the success condition.
The model has no concept of budget. It's not trying to be expensive. It's doing exactly what you told it to do: keep working until the task is done. The cost is your problem, not its problem.
The retry multiplier
One particularly common failure mode: an agent that retries on error.
Your agent calls a tool. The tool returns an error — maybe a rate limit, maybe a transient timeout, maybe a malformed response. The agent, being a good agent, retries. The tool fails again. The agent retries again. It might do this twenty times before giving up. Each retry involves at least one model call to decide what to do next.
Now multiply that by: the agent is running three parallel subtasks. Each subtask can retry independently. Your twenty retries per subtask become sixty model calls before anything useful happens.
A well-built agent has retry limits and backoff. But "well-built" is doing a lot of work in that sentence. In practice, many agents are built with retry logic that seemed reasonable in testing and turns catastrophic in production.
The context window cost
Another pattern: the agent's context grows with each step.
At step 1, the agent sends a short prompt. At step 10, it's sending the original prompt plus nine rounds of tool calls and results. At step 50, it might be sending 50,000 tokens just to ask what to do next.
Token-in costs add up. A task that was $0.02 at step 1 might cost $2.00 at step 50 just due to context accumulation — before you count the actual output. If the task takes 200 steps, the math gets painful.
This is the compounding cost problem. Single-shot calls have linear costs. Agents can have superlinear costs depending on how the context grows.
The authorization problem
The $14,000 weekend usually has one other ingredient: nobody was watching.
In business hours, someone might notice a spike in the usage dashboard. But agents run at 3 AM on Saturdays because that's when you scheduled the batch job. Nobody is watching the dashboard at 3 AM on a Saturday. By the time someone notices Monday morning, 60 hours of uncapped spending have happened.
This is not a monitoring problem. You can add alerts — but if the alert fires at 3 AM and the on-call engineer doesn't wake up for it, you've lost four more hours. The right solution isn't better alerting. It's not allowing the spend to happen in the first place.
Budget envelopes, not alerts
The architectural fix is budget enforcement before the call, not visibility after.
A spend token is a budget envelope. You mint it with a maximum spend amount, a set of allowed models, and an expiry. Every API call the agent makes goes through the gateway with this spend token. Before the call goes to the provider, the gateway atomically reserves the estimated cost against the envelope. When the envelope is empty, the next call gets a 402 — not a timeout, not an error, a clean rejection.
The agent stops spending. Automatically. Without anyone having to wake up at 3 AM.
The key word is "atomically." The reserve-then-call operation happens in a database transaction. You can't have two concurrent agent threads both think there's $5 left and both proceed with a $4.50 call. One gets through; the other gets the 402. This is the difference between a soft budget and a hard budget.
Designing for budget awareness
Once you have hard budget enforcement, you can design your agents to be budget-aware. Before starting a long task, check the remaining envelope. If it's less than your estimate for the task, don't start — or prompt the user to add budget. After each subtask, check the remaining envelope and decide whether to continue.
This isn't paranoid over-engineering. It's what responsible agent development looks like when the cost is real.
The analogy: a contractor who checks their materials budget before ordering supplies, rather than ordering everything and hoping the client pays. The behavior is normal in every other context. It's just new in AI.
What the envelope tells you after the fact
A spent budget envelope isn't just a spending control — it's a record.
After the weekend job runs, you can look at the envelope's ledger: how many tokens were reserved, how many were settled, what models were used, what the reserve-to-settle ratio was (an unusually high ratio suggests a lot of retries or abandoned calls). That ledger is the audit trail for your agent's behavior, not just its cost.
For compliance purposes — "what did agent X do last weekend?" — the spend token ledger is often more useful than the raw request logs, because it tells you the intent (the budget that was authorized) alongside the execution.
Every token counts
The $14,000 weekend is preventable. The spending pattern that causes it is predictable. The infrastructure to stop it is a 30-minute deploy.
The question isn't whether your agents could run up unexpected costs. Given enough time and enough agents, they will. The question is whether you've built the circuit breaker before it happens.
Visionality's Spend Token system is the circuit breaker. See how it works →