Spend limits

The runaway this feature exists for is not a run you are watching cost too much. It is a scheduled workflow that fails, retries, and fails again through the night while nobody is looking. A spend limit is a ceiling that stops new work from starting once the month's estimated spend reaches the number you set.

Limits live under Settings, in the Spending limits section.

Three scopes

You set a monthly cap in US dollars at three levels:

• You, covering everything your own account runs.
• Everything in this workspace.
• A single workflow. Every workflow gets its own row, whether or not it has a cap today.

They are independent limits and all three are checked, widest first. Whichever one is exhausted is the one that stops the work, and the message names it, so you are pointed at the control that actually unblocks you rather than the narrowest one that happens to apply.

A scope with no cap has no limit. Removing a cap is the same state as never having set one.

Amounts are in US dollars. There is no other currency, and no way to express a limit as anything other than a monthly total.

A month is a calendar month

Spend is summed over the calendar month, in the reset timezone the workspace chooses. UTC is the default, and the setting sits at the bottom of the same screen: The spend month rolls over in. One workspace has one reset moment for all three of its scopes.

There is no reset job and no counter to zero. Current spend is a sum over the work that finished inside the current window, so a budget resets because the window moved. Nothing has to run at midnight on the first, which means nothing can fail to run. Changing the timezone changes the boundaries and takes effect on the next read: there is nothing to recompute.

Work counts against the month it finished in. A run that starts at 23:50 on the last day and finishes after midnight bills its last stretch to the new month.

The number is an estimate, and says so

Three reasons, all deliberate:

• Nothing is reserved in advance. The check asks whether the month has reached the cap yet, and several jobs can pass it in the same moment before any of them has landed a cost. The overshoot is bounded by how much work can run at once, not by zero. Reserving would buy billing-grade exactness and bring a class of leaked-reservation bugs along with it.
• Failed attempts still spend. A run that burned tokens and then failed cost real money, and it counts.
• Some real spend has no price attached yet. Browser session time and sandbox time are both measured and recorded, but neither has a rate, so no cap can see them. Browser time is shown to you in minutes anyway, because guessing at it is worse than reading it.

What happens when a limit is reached

Enforcement happens when work is admitted, and nowhere else. Anything already underway finishes: a run in flight, a step in progress, a gate you already approved that is now resuming. Stopping work mid-flight saves very little, since one run's spend is already bounded by its turn limit, and it costs the thing people actually care about, which is that a decision they made gets carried out.

What happens to new work depends on whether anyone is watching.

Unattended work parks. A run from a schedule or an incoming event keeps its place in the queue. It records which limit stopped it and the earliest moment it may try again, and it drains itself: when the month rolls over, or when you raise the cap, it wakes up and runs. On the Runs screen, pick a workflow and open the Queued view to see it, marked "Paused: monthly spend estimate reached" with the date it resumes. Parked work is counted in the waiting totals rather than hidden.

Attended work fails readably. Firing a run yourself, starting a test run, or sending a message in an interview is refused on the spot, with the numbers in the message: roughly what has been spent, what the cap is, and when new work resumes. Somebody is looking at a screen, and a run that silently never starts is worse than a refusal you can read.

You also get one email per scope per month, the first time a limit bites. A park is otherwise completely silent, which is the case that needs the message most. See notifications.

Raising a limit releases what it parked

Raising a cap is a single act: the number changes, and every job that that cap had parked is released in the same move. Raising a workflow's cap does not wake work parked on the workspace's cap, and the other way round.

Waking is not the same as admitting. A released job re-checks its limits when it is picked up, and if the raise was not enough it parks again. That is what makes "start conservative, watch it bite, raise gradually" a workable flow instead of a manual restart per job.

Removing a cap releases its parked work the same way.

Where the month went

Each scope shows what it has spent so far this month next to its cap, and splits it by who paid: your own model key, All-Agents billing, and the part that fell back onto All-Agents billing because your key stopped working. Those are separate numbers because a run that starts on your key and falls back mid-flight is genuinely two stretches of spend with two different payers. See model selection and BYOK.

Browser time appears as minutes, labelled as measured but not priced yet.

A scope that has reached its cap is marked, with a line saying new work waits until the month rolls over or you raise the limit. The workspace overview repeats the tightest of your limits under the runs figure, as spend against cap. If you have set no caps at all, that line is absent rather than showing a zero.

A fallback onto All-Agents billing draws from the same cap. Moving to a different key changes who is billed, never how much may be spent.

What a cap does not do

• It does not cap a single run. The bound on one run is its turn limit, not dollars.
• It does not stop work already underway, ever.
• It does not warn you at a threshold below the cap. The message comes when the limit is reached.
• It does not split into separate caps per payer. One total per scope is the number you set, and the payer split lives in the breakdown.