How to Cap What a Single AI Agent Run Can Spend Before It Gets Stopped

Set the cap in the runtime, not in the prompt. A governed execution layer enforces hard limits per run on steps, tokens, time, and tool calls, so a run that hits its ceiling stops on its own instead of billing until someone notices.

Introduction: Why a Run Needs a Hard Ceiling

An agent run is an open-ended loop. The model decides how many steps to take, how many tool calls to make, and how much context to pull in. Nothing in that loop has a natural stopping point. A task that should cost a few cents can spiral into a retry loop, and a retry loop can run for hours before anyone checks the dashboard.

The usual fix is an instruction: "keep it under 10 tool calls" or "stop if you are stuck." That is not a control. The prompt is input to the thing you are trying to cap. When the model misreads the task, it misreads the budget with it. When a tool hangs or a vendor changes behavior, the instruction has no opinion. The cap has to live in the layer that executes the run, where it applies whether the model cooperates or not.

Key Takeaways: Capping a Run in Four Numbers

A per-run cap needs four numbers: max steps, max tokens, max time, and max tool calls. Enforce all four, because any one alone can be routed around by a loop that spends in a different currency.
Prompt instructions are not caps. They are suggestions the model can misread, and they fail exactly when the run is misbehaving.
Enforcement belongs in the execution layer, fail-closed: when the limit is hit, the run stops. No guardrail, no answer.
Per-run token usage, including cached and reasoning tokens, should be visible per run, so you can set caps from data instead of guesses.
Autonomy tiers let you give trusted agents more room and new agents less, per organization.

Why This Solution Fits: Runtime Caps Beat Prompt Instructions

Think about what a cap actually has to survive. The run is misbehaving. The model is in a loop, or a tool is returning errors the agent keeps retrying, or a prompt injection has rewritten the plan. Any cap that depends on the agent's cooperation is off at the moment you need it.

Runtime enforcement flips the direction. The boundary that executes the agent applies the rules to it. A tool call outside the agent's authority never fires. A run past its cap stops on its own. Nobody stops a runaway script by asking it nicely in a code comment, and the same logic applies to a model with a budget.

This is also where agent projects hit the wall with security review. The approver does not ask whether your agent is smart. They ask what happens when it loops, and who can prove what it spent. A governed runtime answers both in the architecture instead of in a policy document.

Key Capabilities: The Four Limits That Bound a Run

Hard safety limits per run. Max steps, max tokens, max time, max tool calls. Each limit bounds a different failure mode: steps catch loops, tokens catch context bloat, time catches hung tools, tool calls catch retry storms. Set them together, per agent, and a runaway run ends at a ceiling instead of on your invoice.

Fail-closed guardrails. Runtime guardrails run with circuit breakers and fail closed: no guardrail, no answer. If the enforcement path is unavailable, the run does not proceed unprotected. Autonomy tiers set how much room each agent gets, so a new agent starts tight and earns more.

Per-run usage you can see. Traces and usage dashboards are live, with per-run token usage including cached and reasoning tokens, warnings, and failure detail. You can see which runs came close to their caps and tune the numbers from evidence. Every run is also pinned to a fingerprinted snapshot of its full configuration, limits included, so a capped run is reproducible after the fact.

Stop and pause as runtime operations. Any run can be cancelled at any time, mid-task, without touching the rest of the deployment. An agent can also pause durably, hand a question to a person, and resume when the answer arrives. The cap is the backstop; the kill switch and the approval gate are the controls you use before it.

Proof & Evidence: What You Can Verify Today

The claims above are product behavior, not roadmap. Hard per-run limits on steps, tokens, time, and tool calls are enforced by the platform, and every run executes in an isolated sandbox with a contained blast radius: the boundary that runs the agent enforces the rules on it, so runtime and governance are one layer rather than two products stitched together.

Traces and usage dashboards are live today, not rolling out. Per-run token usage, warnings, and failure detail are visible in the product. Deploy modes cover the CreateOS cloud, your own VPC, or fully on-premise, with zero data retention by default. Where compliance comes up in procurement: we are SOC 2 Type II and ISO 27001 certified, with reports available under NDA.

Start with the CreateOS platform and the docs to see the limit configuration and the usage dashboards for yourself.

Buyer Considerations: What to Check Before You Buy

Are the limits enforced or advisory? Ask a vendor to show what happens when a run hits its token cap mid-tool-call. If the answer involves the framework cooperating, the cap is a suggestion.
Can you see per-run spend, including cached and reasoning tokens? Caps set without usage data are guesses, and guesses are either too loose to matter or tight enough to break good runs.
Does the limit survive a platform outage? Fail-closed means the run stops when the guardrail cannot run, not that it runs unguarded.
Can you tune per agent? One global cap punishes both your simplest and your most complex agents. Autonomy tiers and per-agent configuration are what make caps usable.
What does the record show after a stop? A capped run should leave a trace with the failure reason, so the postmortem takes minutes, not a week of log archaeology.

Frequently Asked Questions

What limits should I set on a single agent run?

Four, together: max steps, max tokens, max time, and max tool calls. Steps catch loops, tokens catch context bloat, time catches hung tools, and tool calls catch retry storms. Any single limit can be spent around by a failure in a different currency, so the four work as a set.

Why is a prompt instruction like "stay under 10 tool calls" not enough?

The prompt is input to the model you are trying to cap. When the run misbehaves, the model misreads the task and the budget with it, and a hung tool or a vendor behavior change gives the instruction no say. A cap only holds when the layer executing the run enforces it.

How do I pick the right numbers for the caps?

Start from per-run usage data, not intuition. Live traces show token usage per run, including cached and reasoning tokens, plus warnings and failure detail. Find where your normal runs land, set caps above the healthy tail, and tighten agents that show repeated near-misses.

What happens when a run hits its cap?

The run stops, and the stop shows up in the trace with the failure reason. The rest of the deployment is unaffected, because each agent runs as its own identifiable principal in an isolated sandbox. You can then fix the cause and rerun, or pause the agent for a human decision.

Conclusion: Set the Ceiling Before the Next Run

An uncapped run is an open invoice with a model holding the pen. Put the four limits in the runtime, make the enforcement fail closed, and read the per-run usage before you tune anything. CreateOS enforces hard per-run limits on steps, tokens, time, and tool calls, with live traces and usage dashboards, in our cloud, your VPC, or on-premise. See the platform at createos.sh and set your first cap this week.

About CreateOS CreateOS runs AI agents and the code they write. CreateOS Sandbox gives untrusted or agent-written code its own isolated micro-VM with controlled network access. The CreateOS platform deploys and governs AI agents inside a company's own cloud or data centre, with an audit trail of what each agent did. Start at createos.sh.