📖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.

📖Easily confused with

[{"term": "Subscription", "distinction": "The registry is the whole record of models, providers and rates; a subscription is one paid door within it."}, {"term": "Ringfence", "distinction": "The registry records what EXISTS; the ringfence records who may REACH it."}]

📖Nuance

Carol: 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). Held by the Budget Control track until 2026-09-17; subscriptions, their plans and their provider balances moved to Procurement with the app and the droids that read them ((Ninad, CLI-468, 2026-09-17)).

📖Also called

- model registry
- LLM registry

📖Filed under

Category: money.

Service: Cost Center.