pAIring admin settings

Admins have a separate Admin settings page. It has six tabs. Regular users see only their own Models, Behavior, Knowledge and Account tabs, described in Your settings. Admins also get Stats, Connectors and Cluster pages in the sidebar.

Tab	What it controls
Models	Which models are installed, and the defaults
System	Instances, database, limits, timeouts and defaults
Inference engines	llama.cpp, Matricxon and the cloud connectors: pick and set up the active engine
MCP servers	The tool servers models can use
Users	Accounts and roles
Channels	Shared conversations

Models

Browse more models. Search Hugging Face for GGUF models. This needs internet access, or an outbound proxy set under System. Adding a model that is already installed does not need the network.
Installed models. The models of the active engine. By default llama.cpp and Matricxon share one models folder, so a model pulled under either is installed for both (a remote server keeps its own models). You can pick the default model for new chats.
Recommended models. Suggestions that are not installed yet.
Embedding model. Powers the knowledge base. It is not used for chat.
Diffusion models. Image models for the Images page. They are installed into the image engine’s own folder.

If a Matricxon cluster has lost its quorum (a majority of its voting nodes), model downloads fail until it recovers. Chats keep working.

System

Environment. The app version and a hardware summary.

Local server mode and Local instances.

Instance count (1 to 8) is how many pAIring processes run on this pAIring node, sharing one database, models and knowledge base. It takes effect at once.
Mode decides how those instances sit behind one address. Local lets pAIring balance the load itself, sending each request to the least busy instance. External balancing leaves it to your own reverse proxy such as Nginx or HAProxy.
The mode only matters when there is more than one instance.

Database.

SQLite (a single local file, the default) or MySQL (a separate server).
For MySQL, create the database and user first, with utf8mb4_bin collation. pAIring connects but does not create the database. Use Test connection and Build schema before saving.
Saving switches over at once, without a restart.

Outbound HTTP proxy. Used when pAIring downloads models, and for engines it runs locally. Host, port, and optional username and password. It does not affect requests coming into pAIring.

RAG (knowledge base).

A switch to turn the knowledge base on or off for every user. Off stops uploads and stops chats from searching documents.
Max file size (MB) and Max per-user space (MB). The file limit also applies to shared documents. The space limit does not.
On a Matricxon node with no GPU, the knowledge base can be extremely slow, both when documents are added and when they are searched. Consider lower file size and space limits there.
Embedded documents shows how many documents there are, which embedding model is current, and how many were embedded with another model. Re-embed all documents embeds every document again with the current model. Without a GPU this can take a long time; with a cloud engine it uses some of your allowance.

Reranker. Picks the reranker model that orders knowledge base results, or Off. Once a reranker is chosen, Passages to rerank (5 to 50, default 20) sets how many of the closest passages it reads per question: fewer is faster. Install rerankers under Settings → Models → Reranker models; they work with Matricxon and llama.cpp. See Knowledge base (RAG).

Default models. Each has its own Save button.

For new users: the model a new account starts with.
Vision: answers any message that has an image, for that one reply only.
Embedding: powers the knowledge base. Each document remembers the model it was embedded with. After a change, documents from the old model are left out of searches until they are embedded again: the next sync does it, or press Re-embed all documents under RAG.

Chat titles. Simple builds a title instantly from the first message. Smart asks the model to invent one, which costs an extra generation.

Channel replies.

How members find out about a reply: Cheap (other members’ tabs check every few seconds) or Real (pushed live, token by token, reliable with a single app instance).
Messages posted without asking the AI: Include (the model reads them) or Skip (a shorter, faster prompt).

Context window. How many tokens one request can hold, which is the conversation so far plus the reply. It is one value for every chat and channel. A bigger window keeps more history but uses more memory and slows the start of each reply. Keep it within what your models support.

Reply timeout and Vision reply timeout. How long pAIring waits for a reply before marking it failed. The vision timeout is separate and longer, because reading an image is slow on a CPU. A value of 0 means no timeout.

Data retention. How many days the Stats page keeps its Telemetry history and its System (CPU, RAM, disk) history. Both are small by default.

MCP tools. The master switch for tools, and the limits all MCP servers share:

Max tool rounds per reply (5 by default, up to 20).
Max tool result characters. A longer result is cut before the model reads it.

