Ask Metnos with a request like this example: “Show me where I can change the model and reasoning budget for the wise tier.”

Metnos guides you to the administration page in the web chat: Settings > System > Models. If you ask from Telegram, the Tutor can explain the path, but the page opens in the web chat. Its internal address is /admin/virt, and it requires administrator access.

The runtime does not bind its components to a model name. Each component asks for a logical role; the effective configuration maps that role to a provider, model, endpoint, and related parameters. The Models page shows this mapping and lets an administrator change it without changing the code of the components that use it.

1. Using the Models page

1. Open the Metnos web chat and sign in as an administrator.
2. Open Settings > System > Models. The same page is served at /admin/virt.
3. Choose the family you want to inspect: language models, embeddings, or the vision-language model.
4. For language and vision-language models, press Edit to make the visible values editable.
5. Embedding is view-only: replacing its backend requires a dedicated procedure, verified compatibility, and index reconstruction.
6. Review the values and press Save changes. The confirmation states that subsequent calls will use the new configuration.

The page opens in viewing mode. Reload configuration reads the file and renders the current state again; it does not save changes or restart models. Page edits are separate between LLM and VLM; embedding remains view-only and is never rewritten from the UI.

This is administrative configuration for the Metnos instance run by that system account. It is not a personal preference of an individual conversation user.

2. Logical roles and runtime facades

A consumer states what it needs, not which product or model must satisfy the request. Resolution goes through three public entry points in runtime/virt:

The LLM tier names express the caller's intent. They do not by themselves certify the quality of the concrete model: the administrator decides which provider and model satisfy each role. A partial LLM file overrides only the roles it contains; omitted fast, middle, and wise bindings use their initial values. Fast levels inherit the fast binding and may be overridden in [fast.level.micro], [fast.level.procedural], or [fast.level.fidelity]. When creative is absent, its physical binding is mapped to wise while retaining the creative policy. frontier is optional, and callers that request it must handle its possible unavailability.

from virt import get_embedder, get_llm, get_vlm

text_encoder = get_embedder("text")
planner = get_llm("wise")
translator = get_llm("fast", level="fidelity")
vision_spec = get_vlm("default")

Virtualization therefore separates two decisions: the component selects a role; the instance configuration selects the backend. Changing a binding among providers already supported by the runtime does not require changes to executors or the planner. Adding a provider type unknown to the runtime still requires an implementation.

3. What the page shows

For each family, the page presents:

• the path of the file actually read and any environment variable that overrides it;
• the configured, initial values, or invalid state;
• the resolved roles and the provenance of each value: configuration, initial values, alias, or fallback;
• the provider, model, and endpoint binding;
• the LLM tier's generation policy, including think, temperature, and reasoning_budget when present;
• the other effective scalar parameters, such as timeouts and model paths.

Generation-policy values are the tier's effective values, resolved from the configuration file and initial values. Operations select a tier and do not keep a second decoding profile. Output ceilings, deadlines, grammars, and tool schemas remain operation-level structural constraints.

Passwords, tokens, keys, credentials, and sensitive URL parts are not shown. They are also excluded from fields submitted by the form. Secrets already present in the document are preserved during a save, but they are managed through the protected credential flow or the service environment, not from this page.

Reading the page neither instantiates providers nor loads models: it builds a bounded, secret-free projection of the resolved configuration.

4. Editing and saving

For LLM and VLM, after you press Edit, Metnos exposes only visible scalar values whose type it can preserve. Sensitive fields and values that cannot be edited remain read-only. On save, the runtime:

1. accepts only the exact field set displayed by the editor;
2. reconstructs TOML types and validates providers, URLs, numeric values, and family constraints;
3. rejects a stale revision instead of overwriting a concurrent change;
4. retains a private copy of the previous file, when one exists;
5. writes the new document atomically with 0600 permissions;
6. invalidates the relevant runtime caches.

An invalid configuration does not replace the previous file. After a valid save, no reinstall, recompilation, or server restart is required: subsequent calls resolve the new values. A turn already in progress finishes with the resources it has already acquired.

5. Restoring and recovery copies

Restore defaults operates on LLM or VLM and asks for confirmation. It writes the initial values supplied by the installed Metnos version. It does not automatically select an old personal configuration or reconstruct choices made during an earlier installation.

Before restoring, Metnos retains a private copy of the current file when the file exists. Copies made by saves and restores are stored below $METNOS_USER_STATE/virt-config-history/<family>/; with default paths, the root is ~/.local/state/metnos/virt-config-history/. The page does not expose a historical-version picker: recovering one specific copy is a separate administration operation.

6. Effective files and precedence

The page always shows the effective path, which is more reliable than a path remembered from another installation. Unless overridden, the documents belong to the system account that runs Metnos.

$METNOS_USER_CONFIG is normally ~/.config/metnos. If a file does not exist, the runtime uses the initial values from the installed version and the page says so. If a document cannot be read or fails validation, the page reports an invalid state and distinguishes any fallback values from a valid configuration.

7. Local and remote boundaries

Virtualization centralizes backend selection; it does not turn a remote endpoint into a local resource, nor does it grant an executor network access, credentials, or additional capabilities by itself.

8. LLM-call census

Every production call selects a logical workload. The router resolves it to a tier and, for fast, to its level. A component may define operation-specific requirements such as max_tokens, a timeout, or an output grammar; it does not select a provider, model, or endpoint, and it does not retain a second generation profile. The instance configuration is therefore the sole owner of each tier's effective values.

A tier may point to a local or remote service and may be changed by an administrator. Changing it changes subsequent calls in every row that uses it; the person configuring tiers must therefore assess capability, cost, privacy, and availability.

9. Technical references

• runtime/virt/__init__.py — facades and initial embedding and VLM values;
• runtime/llm_router.py — LLM tiers, bindings, aliases, and inference policy;
• runtime/llm_workloads.py — declarative registry mapping each production workload to one logical tier;
• runtime/virt/configuration.py — effective projection, provenance, and secret redaction;
• runtime/virt/config_editor.py — validated editing, atomic writes, recovery copies, and restore behavior.

For the full web-chat map, see the interface navigation guide. To understand how executable components consume these roles, continue with the executor guide or return to the Architecture guide.