CT-Ops

AI Model Settings

Global CT-Ops settings for hosted and local AI model connections.

The AI Models integration settings page controls the AI provider connections and model allow-list for the current CT-Ops instance. Open it from Settings -> Integrations -> AI Models at /settings/integrations/ai.

Future CT-Ops features that use AI must request a model from this allow-list. They do not configure provider credentials directly.

Administrators can add more than one connection, including multiple external hosted providers. CT-Ops lists enabled models from all enabled connections in AI-capable product screens so the operator can choose the right provider and model for the task.

Access and scope

Only instance administrators can open and change this page. Settings apply to the current CT-Ops instance.

The page has two main areas:

Area	What it controls
AI provider connections	Hosted or local model provider endpoints, stored credentials, status, timeout, and TLS mode.
Allowed models	The exact model IDs CT-Ops features may call through each provider connection.

Supported providers

CT-Ops supports these provider types:

Provider	Typical use	Endpoint handling
OpenAI	Hosted OpenAI GPT and reasoning models.	Uses the standard OpenAI API endpoint.
Anthropic	Hosted Claude models.	Uses the standard Anthropic API endpoint.
Google Gemini	Hosted Gemini models.	Uses the standard Google Gemini API endpoint.
OpenAI-compatible / local	Local or self-hosted runtimes such as Ollama, LM Studio, vLLM, llama.cpp-style servers, or internal model gateways.	Requires an explicit `http` or `https` base URL.

OpenAI-compatible connections are the recommended path for locally running LLMs because many local runtimes expose an OpenAI-compatible /v1 API. The model ID is runtime-specific, so CT-Ops can discover model IDs from the endpoint’s /models response and still lets administrators add custom model IDs when a runtime does not expose discovery.

Provider connection fields

Use Add connection or Edit to open the provider connection dialog.

Field or control	Default	Validation	What it does
Provider	OpenAI	One of the supported providers	Selects the hosted provider or OpenAI-compatible local endpoint mode.
Connection name	Provider-specific default when blank	Up to 120 characters	Human-readable label for operators and audit events.
Local endpoint URL	Blank	Required for OpenAI-compatible connections; must use `http` or `https`	Base URL CT-Ops uses for local or self-hosted OpenAI-compatible requests.
API key	Blank	Required for hosted providers; optional for local endpoints	Secret used for provider authentication. Leave blank on edit to keep the existing key.
Timeout (ms)	`30000`	Whole number from 1,000 through 120,000	Request timeout for model calls through this connection.
TLS mode	Public CA	One of the supported modes	Describes how CT-Ops should treat the endpoint transport.
Enable connection	Enabled for new connections	Boolean	Only enabled connections can serve AI requests.
Save connection	Enabled unless saving is in progress	Server-side validation and administrator access	Stores the connection and encrypted credential state.

API keys are encrypted at rest and are never returned to browser code. The settings page only shows whether a key is configured.

Use the connection card’s Enable or Disable action when a provider should be taken in or out of service temporarily. Disabling a provider stops CT-Ops from offering or calling its models, but keeps the encrypted API key so the administrator can enable the provider again without re-entering the secret.

Supported TLS modes:

TLS mode	When to use it
Public CA	The endpoint uses a certificate trusted by normal public CAs.
Private CA	The endpoint uses an internal CA trusted by the CT-Ops service environment.
Pinned certificate	The deployment pins a specific certificate fingerprint.
Insecure HTTP	Only for explicitly accepted HTTP local endpoints or non-production testing. Plain `http` local URLs require this mode.

Allowed models

Use the Models button on a provider connection to open the allow-list dialog.

Field or control	What it does
Add provider model	For hosted providers, adds one of the seeded common model IDs for the selected provider.
Fetch models	Calls the provider model-list API and replaces the draft allow-list with the returned model IDs. For OpenAI-compatible connections, this calls the configured endpoint’s `/models` route.
Custom model ID	Adds a provider-specific or local-runtime model ID.
Optional custom display name	Sets the operator-facing name for the custom model.
Globally enabled	Allows or blocks CT-Ops features from calling that specific model. Disable a model here to remove it from every CT-Ops AI model picker without deleting it from the connection.
Default	Marks the preferred model for that connection. If multiple rows are marked, CT-Ops keeps a single enabled default.
Remove	Deletes the model from the connection allow-list.
Save models	Replaces the saved allow-list after server-side validation.

At least one enabled model is needed before the connection can be tested or used by future AI-backed CT-Ops features.

Hosted provider discovery uses the configured API key to ask OpenAI, Anthropic, or Google Gemini for the models available to that account. Review the fetched list before saving, because the discovery action updates only the draft rows in the dialog until Save models is selected.

For local runtimes such as vLLM, set the local endpoint URL to the OpenAI-compatible base path, for example http://llm-host:8000/v1. After saving the connection, open Models, choose Fetch models, review the discovered rows, set the default model, and then choose Save models. The model ID is the served ID CT-Ops sends in requests. When the endpoint also returns a root value, CT-Ops uses that underlying model name as the display label so aliases such as local-it-ops can still show the backing model, such as Qwen/Qwen3-32B-AWQ. The discovery action only updates the draft list in the dialog; it does not change the saved allow-list until the administrator saves.

If the local runtime does not provide a compatible /models response, use Custom model ID to add the exact model name expected by that runtime.

Connection tests

Use Test on a connection card to send a minimal server-side request to the default enabled model. CT-Ops records only the test status, timestamp, provider type, model reference, and a sanitized error message when the test fails.

Connection tests do not store prompts, model responses, API keys, or raw provider errors in audit metadata.

Security behaviour

AI model settings are instance-scoped and administrator-managed. CT-Ops applies these safeguards:

Safeguard	Behaviour
Credential storage	API keys are AES-GCM encrypted at rest and are never returned to the browser after save.
Central allow-list	Future AI features must call the shared server-side adapter, which rejects disabled providers and non-allowlisted models.
Global model disablement	Disabled model rows are hidden from CT-Ops model pickers and rejected server-side if submitted directly.
Endpoint validation	Local endpoints must use `http` or `https`; plain HTTP requires Insecure HTTP mode.
Request bounds	Model requests have bounded message counts, message size, output tokens, and timeouts.
Redirect handling	Provider requests do not follow redirects automatically.
Sanitized errors	Browser responses, audit events, and stored test errors do not include API keys or full raw provider payloads.

Operator guidance

For hosted providers, create narrowly scoped service API keys and rotate them through the provider console on your normal credential schedule. After rotation, edit the connection, paste the new key, save, and run Test.

For local LLMs, expose only the model endpoint CT-Ops needs from a trusted host or internal gateway. Prefer HTTPS when the endpoint leaves the local machine or container network. Keep the allow-list small so future CT-Ops features cannot accidentally call unapproved models.