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
External servers	The inference engines
MCP servers	The tool servers models can use
Users	Accounts and roles
Channels	Shared conversations

Tip

Most saves apply immediately and need no restart. A few exceptions are noted below.

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. Each engine keeps its own separate models, so a model pulled for Ollama is not available to Matricxon. 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 Caddy.
• 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.

Caution

Switching does not move any data. The new database starts with the same starter data as a fresh install, one admin account and three default notes. Existing conversations, users, documents and settings stay behind in the old database. Nothing is deleted, and nothing is copied.

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.

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. Changing it does not re-embed documents that were already added.

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.

External servers

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, Ollama or Matricxon. Changing it does not start or stop either one. It only changes where new requests go. A chat whose model is missing on the new engine falls back to another installed model.

Supported engines

pAIring currently supports two inference engines for text, Ollama and Matricxon. Support for more engines may be added later.

Ollama 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.

Ollama also has: models directory, threads, keep-alive, max loaded models and context length.

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	Models kept in memory together	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. Today there is one, for RunPod. See Connectors.
• Cluster. Manage a Matricxon cluster, with a live map of its nodes.