Settings¶
Backend.AI GO groups settings into three navigation sections:
- App
- Agent
- System
Older docs sometimes referred to retired tabs such as Inference, Network, or Storage. Those names no longer match the current UI.

Current settings tabs¶
| Group | Tab | What it covers |
|---|---|---|
| App | General | app language, timestamp format, startup behavior, and general app preferences |
| App | Appearance | theme and UI presentation |
| App | Models | default models for app surfaces and default engines by format |
| App | Generation | default reasoning effort, generation defaults, container-engine defaults, and MLX engine defaults |
| App | Performance | each model's speed on this computer, the quick check, tuning a GGUF model (and an MLX model on Apple Silicon), the first-run check, and how long measurements are kept |
| App | Tools & extensions | tool permissions, MCP, and the web search tool |
| App | Voice Input | microphone and transcription behavior |
| App | Demo Mode | demo-mode behavior |
| App | Advanced | advanced app behaviors such as transport-related options |
| Agent | Memory | memory-related controls |
| Agent | Data | Data Hub search presets and maintenance: watched folders, re-fetch, wiki updates, the data doctor, and the trash |
| Agent | Squad | the messenger channels connected to squads, the agent runner image, and the global instructions for squad agents |
| Agent | Supervisor | supervisor controls |
| Agent | Policies | policy controls |
| Agent | Agent Protocol | ACP settings |
| Agent | Agent Registry | registry sources for agent profiles and squad templates |
| System | Connectors | connector settings |
| System | Managed endpoints | managed remote endpoints |
| System | Organization | organization-wide settings |
| System | Nodes | Share this computer and Connect other computers |
| System | Maintenance | maintenance utilities |
Where key controls live now¶
Models directory¶
Open Settings > Models.
Additional model folders¶
Open Settings > Models > Additional model folders. Besides its own models directory, the app can read models from folders that belong to another application, such as an LM Studio library, the Hugging Face cache, or the Ollama model store. Add a folder with Add folder, or press Find models from other apps to have the app look in LM Studio's default locations (~/.lmstudio/models and ~/.cache/lm-studio/models), in the Hugging Face cache (see Hugging Face cache), and in Ollama's (see Ollama models), and add one with a click.
A model from an added folder is listed and loaded like any other, and the Models page marks it with the folder's name. The folder itself is treated as read-only: the app never writes into it, so Delete is not offered for these models and nothing you do here changes what the other application sees. Settings you make for such a model, including an alias and its launch configuration, are kept in the app's own data directory and survive removing and re-adding the folder.
Each folder can be turned off without removing it, which hides its models until you turn it back on. A folder that is missing, on a drive that is not connected, or that the app cannot read stays in the list as Not available. Its models are hidden while it is unavailable, Refresh on the Models page keeps them in the index, and they reappear when the folder is readable again. Removing a folder and adding it again under the same key restores the settings saved for its models.
A folder cannot overlap the models directory, another added folder, or the app's own data directory, and it cannot be the filesystem root, your home directory, or a folder that contains your home directory (such as /home). At most 16 folders can be added. A symbolic link from the models directory into an added folder is not followed, so the same files are never listed twice and the scan never writes into the folder through the link.
On a server, a folder declared in config.toml takes precedence: if a folder saved in the settings uses the same key, the saved entry is dropped and a warning is logged. See Additional Model Sources.
Ollama models¶
Models pulled with ollama pull are read where Ollama keeps them, without copying or converting anything. Find models from other apps looks for Ollama's store in the folder OLLAMA_MODELS names, in ~/.ollama/models (%USERPROFILE%\.ollama\models on Windows), and on Linux in /usr/share/ollama/.ollama/models, where the Ollama service install keeps it. When you add a folder by hand, pick that models folder; picking the .ollama folder above it adds the models folder inside it. The app reads Ollama's manifests and loads each model in llama-server straight from Ollama's blob store. Each tag is listed under the name Ollama shows, such as llama3.2:3b or hf.co/Qwen/Qwen3-0.6B-GGUF:Q8_0, so two tags of the same weights are two entries, and they share an alias and launch settings because those are kept per weights file. A vision model whose download includes a projector loads with it and is marked as able to read images.
A model is not listed while its download is incomplete or its weights are missing, when Ollama stores it only as safetensors weights for its MLX engine, or when it is a fine-tuned adapter (LoRA) over a base model. The chat template comes from the model file itself: Ollama's own template is written for Ollama's Go template engine and is not used, so a model whose file has no chat template behaves as it would from the models directory.
The app skips anything in the store that is not a regular file, such as a named pipe or device file where a model file belongs, instead of waiting on it. It reads at most eight entries of a manifest that lists several runners, so a manifest padded with entries is not read in full. A load request over the REST API (POST /models/load) that names a projector (mmprojPath) must name a file inside the models directory or an additional model folder, and any other path is refused with a 400 error. A projector file that has since been deleted, for example one Ollama removed, is ignored and the model loads without it.
Ollama manages its store on its own terms. It deletes a model's files on ollama rm and removes files no model refers to when it starts (unless OLLAMA_NOPRUNE is set), and a model removed there disappears here at the next scan. On Windows, a model loaded here keeps its file open, so Ollama cannot delete it until you unload the model. Some models in the Ollama library use architectures that Ollama's engine runs and llama.cpp does not support yet; they are listed, and loading one fails with the engine's load error.
Hugging Face cache¶
Models that huggingface-cli download, the huggingface_hub library, mlx-lm, or llama.cpp -hf fetched are kept in the Hugging Face cache, by default ~/.cache/huggingface/hub (%USERPROFILE%\.cache\huggingface\hub on Windows). When HF_HUB_CACHE is set, the cache is that folder instead, and when HF_HOME is set, it is the hub folder inside it. Find models from other apps checks all three. To add the cache by hand, pick the hub folder itself, the one that holds the models--<org>--<name> folders; the app refuses a folder that holds none of them unless it is empty.
The app reads one revision of each model repository: the one named in the repository's refs/main, or the most recently modified snapshot when that file is missing. GGUF files, split GGUF files, and MLX safetensors repositories are listed under the repository's own name (ggml-org/Qwen3-0.6B-GGUF), marked Hugging Face cache, and load from the cache without a copy. A download that is still running or was interrupted is skipped, and datasets and Spaces in the same cache are ignored. As with any added folder, the app never writes into the cache, so huggingface-cli keeps managing it.
The app takes refs/main and the snapshots folder only when the cache itself wrote them as plain entries. A refs folder, a refs/main file, or a snapshots folder that is a link is not followed, and a refs/main larger than a revision hash is not read; in those cases the app uses the most recently modified snapshot, and a linked snapshots folder means the repository is not listed. If you added the cache through a link to the hub folder, its models keep the names they have in the list when you load them. A GGUF file whose header nests data absurdly deep is still listed, but the app does not read its details, and one such file does not stop the scan. Diffusion models in the cache find their companion files (VAE, text encoders) in the same snapshot folder.
Default models for app surfaces¶
Open Settings > Models.
Default engines by format¶
Open Settings > Models.
Default reasoning effort and generation defaults¶
Open Settings > Generation.
When Use model's max context is enabled, Backend.AI GO starts with the model's reported native maximum and limits it with Automatic context limit. It can reduce that value further when the launch memory estimate does not fit the available RAM and VRAM. This estimate does not guarantee that a load will succeed. If system metrics are unavailable, or the model estimate does not fit even at 512 tokens, the automatic context limit remains the selected value and the normal compatibility check remains authoritative.
An explicit context chosen for a load has first priority. A saved per-model context has second priority, and both remain exact. Otherwise, Backend.AI GO uses the limited native maximum, then the selected preset, then the custom default.
MLX engine defaults¶
Open Settings > Generation.
Run across cluster transport port range¶
Open Settings > Advanced > Ports & networking.
Socket directory¶
Open Settings > Advanced > Ports & networking. Leave Socket directory empty to use the per-user runtime directory described in Local Socket Location. A custom value must be an absolute path inside your home directory, 62 bytes or shorter (so a socket name still fits in the 103-byte limit), and is applied to the router, the model servers, the Management API, and the monitor at the next launch. A longer path is rejected when you save, with the byte count in the message.
Model speed on this computer¶
Open Settings > Performance. The tab opens with this computer on a card (its chip or GPU, memory, and accelerator) and, beside it, the fastest local model measured here with its answer speed. This tab lists each local model with its answer speed and first response on this computer, measured by a 15-second Quick check (on a model that is not running, it asks first whether to run it for the check, and whether to stop or keep the other running models), and marks a number engine changed or settings changed once it no longer describes the next run. A model's detail adds the verdict for chat and the engine and settings it was measured with; This model's records opens the model's history on the Benchmark page, where comparing runs and raw llama-bench measurement live. The options turn the check on a model's first run on or off (off by default, so nothing is measured unless you ask), show provider models (off by default, because measuring one sends a paid request), and set how long records are kept (90 days by default; baselines stay).
Tune settings automatically (off by default) lets AI:GO tune local models for Chat while you are away from the computer. It starts only after ten minutes with no keyboard or pointer input and no request through the router, with nothing loading or measuring, on AC power, and with memory to spare for the model. On Linux it needs GNOME or xprintidle to tell how long the computer has been idle, and without either it never starts. It tunes one model at a time, the running ones first, and only a model whose chat tune has something to try; a model is tuned again only after its file, the engine, or the computer changes. It runs the same measurement as Tune on the Benchmark page without the drafter comparison, stops the running models without asking, and runs them again afterward. Anything you do stops it at once and changes nothing: using the computer, a chat request, loading a model, starting your own measurement, switching to battery, turning the switch off, or quitting the app. A finished run applies only speed settings (batch sizes, threads, flash attention, GPU layers, CPU MoE layers, the MLX prefill chunk, and n-gram speculation), only when they are at least 1.1 times faster, and never a value you set yourself. It does not run the model again, so the values take effect on its next run. Applied values read Set by AI:GO in the Hardware tab of the model's settings and under Profiles in its detail, where Undo restores what was there before. The Benchmark page's History marks these runs Automatic and says why a stopped one stopped, and the line under the switch says what it is doing. A headless server never tunes on its own: the setting is stored there but does nothing.
Tune, which finds faster settings for one use when you ask, is on the Benchmark page (see Tune). Each model keeps one profile per use under Profiles in its detail here, where Undo restores the settings from before an apply (it asks first and names the date), and a saved profile's Apply opens its result on the Benchmark page. Apply and Undo are unavailable while another measurement runs, since both run the model again.
On a laptop, Defer while on battery holds the first-run check until the model's next run on power.
After an engine or app update, a model's number reads engine changed until it is measured again. Nothing measures on its own, since a check would interrupt a running model; instead the app keeps timing real use. Once ten chat answers of at least 64 tokens have run on the new engine with the same settings as the baseline, it compares their median answer speed with the baseline's, and below 80% of it the model's row and detail warn, for example "Qwen3-8B is slower than before the update. Answers 34 tok/s, previously 45 tok/s.", and one notification offers Measure again and Tune, once per model and engine build. Measure again runs the quick check and makes its result the new baseline either way: within 10% of the old speed it says the measurement matches before, so the slowdown may come from the conversations themselves, and otherwise the warning stays, and Tune in the notification opens the tune on the Benchmark page. Answers given with other settings than the baseline's are never compared, because a different setting is not a slowdown, and provider models are never compared at all. A headless server does the same with the chats its web UI runs.
Tool permissions, MCP, and web search¶
Open Settings > Tools & extensions.
General holds the tool-calling switches and Available tools, which opens the list of tools with a switch and a Test action on each. The MCP servers and the web search tool follow it. Workspace context, Python sandbox, Local network access, and Skill shell injection each open from Advanced at the end.
This covers Backend.AI GO as an MCP client, connecting to remote MCP servers. To expose Backend.AI GO itself as an MCP server, see MCP Endpoint under Settings > API Server > Management API.
Voice input behavior¶
Open Settings > Voice Input.
Update channel¶
Open Settings > General, in the Updates section. The channel decides which build the update check fetches: Stable, Beta, or Canary.
Switching the channel moves you to that channel, and the app then offers the newest build of the target channel that was published after your current build, compared by publication date rather than version number. When nothing has been published after your build, the check reports no update and you stay where you are. Checks within the same channel keep comparing version numbers.
Connector configuration¶
Open Settings > Connectors.
Data Hub search presets and maintenance¶
Open Settings > Data, or the Data settings tab on the Data page. Each preset opens as its own page with its editor, its embedding run, and delete; going back with unsaved edits asks first.
Maintenance tasks¶
Open Settings > Maintenance.