AI assistant
assistant
Configure assistant inside the management block.
The assistant block enables an experimental feature. Its behavior and configuration may change in a later release. Configuration checks report it, and the server logs an Experimental feature enabled message. About experimental features.
The assistant block inside the management block enables an AI assistant in Radiator UI. The assistant answers questions about the running server and prepares configuration and RadiatorDB changes. It connects to an OpenAI-compatible chat completions endpoint, such as the OpenAI API or a self-hosted inference server like vLLM, llama.cpp or Ollama. The endpoint and its model must support streaming and function calling.
management {
assistant {
url "https://api.openai.com/v1";
model "gpt-4.1";
api_key env.ASSISTANT_API_KEY;
}
http {
# ...
}
}
Without an assistant block, Radiator UI does not show the assistant.
The assistant works with the same data as the signed-in user. It sends its requests to the Management API with that user's credentials, so the management policy, the user's privilege and RadiatorDB collection roles apply to them, and each request appears in the management log as a request by that user. The assistant can read:
- server, backend, overload and license status
- application logs, AAA logs and AAA request contexts
- counters and counter history
- active and pending configuration files, and the result of validating the pending configuration
- RadiatorDB collections and documents
- the documentation of the running Radiator Server version, for every user
The assistant can create, change, rename and delete files in the pending configuration, which it creates from the active configuration when needed, and create, replace and delete RadiatorDB documents. Each change requires the write privilege or the collection's write role, like the same change made directly. The user sees the content before and after the change and approves or rejects it, unless the user allowed that kind of change without asking for one conversation or for all of their conversations. A change is not applied when the content changed after the user saw it. The assistant cannot deploy configuration or change the active configuration.
The questions and the data the assistant reads, such as log entries with user names and addresses, are sent to the configured endpoint. Values of secret statements, such as secret and password, and inline private keys in configuration files, including configuration that users attach to a message from Radiator UI, are replaced with <redacted> before they are sent, unless the value only references an environment variable. Secrets elsewhere, such as in Lua scripts, are sent unchanged. With a self-hosted endpoint, the data stays on hosts you operate.
| Statement | Default | Description |
|---|---|---|
url | (required) | Base URL of the OpenAI-compatible API, for example https://api.openai.com/v1 or http://127.0.0.1:8000/v1. |
model | (required) | Model name sent with each request. |
api_key | none | API key sent as a bearer token. An empty value sends no key, which suits local inference servers. |
privilege | read | Minimum privilege needed to use the assistant: monitor, read, install, write or all. |
reasoning_effort | not sent | Reasoning effort for reasoning models, sent as written because models accept different levels, for example low, medium or high. |
temperature | not sent | Sampling temperature from 0 to 2, for example 0.2. Many reasoning models reject this parameter. |
max_output_tokens | not sent | Maximum number of tokens in one model response. |
max_tool_rounds | 25 | Maximum number of model requests for one message. The assistant stops with an error when it reaches the limit. |
tool_result_limit | 32000 | Maximum number of characters of one tool result sent to the model. Longer results are cut off. At least 1000. |
timeout | 300s | Time allowed for one model request, including its streamed response, as a duration. |
prompt_cache_key | true | Sends the conversation ID as prompt_cache_key so the endpoint can reuse its prompt cache for follow-up messages. Disable it for endpoints that reject the field. |
instructions | none | Site-specific guidance added to the assistant's instructions, for example naming conventions or the purpose of each backend. |
extra_body | none | JSON object whose members are added to every chat completions request, for parameters specific to one inference server. |
image_input | false | Lets users attach images to their messages. The model must accept image input. |
Options that are not sent leave the choice to the inference server's defaults.
Users can attach up to 5 files to a message. Text files must be UTF-8 and at most 256 KiB. With image_input true;, PNG, JPEG, WebP and GIF images of at most 4 MiB are also accepted. The files of one message can be at most 7 MiB together. Text files are sent to the endpoint as text and images as data: URLs, with every later request of the conversation.
For example, a local inference server that needs a template option to enable reasoning:
management {
assistant {
url "http://127.0.0.1:8000/v1";
model "qwen3-30b-a3b";
max_output_tokens 8192;
extra_body """{"chat_template_kwargs": {"enable_thinking": true}}""";
}
}
Conversations are stored per user in the .radiator/assistant directory of the configuration directory, which only the Radiator Server user can read. They are not part of the configuration, so they are not deployed, exported or backed up with it. The assistant needs a configuration directory; with a single configuration file, it is not available.
The assistant works on a message in the background until it answers, needs the user's approval, or the user stops it. It stops when the user's management session ends. Each follow-up message sends the whole conversation again, starting with exactly the same content as the previous request, so endpoints with prompt caching reuse the cached prompt and only process the new messages.
When the endpoint cannot be reached, or answers with status 408, 429, 500, 502, 503 or 504 before its response starts, the request is retried up to 3 times, after 2, 5 and 10 seconds. A response that has started is not retried. When a run stops with an error, the user can continue the conversation from where it stopped without sending a new message.
Changing the assistant block takes effect for new requests without restarting the management listener.