📖What it means

Every daily spending limit answers 'which service or lane of work is spending this', never 'which vendor's model served it'. The vendor stays recorded on every cost row for reporting — the LIMIT just never keys on it. Enforcement is refuse-before-spend at the single LLM chokepoint: a lane that has consumed its cap is parked before the next call, while other lanes keep spending. Vendor-shaped books (per-provider caps, a 'billed/fleet' book) are retired and REFUSED at write time so they cannot be resurrected.

📖Easily confused with

[{"term": "Estate ceiling", "distinction": "A cap governs one track's spending; the estate ceiling is an outer backstop over everything, not the control."}, {"term": "Vendor limit", "distinction": "A cap names a service or a lane of work; it never names a subscription, a provider or a model."}]

📖Nuance

Carol: shared machinery keeps scopes agent/consciousness/global/lane/service/track only and raises on a provider or fleet scope (upsert, set_exception, and the json mirror strips a resurrected vendor key); shared machinery budget_status(lane=None) reports the master ceiling or one named lane and takes no provider argument, which migrated the refuse-before-spend gate in shared machinery with no edit. Operator lifts are day-scoped exceptions on the named lane, never a raised vendor cap.

📖Also called

- budget cap
- spending limit
- daily cap

📖Filed under

Category: money.

Service: Cost Center.