Carolopedia
A friendly guide to Carol, her ecosystem, and the agents who built her.
📖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.
⚖️What it is NOT
The neighbours this word is most often confused with, and the line between them.
Not: Estate ceiling
A cap governs one track's spending; the estate ceiling is an outer backstop over everything, not the control.
Not: Vendor limit
A cap names a service or a lane of work; it never names a subscription, a provider or a model.
🧭The nuance
Carol (CAROL-INI-3433, cookbook #976): 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 capspending limitdaily cap