Cost control · Operations

Bounding what an autonomous agent can spend

A ceiling that stops a task is not a ceiling that stops a bill. ClearFrame reports the limit it reached and states in the interface that the stop is measured rather than pre-emptive.

Last updated September 28, 2026

September 18, 2026 · Cost control · Operations · 5 min read

ClearFrame offers two limits for that reason, and the difference between them matters more than either one alone.

Two limits

LIMIT 01

Token ceiling

A cap on tokens for a single task. It suits work whose shape is known: the job should cost roughly this much, and beyond that something has gone wrong.

LIMIT 02

Plan-percentage stop

A stop at a chosen percentage of managed-plan usage. It answers a different question, which is how much of a billing period should go to one task before a review is wanted.

A ceiling protects one run from a runaway loop. A percentage stop protects the period from a series of runs that each looked reasonable. The two compose.

What the limits are not

They are measured stops, not pre-emptive refusals. When a ceiling is reached, work already in flight can consume further usage before it settles. A run that stops at the ceiling can therefore cost slightly more than the ceiling.

This is a property of the billing model rather than a shortfall in the implementation. The provider charges for calls already made. A product that described its ceiling as absolute would be describing something it cannot enforce, and the difference shows up on an invoice.

Three reasons a task stops

The application distinguishes the reasons, which matters because the remedy differs for each. The three appear in the interface as follows:

Stop conditions reported by the Active panel.
Reported reason	Meaning
Token ceiling reached	The task exceeded the budget set for it. The work may have been legitimate, or the task may have looped.
Plan limit reached	Managed usage for the period is exhausted. The task did nothing wrong.
Round limit reached	The task reached a turn cap, a deliberate bound on how long it may continue.

A single "stopped" state would collapse a budget constraint, a billing constraint and a scope constraint into one signal. The three are not interchangeable.

The counter does not reset itself

Once a ceiling has fired, it stays fired until the counter is reset, which is a separate control in the Active panel. Resuming a task does not clear it. The two actions are kept apart deliberately: resuming means continue this work, and raising the budget means the operator has reviewed the cost and chosen to spend more.

Two things outside the meter

Provider accounts the user supplies. Where a ChatGPT or Claude subscription, or a personal API key, is connected, spending on that account is separate from ClearFrame usage and is not governed by the ceiling.
Remote execution. Where remote runs are enabled, the additional usage estimate is shown before the run starts, because it follows a different cost model from local tokens. It is disclosed rather than merged into the same total.

Where the controls live

Both limits are set from the Active panel, which shows usage as a percentage remaining and carries the two controls beside it. The ceiling takes a number, and a separate control resets the spend counter. Nothing about the panel is hidden behind a settings screen, which matters because a limit is only useful if it is visible while the work is running rather than configured once and forgotten.

The panel distinguishes the stop reasons in its own vocabulary. The three reasons are separate labels rather than a shared error state, and each is presented with the same weight. A dashboard that showed a single "stopped" badge would make the operator open a log to find out which limit had fired, at which point the label was doing no work.

Why the ceiling is per task

A per-task ceiling follows from how the work is structured. A task holds one goal and runs until the goal is met, the budget is exhausted, or a person intervenes. That makes the task the natural unit for a budget: it is the thing whose cost can be estimated in advance, and the thing whose overrun is meaningful.

A single global cap has the opposite property. It is simple to set and says nothing about any particular piece of work, so a run that consumes the month's budget reports nothing beyond the fact that it did. Percentage stops exist alongside the ceiling because the two units answer different questions, and neither substitutes for the other.

The margin question

Because the stop is measured, the useful number is not the expected cost but the expected cost plus one turn. A task that stops at its ceiling has already paid for the turn that crossed it. Setting a ceiling at the exact expected cost therefore guarantees a stop at the point where the work was almost finished, which is the least useful place to stop.

This is a property of the mechanism rather than a defect, and it is the reason the interface describes the stop as measured. An operator who understands the margin sets a ceiling they are content to overshoot slightly. An operator who does not learns the distinction from an invoice.