One cap for every AI: how a spending cap works

A cap you discover after the bill arrives is not a cap. This article explains the one rule Cortex66 builds everything on: money fails closed. The cap comes first, it is reserved before anything leaves, and whatever cannot be priced does not run.

The cap comes first

Every task starts with a receipt: the most it can cost. Nothing runs until you accept it. When you do, the cap is reserved before any paid call, and it is checked again on the way back. If a price is unknown, the task is not allowed to run. The run stops at the cap and the receipt shows what was spent; you decide whether to raise it.

This is true for every AI in the workspace, on your own keys and on ours alike. One rule, one place, no exceptions per provider.

Who sets the cap

You do. Defaults are shown as suggestions, and nothing is set without a yes. A workspace has three kinds of cap:

• the workspace monthly cap;
• the project's default cap per run;
• a per-user daily cap.

Raising a cap is a deliberate act: it needs a fresh sign-in step and the right to edit budgets, and two people editing the same cap at once never overwrite each other. The screen shows settled, reserved and pending spend per scope, read from the ledger, never from a cache.

A tree of caps, and the tightest line wins

Caps form a tree: workspace → user → project → run → one step. Each level can draw two kinds of line:

• a hard line (the month, a day, a single run) that a request may not cross: the request is refused at the door;
• a soft line (by default 85 % of the hard one) that changes behaviour instead of refusing: the run steps down to the cheapest model only, or it stops and asks you.

When a request arrives, every scope on its path is checked and the tightest scope wins. A hard line the request would cross binds and refuses; otherwise a crossed soft line acts by its scope's rule; otherwise the line with the least headroom left is "tightest now", and past 60 % you see a warning before it becomes a block.

Stop at the door, never mid-flow

A step that was admitted finishes. The cap is enforced where a new spend is admitted, not by cutting a running answer in half. A new message needs its whole cap left to start; a turn that already started finishes or ends partial; each later step is its own reservation. A cancel pays only the real cost: the step is settled at what came back and the rest of the hold is released.

Lowering a cap below what is already committed

The new cap applies to new admissions immediately. Reservations made under the earlier cap remain and settle, and the screen says "already committed above the new cap". No new spend is admitted until the total fits. A cap is an admission limit; what was committed earlier is reported, never hidden.

Alerts that never act for you

At 50 %, 80 % and 100 % of a cap the cap's owner is told once per period, with the cheapest allowed lane as a suggestion. An alert never changes a cap or a route by itself.

A second fence at the provider

For a key whose provider supports project spend limits, the connection screen recommends setting one there too. Our ledger stays the authority; the provider's limit only catches a bug or a leaked key.

Read next: bring your own key and which model for which task.