Inference engines

A selector at the top picks which engine to configure: Choose models engine or Image-generation engine.

Active engine. Which engine answers chat and embedding requests: llama.cpp, Matricxon, or a connector such as Cloudflare Workers AI once it is set up and tested. Changing it does not start or stop any of them. It only changes where new requests go. A chat whose model is missing on the new engine falls back to another installed model.

llama.cpp and Matricxon share these controls:

Mode: Local (pAIring installs, starts, stops and configures it) or Remote (it only talks to servers that run elsewhere, up to 120, balanced by least busy).
Install from GitHub, with an option to use another repo or version. Or enter the path of an engine you installed yourself.
Start, Stop and Save.

llama.cpp also has: build (CPU, Vulkan or CUDA), models directory (blank shares Matricxon’s), parallel requests, unload after idle, max loaded models, GPU layers and extra arguments. The context size comes from Settings → System → Context window.

Matricxon settings (local mode). Leave a field blank to use Matricxon’s own default.

Setting	What it does	Default
Project directory	Where Matricxon is installed	auto-detected
Models directory	Where models are stored	Matricxon’s own
Saved chat caches directory	Where saved chat caches live	Matricxon’s own
Max loaded models	Chat models kept in memory together. Embedding, reranker and vision models don’t count	2
Memory safety margin	Free memory needed beyond a model’s size, 1.1 to 1.8	1.2
Quantized native compute	Multiply packed weights directly	on
Kernels	Native C (about 5 to 10 times faster, needs gcc) or Numba	Native C
Compute device	CPU, or CUDA GPU (experimental)	CPU
GPU weights	Dequantized (fast, more VRAM) or Packed (less VRAM, slower)	Dequantized
Log level	0 warnings, 1 pipeline steps, 2 per-layer trace	0
CPU threads	Fewer threads run cooler	all cores
Keep model loaded	Minutes idle before it unloads, 1 to 1440	5
Cached conversations per model	Chats whose cache each model keeps	4
Cache memory budget (MB)	Memory those caches may use together	2048
Concurrent replies per model	Replies that run at once on one model	8

Saved chat caches keep each long chat’s processed state on disk, encrypted, so returning to it does not re-read the whole conversation. You can turn it on or off, set a disk limit (MB) and a keep time (hours), or delete all saved caches. Turning it off deletes everything saved.

When cluster mode is on, the node list, the shared folders and the cache limits are managed on the Cluster page. See Deployment layouts.

Image engine (stable-diffusion.cpp). See Image generation.

MCP servers

Connect tool servers that use the Model Context Protocol (streamable HTTP), so a model can look things up or take actions.

For each server you set:

Name and URL.
Headers, one per line, such as an API key. They are stored encrypted and are never shown again. Leave the box empty to keep the saved headers.
Enabled, to switch one server off without deleting it.
Tool call timeout, in seconds.

Use Test connection before saving. Only connect servers you trust, because whatever a tool returns is shown to the model. Users turn tools on per chat. See Chat and channels.

Users

Add accounts and set each person’s role and status.

Role	What they can do
User	Chat, use channels they belong to, and manage their own settings
Channel manager	A user who can be made a manager of channels
Admin	Everything, including this page

A new account starts with the default model for new users. An account can be Active or Disabled. Disabling keeps its history instead of deleting it. You need at least one model installed before you can add a user.

Channels

Create shared conversations and choose who is in them.

Name and members. Every member can read and send messages.
Managers. A channel needs at least one. Managers must be members with the Channel manager role. Admins and managers can change the channel’s model, settings, notes and tools.
Reset wipes a channel’s history and sets its notes fresh. The channel and its members stay. It cannot be undone.
Delete removes the channel.

See Chat and channels for how channels work for members.

Other admin pages

Stats. Usage overview, an interactive diagram of the request pipeline, telemetry (latency, tokens per second, error rate, loaded models) and CPU, RAM, disk and GPU monitoring. See Stats and monitoring.
Connectors. Add engines that run on cloud GPU services. Currently supported connectors are Cloudflare Workers AI, DigitalOcean Serverless Inference, OpenRouter, Google Gemini, Groq, NVIDIA NIM, Cohere and RunPod Serverless. See Connectors.
Cluster. Manage a Matricxon cluster, with a live map of its nodes.