Understanding cost and run ceilings

Why the limit has to come from outside the run

Every other generation path in this plugin is bounded by the shape of the work. One article, one humanising pass, one image: the job is finished when the thing is made. An agent is not built that way. It chooses its own next step from its own last result, so “it will stop when it is done” rests entirely on the model agreeing that it is done.

That is not a safe assumption. A critique loop that keeps finding one more flaw has not failed. A research loop that keeps deciding it needs one more source has not failed either. Both are doing exactly what they were asked to do, and both keep spending. The first anyone usually hears of it is the provider invoice. A ceiling is the part of the system that is not the model’s own judgement.

Checked before the step, not after

The ceiling is tested before a step runs, not once it has finished. The job is to refuse the call that would breach the limit rather than to notice afterwards that it did. A run also has to be in an approved or running state to continue at all, which is what makes a proposal a genuine stop rather than a suggestion.

Each check asks whether the run has reached the number, not whether it has passed it. A run with a five step limit takes five steps. That reads as pedantry until you price it: allowing the step that lands exactly on the ceiling is how a spending limit becomes the limit plus one more article.

The order they are tested

Deadline first, then steps, then spend, then tokens. The order changes what you are told, not whether the run stops.

A run that is out of time is out of time however much budget it has left. When a run crosses two ceilings in the same moment, reporting the deadline is more useful than reporting whichever other limit it also happened to reach.

Zero means no limit

A ceiling of zero means no limit of that kind. For an agent that decides its own next step, that is rarely what anyone wants — set at least a step count and a spend limit before running anything unattended.

Frozen when the run starts

The ceilings are written onto the run at the moment it begins. Editing a playbook or a global setting between clicking and the queue picking the job up cannot change a run already authorised — what you approved is what runs.

Reading what stopped a run

Agent Runs records the reason on the run itself rather than leaving you to infer it from where the work ended. There are four, and the wording is deliberate:

None of them say failed. A run that stopped on a ceiling did what it was allowed to do and then stopped, which is the point. An operator who reads “failed” goes looking for a fault that is not there.

A ceiling that is switched off and a ceiling with nothing left are opposite states, and the plugin never shows them the same way. An unset ceiling reads as no limit. It does not read as nought remaining.