Manage the Model Catalog
Every conversation in C3 AI Agentix runs on an LLM model, and every token that model processes carries a cost and a provider. The LLM service tab is where you decide which of those models your users can pick, and check that each one is reachable.
The catalog is the list of models registered to your environment's LLM service and available for agents and chats to use. C3 AI Agentix does not manage provider accounts or API keys itself: that lives with the LLM service, which handles authentication and billing with each provider. Curation happens on top of that: which registered models your users can pick, the defaults a new chat and a new agent pod start with, and the write-access baseline every agent on the app inherits.
Curate the catalog
When a provider outage takes down one model, a user's chat fails partway through with an error that doesn't obviously point to the model. Open the LLM service tab and run Test all: the affected model fails its health check while the others pass. Disable it to stop new chats from picking it while the provider recovers.
Open Admin from the left navigation and select the LLM service tab. A table lists every registered model with its provider, key, and health status, alongside an Enabled switch that controls whether users can pick it in chat. A summary line shows how many models and providers are registered, and how many of those models are currently enabled.
- Enable or disable a model with its switch. Use it for day-to-day control without changing the underlying registration. Disabling a model you consider too expensive, unapproved, or still under evaluation keeps it out of everyday use without removing it from the registry. Enabling a model only adds it to what users can pick; it changes nothing else. Disabling a model that's currently the chat default or the judge default asks you to confirm first, since doing so clears that default.
- Add model registers a new model into the catalog: a name, the LiteLLM model identifier (for example
openai/gpt-4o), and, optionally, which stored credential to use. - Test health-checks one model on demand; Test all tests every registered model, one at a time. An untested model reads as Not tested until you run one; a failing model also triggers a summary banner. These are live checks made from your session, not a stored health record: running Sync clears them so the next test starts fresh.
- Sync refreshes the catalog from your providers: it re-verifies provider credentials, registers each provider's currently available models, and mirrors them into this catalog.
- LLM service UI opens the underlying LLM service's own console, the place for tasks the catalog doesn't cover, including managing provider API keys.
Set chat defaults
The same panel sets the default model and default reasoning effort for every new chat. Choose Auto (recommended) to let the system pick a model and effort automatically for each turn. Choose No preference to defer to the pod's built-in default model instead, or pick a specific enabled model. Reasoning effort only applies once you choose a specific model; under Auto it shows as routed automatically. A user can still override either one per conversation, from the model and effort pickers in the chat composer. Setting sensible defaults means most conversations start in a cost-appropriate configuration without anyone needing to adjust it.
Set the judge default
Judge default, in the same panel, sets the model used to score conversations for automatic evaluation and as the shadow judge behind Auto routing. It applies only to new agent pods; a pod already running keeps whatever judge it started with until it's recycled. Leaving it at No preference resolves to the newest Sonnet model available in your catalog. You don't have to keep this in sync with your model registrations by hand.
Set app-wide write access
App-wide write access sets the baseline every agent on this app inherits, underneath whatever allow/deny lists that agent defines for itself. Both apply at once, and either one can block a write the other allows. Deny always wins over allow.
Pick one of three modes:
- Full: no restriction; every agent may write to connected apps with no human in the loop. This is the least safe setting, and the UI flags it with a warning.
- Scoped: writes are limited to the allow and deny lists you define. An entry can name an action class (create, update, remove, exec, config, or file), a type, a type/method pair (with wildcards), or a regular expression. A non-empty allow list acts as a whitelist; deny entries block regardless of what allow permits.
- Read-only: every write to a connected app is hard-denied, app-wide, no matter what an individual agent's own lists otherwise allow.
An Effective policy summary always states the resolved posture in one line. It also warns you if your allow list contains only invalid entries, which blocks every write instead of none. Changing modes takes effect on new chats.
Check the service itself
The same panel shows the health of the LLM service's own pods, useful when models are failing health checks across the board and you need to know whether the problem is the models or the service that talks to them.
What the service overview shows
An overview table lists Component, Phase, and Containers, with one row per component even during a rolling update.
Read a container's log
A log tab appears per container. Filter it with space-separated terms, ANDed together; prefix a term with - to exclude it. Turn on auto-scroll to follow a live log. The tab refreshes every five seconds on its own, or immediately if you select refresh.
Permissions
This table maps each action in the LLM service tab to the role required to perform it.
| Action | Role required |
|---|---|
| View the LLM service tab, its model table, and service details | Agentix.AgentAdmin or higher |
| Enable/disable a model, add a model, run Test / Test all / Sync | Agentix.AppAdmin, or a platform administrator |
| Set chat defaults, the judge default, or app-wide write access | Agentix.AppAdmin, or a platform administrator |
For the full role ladder, see Roles and Permissions.