AI / LLM configuration

The AI / LLM Settings page at /settings/ai is where a deployment operator chooses an AI provider, configures the connection, and decides which parts of the product the AI surfaces in. The page is OpenAI-compatible: it speaks the OpenAI chat-completions API shape, which means every provider that exposes that shape — OpenAI itself, Anthropic via its OpenAI-compatible endpoint, Ollama, LM Studio, LocalAI, and others — works from the same six fields below.

There is no NetLock RMM-managed AI. All inference happens at a provider you choose. That lets you keep everything on-premises with a local model if compliance requires, or hand it off to a hosted provider if throughput matters more. The trade-off is that every AI feature in the product depends on the provider you configure here being reachable and responsive.

A.11.1 The master toggle

Enable AI Features sits at the top of the page. It is the single switch that decides whether any AI-driven surface in the product is active.

• When off, every AI affordance across NetLock RMM is disabled. The AI Chat page is unavailable, AI buttons inside Scripts and Remote Shell are hidden, the Analyze with AI button on Event Details is gone, and the AI Assistants inside the Add / Edit Sensor and Add / Edit Job dialogs are suppressed. Everything else in the product keeps working as normal.
• When on, the specific AI surfaces that are active depend on the per-feature toggles below (see A.11.3).

Save persists the change. Toggling the master switch does not interrupt the provider configuration below; turning AI off and back on later restores whatever provider settings you saved last.

Tip: If you are not sure whether AI is the right fit for your deployment, turn the master toggle on, configure the provider, and leave every per-feature toggle at its default. Individual operators can then explore AI Chat (Chapter 13) before you broaden the feature exposure to the in-line buttons.

A.11.2 Provider configuration

Six fields describe the provider. Every AI call the Console makes uses them.

• Provider Name — a free-text label that is shown in the Console wherever the provider identity matters (for example, on the AI Chat page header). Pick something operators recognise rather than the raw URL. Using the literal name of the service — OpenAI, Anthropic, Local Ollama — is usually the right choice.
• API Base URL — the root URL the Console appends chat-completions paths to. The helper text on the field reads e.g., https://api.openai.com/v1. It must include the /v1 segment if the provider expects it; the templates below populate this correctly for the four well-known providers.
• API Key — the secret used in the Authorization: Bearer header on every request. Password-masked input. For local providers that do not require authentication, the field still needs a non-empty value for some SDKs to function; providers vary, and most local setups accept any string.
• Model — the model identifier the provider expects in the chat-completions call. The helper text reads e.g., gpt-4o, claude-sonnet-4-20250514, llama3. If you configure an identifier the provider does not recognise, Test Connection surfaces the provider's error directly.
• Max Tokens — the ceiling on the response length. Numeric input, range 256 to 128000. The value should match what your chosen model and provider accept — a local model with a 4 000-token context window will not honour a 128000 setting. The default produced by the provider templates is 4096.
• Temperature — the sampling temperature. Slider labelled Temperature: <value> with range 0.0 to 2.0 in steps of 0.1. Lower values produce more deterministic output (0.0 is effectively greedy decoding); higher values produce more varied output. 0.7 is a reasonable default for script analysis and event commentary, which is what the provider templates set.

Provider templates

Four one-click templates populate the fields with sensible defaults. Clicking a template overwrites whatever is currently in API Base URL and Model, resets Temperature to 0.7 and Max Tokens to 4096, and leaves API Key and Provider Name for you to fill in.

The page subtitle reads "any OpenAI-compatible provider". A provider that is not listed above — for example, LocalAI or a self-hosted vLLM — works by entering its API Base URL and Model manually. There is no separate "Custom" template because every configuration is custom at heart; the four named templates are just prefilled field sets.

Note: For Ollama and LM Studio, the template URL uses localhost. That resolves to the host running the Console — not the host running your workstation, and not the host running the agent. If you run a local model on a different machine, replace localhost with the reachable hostname or IP. If you run the Console in a container, make sure the container can reach the host's loopback if that is where the model lives.

Test Connection

The Test Connection button sends a minimal probe to the configured provider with the current field values. A spinner labelled Testing... displays during the call; the result is rendered inline below the button as either a success alert or an error alert with the provider's error text quoted.

Use Test Connection every time you change API Base URL, API Key, or Model. A saved configuration that has never tested successfully is a saved configuration that will silently fail every AI action in the product until you notice the first one fail.

A.11.3 Per-feature toggles

Five toggles below the provider section decide which AI surfaces are active in the rest of the product. Each defaults on once the master toggle is on — but you can narrow the exposure for rollout or policy reasons.

Turning a toggle off hides the surface wherever it appears; it does not break the feature the surface belongs to. Turning Script Analysis off still leaves the Scripts editor fully functional — you just do not see the AI Assistant affordance on it.

A common rollout pattern is to leave AI Chat on for all operators (it is the cheapest surface to evaluate), enable Script Analysis and Event Analysis for senior engineers, and keep Remote Shell AI off until the team is comfortable with the suggestions' quality.

A.11.4 Chat history cleanup

AI conversations started from the AI Chat page (see Chapter 13) are stored in the database. Two fields control how long they are retained.

• Auto-cleanup chat history — toggle. When on, conversations older than the retention window are deleted on a rolling schedule. When off, conversations are kept until manually deleted from the AI Chat page.
• Keep chat history for X days — numeric, range 1 to 9999. Disabled when the auto-cleanup toggle is off.

The auto-cleanup loop respects the toggle at runtime: turning the toggle off immediately stops the sweep; turning it on resumes on the next schedule tick. Clearing the retention window does not reset conversations that were already deleted — they are not recoverable.

Warning: Chat history can contain sensitive information operators pasted into the chat (credentials, internal hostnames, PII). If your compliance posture requires it, set a short retention window (7 or 14 days) from day one. Longer windows are defensible when there is a training or coaching use for older conversations.

A.11.5 What to verify after changes

A quick sanity loop after editing this page:

1. Run Test Connection. An inline success alert is the only confirmation the provider is actually reachable and the key, URL, and model all work together.
2. Open AI Chat (Chapter 13) and ask a one-line question. Confirm a reply arrives within a sensible time for the provider you chose.
3. Visit one of the in-line surfaces whose toggle you enabled — the Scripts editor for Script Analysis, Event Details for Event Analysis — and confirm the AI button appears and produces output.

If step 1 passes but step 2 fails, the provider is reachable but the Chat-specific prompt is not being answered; check Max Tokens against the model's context window. If step 1 passes but step 3 fails, the per-feature toggle is off or the operator's role lacks the relevant feature-area permission.

Permissions

• settings_enabled — access to the Settings group.
• settings_ai_llm_enabled — access to the AI / LLM Settings page.

Related chapters

• Chapter 13 — AI Chat — the primary AI surface for operators.
• Chapter 8.1 — Scripts — AI Assistant in the Scripts editor.
• Chapter 8.2 — Jobs and 8.3 — Sensors — AI Assistant in Add / Edit dialogs.
• Chapter 3.3 — Device details view — AI buttons in the Remote Event Log viewer.
• Chapter 3.5 — Remote control — AI in remote shell.
• Chapter 12 — Events & Audit — Analyze with AI on Event Details.
• X.5 — Integration endpoints — the full list of third-party endpoints NetLock RMM reaches out to, including LLM providers.