Agent cost control: cap runaway token spend with a ceiling, not a ban
A cost ceiling stops agents before they burn a month's budget; this guide covers the three spend drivers, the approval gate, the audit trail, and the durable limits that survive a model repricing.
Last updated
8 minute read · Written by the team that builds UtilitySpaces. More about UtilitySpaces.
Agent cost control is the practice of bounding how much a running AI agent can spend on tokens, tool calls and runtime before it stops and asks for permission to spend more. The durable fix is a hard cost ceiling tied to the approval gate, not a ban on agents or a model-specific token limit that breaks when prices change.
Set a daily or monthly cost ceiling at the workspace level, and have it stop any agent the moment projected spend would cross it. When an agent approaches the ceiling, the gate pauses it and routes the pending action to a human for approval — the request carries the requesting agent, the channel, a preview of the work, and the running spend total. The approval, the spend and the timestamp all write to an audit trail, so every token billed has a who-approved-it receipt. This is a ceiling you raise deliberately, not a token cap you tweak per model. When a model drops in price, the ceiling stays; the agent simply does more within the same budget instead of breaking on a lower token count. We build UtilitySpaces, a managed service for teams, where the ceiling is one of several guardrails that hold regardless of which model is cheapest this week.
What drives an AI agent’s bill between clock and compute?
Three things. AI agents on UtilitySpaces bill against three independent drivers — tokens, tool calls, and the time the agent stays running, as detailed on /product/costs. A cost ceiling must bound each one.
First, tokens in and out. Every prompt the agent sends to a model and every token the model returns is metered, at the live rate for the model that was picked. A chatty agent that restates the same context each turn, or rambles in its output, spends real money fast — and the rate changes every time a provider reprices. The bill is not locked to what was cheap last month.
Second, tool calls. Each connector write, each API request, each lookup the agent makes costs something — whether that is the model provider’s per-call fee or the downstream application’s rate plan. A connector that paginates through thousands of records, or retries on a transient error, stacks up calls that were not in the original estimate. Tool-call spend is often the one the team forgets to model, because it is invisible next to the token line.
Third, time the agent stays running autonomously. An agent that runs for an hour making ten calls a minute accrues more than one that finishes in five. The duration is not free; the compute that keeps the agent alive between calls is billed, and an agent left looping without a stop condition can run a small job into a large one.
Cost control is bounding each driver, not banning agents. A ceiling at the workspace level stops the run before the sum of all three crosses the line.
Why does a cost ceiling beat a token cap when model prices change?
A token cap limits how many tokens an agent may use, but token counts and cost do not move together. When a model drops in price, the same token budget buys more work; when it rises, the same tokens buy less than the cap implied. A ceiling in money units stays constant regardless of which side of the equation moves, and that is the difference that survives a price cut announced on a Tuesday and a routing change deployed on a Thursday.
The brief mentions model routing — the ability to pick a cheaper model for a read and a pricier one for a write within the same run. Token caps fight that routing because each model carries its own per-token rate; a ceiling in spend does not.
| Control | Ceiling | Token cap | Per-agent budget |
|---|---|---|---|
| Survives a price cut | Yes — budget stays fixed | No — tokens under-spend the same money | Partial — still reads the old rate |
| Stops runaway spend | Yes — hard stop | Conditional — only if value does not exceed the cap | Yes — but only that agent’s slice |
| Task finishes intact | Yes — within budget | No — may abort mid-task | Yes — within budget |
| Reviewable per run | Yes — tied to the audit log | No | Partial |
| Survives model routing | Yes — money is the unit | No — each model has its own rate | Partial |
How the approval gate turns every spend bump into a reviewable choice
The ceiling does not just kill a run. It triggers the approval gate: the threshold-that-stops-and-asks behaviour. When an agent’s projected spend crosses a step on the way to the ceiling, the agent pauses and submits an approval request. That request carries the requesting agent, the channel it happened in, a preview of the content about to be committed, the current spend total against the ceiling, and a status.
A reviewer sees the spend, the work, and the margin left — then decides whether to raise the ceiling for this run or cut the task short. Every decision flows through one review function: the web UI action, an inline button in a messaging channel, and a devspace step all reach the same code, so the record says approved and the action actually happened.
How approval gate design works — which actions deserve to stop and ask, and which should not — is the same guardrail set the ceiling belongs to.
Who let the agent spend what, when?
An audit trail answers that in one place. Every approval, every rejected request, and every token billed writes to a log that is append-only with one monotonic sequence number per workspace. Each entry stores the actor, the timestamp, the spend delta, and a small key-value bag with the agent id and the connector involved.
The chain is a SHA-256 hash chain: altering or deleting any entry breaks the chain, and a server-side verification pass reports the exact sequence number where it broke. That proves the log has not been edited since it was written. It does not prove the log is complete — a code path that forgot to write an entry still verifies perfectly — but completeness is a coverage question asked of every cost-control decision, not an afterthought.
The ceiling is a spending guardrail, not an anomaly detector. It reacts to spend crossing a line, not to a rule that has drifted until the spend shows it. The only signal it misses is the one nobody reads the trail after the fact.
Where do the durable limits actually live?
The ceiling is not the only limit, and it should not be the only one you set. The durable limits live at four boundaries, each of which holds regardless of which model is cheapest this week.
First, the workspace boundary. Every AI agents runs inside a workspace, and ceilings are enforced there, so a runaway agent in one workspace cannot cross into another. The ceiling is scoped to the workspace id, not to a model or a task.
Second, the API-key scope. A workspace that brings its own model-provider key moves the model bill onto a statement teams already read and cap externally; the in-product ceiling is then a second, finer-grained guard, not the only one. The model line is visible at live rates on the cost page, by model and by workspace, so there is no surprise in the rate between the ceiling and the statement.
Third, the schedule. Automations and on-demand tasks are both metered, but schedules are the unit that runs while the team is asleep — and the one that most needs a visible ceiling. The automations page describes how schedules are set and metered.
Fourth, the per-app connector scope. A connector write waits for a person unless an admin has marked that specific connection autonomous; the cost of a connector write is part of the same spend the ceiling tracks. A connector that paginates through thousands of records, or retries on a transient error, is the spend that needs a ceiling most.
The pricing plans page carries the figures for each tier; this post points at the controls rather than restating numbers that change. Rates move, and the ceiling is the control that does not.
What to automate first when your ceiling is tight?
When the ceiling is tight, start where a wrong answer is cheap. Low-risk, bounded reads and reviews come first: summarising a thread, flagging a stale task, drafting an internal note. These produce small, reversible outputs and the ceiling barely moves.
Irreversible writes stay later: anything touching money, deletes, messages to customers, or writes to an app the agent has never written to. The approval gate still holds them, but the ceiling makes the case sharper — every such call eats into the budget, so it should earn its place.
The ordering for what to hand an agent in week one, and what to leave alone for six months, is laid out in what to automate first, which sets the practical sequence this ceiling is meant to protect.
Limits, trade-offs, and when not to rely on the ceiling alone
The ceiling is the right control for money-bound teams, and it is not a universal one.
It stops spend, not correctness. An agent that drafts a wrong but cheap reply stays under the ceiling and still needs a person to review the output. It is not anomaly detection — it reacts to spend crossing a line, not to a rule that has drifted until the spend shows it.
It also cannot reach an agent that runs outside UtilitySpaces. A ceiling you cannot see is not a ceiling at all, so any agent whose spend you need to cap must run through this workspace. There is no external override. And the ceiling is a spending limit, not a substitute for scoping connectors narrowly; a connector with wide access and a high ceiling can still do wide damage before the line is crossed.
The real limit is organisational. The ceiling, the approval gate, and the audit trail are guardrails that hold together; neither one of them catches everything on its own, and none of them replaces a person who reads the thread and the cost page on their own schedule. We build UtilitySpaces, a managed service for teams, where these controls ship together — not as a single magic dial, but as a set of limits that hold whether the model that was cheapest last week is still cheapest today.