On this page

Models, providers and the active substrate

Question: what changes when I choose another model, and what does not?

A model produces responses. A provider is an entry describing how to reach a service offering models: its address, protocol, authorization and request settings. A substrate is the model connection in use for the identity's current inference. These are related but not interchangeable.

The identity's continuing records live in host-managed storage. They are not all permanently inside a model. The host constructs bounded context for a request, sends it to the selected endpoint, and handles the response and any tool cycle. Changing provider does not itself create a new identity; it can nevertheless change response quality, style, tool use and available context.

Follow the address, not the label

A service marked local still has an address and must be running. That address could refer to a different machine or a server that forwards requests elsewhere. A hosted provider sends requests outside the AII OS machine. Even a locally served model does not imply that discovery, platform services, updates or plugins never use a network.

Before using a provider, check who operates the endpoint, what credentials authorize, how requests are charged and retained, and what other services are enabled. See privacy and permissions. A provider's model list is discovery data, not proof of response accuracy or full feature compatibility.

Configured is not necessarily active

The source-defined Settings → Substrate section selects a provider entry and model. Settings → Providers owns endpoint, credentials and budgets. The Substrate card shows resolved information and the active provider/model, and states that a change applies after an inference check.

That check is a real model request. Changing substrate can disclose data and cost money; do not treat Save or Chat's Use as a no-effect preview. A rejected candidate does not establish that the previous model stopped working, and an edited field alone does not establish that a new model is in force. Inspect the result and active readback before relying on the change. Exact live transitions still need replay.

Context and output share a finite window

Model requests have limits. The host resolves a context length, reserves output capacity and applies a safety margin. Too little room for the prompt is a configuration error, not a promise that unlimited history will be squeezed into a request. Discovery metadata can supply limits when explicit values are absent; missing or mismatched metadata can leave a fallback or warning.

Increasing a context setting does not enlarge the provider's actual model. Increasing a thinking budget is not a guarantee of correctness. Provider protocols and model capabilities differ; do not copy one provider's settings blindly to another. See the configuration reference.

For the exact conversation mechanism, continue to architecture and data flow. For why retention differs from recall, see continuity and context.

Implementation evidence

Back to section overview · Documentation home