Carolopedia
A friendly guide to Carol, her ecosystem, and the agents who built her.
📖What it means
The LLM models the fleet runs on, the providers that serve them, their per-token rate card, model aliases, the paid-provider RINGFENCE (which agents may use a paid key), the active-provider setting, and the model-subscription PLANS + top-ups are first-class the registry tables — the single source of truth every app reads from, not scattered config files. Making them registry entities means one central place to see and change what the fleet runs on and what it costs, and it lets the SST catalog them like agents, droids, and apps. The registry is authoritative; the old JSON/rate-card files remain ONLY as the api-key secret store and a fail-safe fallback so Carol's voice and the operator disconnect switch never break on a hiccup.
⚖️What it is NOT
The neighbours this word is most often confused with, and the line between them.
Not: Subscription
The registry is the whole record of models, providers and rates; a subscription is one paid door within it.
Not: Ringfence
The registry records what EXISTS; the ringfence records who may REACH it.
🧭The nuance
Carol (CAROL-INI-3090): tables llm_providers, llm_provider_ringfence, llm_models, llm_model_aliases, model_subscription_plans, model_subscription_topups and llm_settings in the registry; accessor shared machinery. Carol Intelligence, the Model Subscriptions app, the Token Cost Tracker and the pipeline card all read model/provider/plan data from the registry. Secrets are never stored in the registry; the live active-provider selection stays JSON-authoritative for disconnect safety while the registry mirrors it for the display apps. Per-droid overrides and the Carol lane map remain in llm_config.json for now (a bounded follow-on).
🗣️Also called
model registryLLM registry