A spend cap is a ceiling on what this workspace can commit in a month. It is enforced before a job is queued, not discovered afterwards on a bill, and when it refuses something it shows the arithmetic that refused it.
What a refusal says
Not “limit reached”. A cap refusal names the scope, the ceiling, what is already committed, what this render would add, and the total the two come to, so you can tell “I am nearly out” from “this one render is enormous” without going to look.
It also carries the headroom left, so the next question, what can I still render this month, is answered in the same breath as the refusal.
Two ceilings, and they are checked separately
| Scope | What it protects |
|---|---|
| Workspace | The month’s total across everything. Set in Settings · Spend caps |
| Lot | One project’s own budget, a client engagement that must not exceed what was quoted |
Either can refuse. The message says which one did, because the remedies are different: one is a conversation with yourself and the other is a conversation with a client.
“Committed” is not “billed”
A queued render counts against the cap immediately.
It has to. If only finished jobs counted, every request would see the same untouched headroom and you could enqueue without limit, the cap would hold right up until the moment it mattered.
So the number the cap is working from includes work that is still running. Two things are deliberately excluded, and both are the right call: a job cancelled before it ever started, and a job that failed before it reached the provider. Neither of those ever became money, so neither should eat your month.
Fake renders are free and do not count. Counting them would eat cap headroom for work no provider ever saw.
The month is a UTC month
The window resets at the start of the calendar month, in UTC. That is stated plainly wherever a figure is shown, because a display that disagreed with the thing doing the refusing would be worse than one that is merely not in your timezone.
It is also the same boundary everywhere. Three surfaces once said “this month” and meant three different windows, so the home screen read $0.00 beside a studio reading $8.17 on the same workspace on the same day. One definition now, on both sides of the wire.
The unpriced case, which is its own refusal
A model with no catalogue row cannot be quoted. Under a cap that is a genuine problem: we cannot prove the render fits, because we cannot say what it costs.
Treating it as $0 is the one thing that must not happen, that would let unpriced models walk straight through the ceiling the cap exists to hold. So it refuses instead, and names three ways out:
- Pick a catalogued model.
- Clear the cap.
- Set the workspace to allow unpriced models under a cap, a deliberate choice, made in Settings · Spend caps rather than inferred from a click.
That third one has a real consequence and the product says so rather than burying it: the render will go through, and it spends against a cap it could not be counted against in advance. You find out what it cost when the bill arrives.
One direct provider quotes unknown for everything until its international billing has been opened once, so it needs that setting to render at all.
Where the cap is enforced
Everywhere that spends, not only where you first met it. Rendering a shot, rendering a lot, and each of the paid fixes on an existing take all ask the same question of the same ledger.
That was not always true. Six doors once quoted a price beside a live button and were refused after the click, because only one route could compute a verdict. A cap that is enforced in one place and displayed in another is a cap that surprises people.
Running without one
A cap is optional, and clearing it is a single action. There is an argument for no cap: you are on your own provider accounts, and most providers offer their own limits closer to the money.
The argument for one here is that it is scoped to this software. A provider-side limit protects your account from everything; a cap here protects your account from this tool, including from an agent or a batch doing exactly what it was told to do, twelve times.