Choose a model and execution route

ABot does not bundle a language model. It connects to a provider, loads a model profile, and uses the execution route selected for that profile. Keeping these three choices separate makes configuration easier to reason about.

Connection, model, and route

Choice	What it controls	Example
Provider connection	How ABot reaches a service and authenticates	An Ollama base URL or an OpenAI connection with an API key
Model profile	Which exact model to use, its context capacity, capabilities, and calibration	A saved profile for one installed Ollama model
Execution route	How the Runtime divides responsibility during a request	Execution Agent or Supervisor

An Ollama connection does not select or download model weights. Likewise, adding an OpenAI connection does not make every model available to the account. Use a concrete model ID that the configured provider can actually serve.

Add a second model

Open Models → Add model. Choose an existing provider connection or create another OpenAI/Ollama connection, enter the model details, and choose Save and apply.

Adding a model preserves existing profiles and the default model. If activation is deferred, the dialog distinguishes a saved model from an active one. Apply model retries activation without creating another profile. New profiles are stored in separate models/<profile-id>.config.json files beside the selected Runtime configuration.

The equivalent command-line operation is:

npx abot add-model --profile <profile-id> --provider openai --model <model-id>

Replace both placeholders. Add --default only when you intend to change the default. The command does not remove other profiles.

Execution Agent: broader responsibility

Choose Execution Agent for a model that can reliably carry a wider task context, select tools, and decide what to do next. The Execution Agent owns tool execution directly and can request planning or audit advice when needed.

This does not mean every request runs a planner and an auditor. A simple request may finish without either. The route is intended to give capable models room to work, not to require a fixed ceremony around every message.

Supervisor: smaller responsibilities

Choose Supervisor when the model benefits from a more focused division of work. The Supervisor coordinates the request and can delegate to Planner, Worker, and Reviewer roles. The Worker owns tool execution.

This division can be useful for smaller local models: the model does not have to carry every responsibility in one decision. It is not a guarantee that any small model will succeed, nor does it create context capacity the model does not have. Planning and review are available as needed rather than mandatory stages for every request.

Both routes use the same Runtime, tools, permissions, conversations, and persistence. Both work with local or hosted providers. Provider identity alone is not a reason to prohibit a route.

Set the route explicitly

In Models, select Execution Agent or Supervisor under Execution route. In a model profile file, the corresponding fragments are:

{
  "execution": {
    "policy": "execution-agent-v1"
  }
}

{
  "execution": {
    "policy": "supervisor-worker-v1"
  }
}

These are model-profile fragments, not complete Runtime configuration files. Omitting execution.policy uses the Supervisor/Worker policy. The OpenAI setup flow recommends and writes the Execution Agent policy. Changing a route is an architectural choice, separate from adjusting temperature or step instructions.

Declare real context capacity

contextWindowTokens belongs to the model profile. Set it to the actual capacity supported by the concrete model configuration. Entering a larger number does not enlarge the model’s context window.

For example, this fragment describes a profile with a 32,768-token capacity; it is not a universal setting for local models:

{
  "contextWindowTokens": 32768
}

The request runner reserves room for output, safety, and attachments. Those reserves are admission headroom, not an instruction to every provider to generate that many output tokens.

Calibrate one problem at a time

A successful connection does not prove that every model step is reliable. Start with one representative task, inspect the failing modelStep, and change only the relevant calibration slot. Compare actual output and artifacts, then test nearby requests.

Increasing a timeout helps with latency, not reasoning. Copying another model’s settings without testing can introduce new problems. Continue with configuration for file ownership, or the field guide for concrete calibration and instruction examples.